Wie leitet VPN den Netzwerkverkehr weiter? (Schicht 3)

Ich suche nach Informationen darüber, wie VPNs (Virtual Private Network) den Netzwerkverkehr über seinen VPS (Virtual Private Server) weiterleiten.

Nehmen Sie ein Beispiel, in dem Sie mit einem VPN verbunden sind. Sie stellen eine Anfrage an eine Website, die dann den Netzwerkstapel hinunter zu Schicht 3 gelangt.

Wir haben ein IP-Paket - es hat seine Header, einschließlich seiner Zieladresse, und eine Nutzlast.

Wie leitet der Server die Anforderung an die ursprüngliche Zieladresse weiter, wenn Sie die Zieladresse des IP-Pakets in die IP-Adresse des VPS ändern?

Das einzige, woran ich denken kann, ist, dass auf Schicht 3 (der IP-Schicht) die Zieladresse des Headers in die IP-Adresse des VPS geändert wird und dann die ursprüngliche Zieladresse an die Nutzlast des Pakets angehängt wird.

Bedeutet dies nicht, dass die Länge des Pakets und der Prüfsummenheader des Pakets neu berechnet und das IP-Paket erneut geändert werden müsste?

Und dann führt der VPS die inverse Zuordnung des Pakets durch, um die ursprüngliche Anforderung auf dem Server zusammenzustellen und zu stellen.

Dies scheint mit einer hohen Latenzzeit verbunden zu sein?

Vielleicht fehlt mir ein technischer Aspekt, wie das funktioniert. Kann es jemand anderes erklären?

Nehmen wir zum Beispiel den GRE-Header (GRE ist ein Protokoll zur Realisierung von VPNs - es wird nicht oft verwendet, da es in keiner Weise sicher ist, aber das Konzept der Kapselung ist bei jeder VPN-Verbindung nahezu gleich (so auch bei IPSec zum Beispiel). ):

Wie Sie sehen können, wird das Originalpaket in ein anderes IP-Paket eingekapselt.

Nehmen wir an, es gibt zwei Netzwerke / Router (A und B, ein Router kann ein VPS sein), die über ein VPN (Site-to-Site) miteinander verbunden sind.

Wenn ein Host in Netzwerk A auf einen FTP-Server in Netzwerk B zugreifen möchte, sendet der Host in Netzwerk A ein Paket, wobei die Zieladresse die IP-Adresse des FTP-Servers und die Quelladresse seine eigene ist.

Dann kommt das Originalpaket zum VPN-Gateway (wahrscheinlich seinem Router), das dieses Originalpaket beispielsweise in ein IPv4-Paket einkapselt, dessen Zieladresse das VPN-Gateway (Netzwerk B) und dessen Quelladresse ist. Auf diese Weise kann das Paket über das Internet zum anderen VPN-Gateway (Netzwerk B) übertragen werden. Hier spielt das ursprüngliche Protokoll / Header oder Pakettyp keine Rolle, da es mit einem IPv4-Header gekapselt wird, um über das Internet zu übertragen, und andere Router sich nicht um das ursprüngliche Protokoll / Header kümmern, da sie nur das "neue" sehen. IPv4-Header.

Es muss eine neue Prüfsumme für das "neue" Paket berechnet werden, die angehängt wird, da es sonst nicht über das Internet übertragen werden kann (da beispielsweise PPP manchmal zwischen Punkten im Internet verwendet wird, die eine Prüfsumme berechnen). Das gesamte Paket muss also zwei Prüfsummen enthalten.

Bei IPsec (das fast immer für VPN-Verbindungen verwendet wird) wird das Originalpaket verschlüsselt (meistens über AES) und ein Klartext-Header (der "neue" Header für die Übertragung über das Internet) hinzugefügt. Es muss Klartext sein, damit es richtig weitergeleitet werden kann. Dazu muss auch eine neue Prüfsumme berechnet werden (da die ursprüngliche Prüfsumme verschlüsselt ist).

Wenn es das andere VPN-Gateway (Netzwerk B) erreicht hat, wird der VPN-Header auseinandergenommen und das ursprüngliche Paket in das Netzwerk (an den FTP-Server) gesendet.

Die kurze Antwort auf Ihre Frage lautet also Kapselung. Das heißt, es gibt einen weiteren Satz von Paket-Headern um das Paket, das Sie an eine Website senden, die vom VPN-Endpunkt entfernt wird.

Denk darüber so:

-----------------------------------------------
| src_ip=2.2.2.2, dest_ip=3.3.3.3             |
|---------------------------------------------|
|| src_ip=10.10.10.10, dest_ip=5.5.5.5       ||
|| Data goes here. This could be a HTTP GET  ||
|| or pretty much anything.                  ||
|---------------------------------------------|
-----------------------------------------------

Ihr VPN-Client, der auf Ihrem lokalen Computer ausgeführt wird, gibt Ihnen eine neue IP-Adresse (10.10.10.10) und ändert Ihre Routentabelle so, dass die Standardroute den erstellten Tunnel entlang führt. Anschließend wird der Datenverkehr an den VPN-Server oder in Ihrem Beispiel an einen VPS (3.3.3.3) gesendet. Oft wird auf Ihr Paket ein NAT angewendet, wenn es entkapselt wird, sodass auf Ihrem Zielserver (5.5.5.5) der Datenverkehr von der Ziel-IP des gekapselten Datenverkehrs (3.3.3.3) stammt Der Datenverkehr wird zurück an Sie gesendet, indem Sie zuerst zum VPN-Server gehen.

Weiter zu Ihrer dritten Frage. Da Sie ein zusätzliches Paket im Wesentlichen außerhalb der Länge platzieren, wird die Prüfsumme für das resultierende Paket berechnet. Also ja, es gibt zwei Längen und zwei Prüfsummen. Für die maximale Länge, die entweder vom VPS-Sprichwort durchgeführt wird, verwenden Sie diese MTU oder durch MTU-Erkennung wie gewohnt.

Wie für die Latenz. Sie können die Physik nicht brechen. Sie werden Ihren Overhead berücksichtigen, wenn Sie zum VPS gelangen und dessen Netzwerkstapel durchlaufen. Obwohl es den Anschein haben mag, dass es eine hohe Latenz geben würde, ist dies manchmal nicht der Fall. Wenn Ihr VPS topologisch mit der Position des Pakets übereinstimmt, wird möglicherweise nur ein minimaler Overhead hinzugefügt. Wenn Sie beispielsweise in Seattle sind und Ihr VPS in New York ist und die Website, mit der Sie sprechen möchten, in London ist. Wenn Sie jedoch von Seattle nach New York reisen, um zu einer Website in Seattle zurückzukehren, entsteht eine zusätzliche Latenz von der Reise durch die USA.

Ein Paket wird von der Transportschicht erstellt und an die Netzwerkschicht weitergeleitet. Der Host sucht in seiner Routing-Tabelle und sendet sie an die von der VPN-Software erstellte virtuelle Schnittstelle.

Die VPN-Software nimmt das Paket von der virtuellen Schnittstelle. Es kann es verschlüsseln oder eigene Header hinzufügen und es dann als Nutzlast an den Netzwerkstapel zurückgeben. Abhängig von der jeweiligen VPN-Implementierung kann diese Nutzlast an die Transportschicht weitergeleitet oder die Transportschicht umgangen und direkt an die Netzwerkschicht weitergeleitet werden.

Eine weitere Schicht von Netzwerkschicht-Headern wird dann zu dem Paket hinzugefügt, das auf den VPN-Server abzielt. Das Paket wird dann erneut in der Routing-Tabelle nachgeschlagen und ins Internet gesendet (wenn das VPN eine "vollständige Abdeckung" ist, muss die VPN-Software darauf achten, die Routing-Tabelle so einzurichten, dass der VPN-Verkehr über das Internet hinausgeht echte Internet-Schnittstelle statt zurück zur VPN-Software).

Wenn das gekapselte Paket beim VPN-Server ankommt, wird es an die VPN-Software zurückgegeben. Die "äußeren" Header werden entfernt und das Paket über eine virtuelle Schnittstelle an den Netzwerkstapel zurückgeleitet.

Danach ist es Sache des Netzwerkstapels auf dem VPN-Server, was damit zu tun ist. Im Fall eines VPN, das für den Internetzugang verwendet wird, wird der Netzwerkstapel auf dem VPN-Server wahrscheinlich als NAT-Router konfiguriert, sodass die Quelle des Pakets geändert und wieder an das Internet gesendet wird.

Wenn die Antwort zurückkommt, geschieht der gleiche Vorgang. Das Paket kommt herein, der NAT-Prozess wird umgekehrt, es wird über die virtuelle Schnittstelle an die VPN-Software zurückgegeben, es wird gekapselt und an die VPN-Software auf dem Client zurückgesendet, die es entkapselt und an den Netzwerkstapel zurückleitet kann an die Client-Anwendung ausgeliefert werden.