Bevor uns die IPv4-Adressen ausgegangen sind, haben wir NAT (weitgehend) nicht verwendet. Jeder mit dem Internet verbundene Computer hätte eine eigene, weltweit eindeutige Adresse. Als NAT zum ersten Mal eingeführt wurde, ging es darum, den Kunden des ISP eine echte Adresse pro Gerät zuzuweisen, das der Kunde verwendet / besitzt, und einem Kunden eine echte Adresse zuzuweisen. Das hat das Problem für eine Weile (Jahre) behoben, als wir eigentlich auf IPv6 umsteigen wollten. Anstatt auf IPv6 zu wechseln, haben (meistens) alle darauf gewartet, dass alle anderen wechseln, und so hat (meistens) niemand IPv6 eingeführt. Jetzt haben wir wieder dasselbe Problem, aber dieses Mal wird eine zweite NAT-Schicht (CGN) bereitgestellt, damit ISPs eine echte Adresse für mehrere Kunden gemeinsam nutzen können.
Die Erschöpfung von IP-Adressen ist keine große Sache, wenn NAT nicht schrecklich ist, auch wenn der Endbenutzer keine Kontrolle darüber hat (Carrier Grade NAT oder CGN).
Aber ich würde argumentieren, dass NAT schrecklich ist, insbesondere in dem Fall, in dem der Endbenutzer keine Kontrolle darüber hat. Und (als Person, deren Job Netzwerktechnik / -verwaltung ist, die jedoch einen Abschluss als Software-Ingenieur hat) würde ich argumentieren, dass Netzwerkadministratoren durch die Bereitstellung von NAT anstelle von IPv6 das Gewicht der Lösung der Adresserschöpfung von ihrem Feld auf die Endbenutzer verlagert haben und Anwendungsentwickler.
Also (meiner Meinung nach), warum ist NAT eine schreckliche, böse Sache, die vermieden werden sollte?
Mal sehen, ob ich dem gerecht werden kann, indem ich erkläre, was es kaputt macht (und welche Probleme es verursacht, an die wir uns so gewöhnt haben, dass wir nicht einmal merken, dass es besser sein könnte):
- Unabhängigkeit von der Netzwerkschicht
- Peer-to-Peer-Verbindungen
- Konsistente Benennung und Position der Ressourcen
- Optimale Weiterleitung des Datenverkehrs, Hosts kennen ihre wahre Adresse
- Verfolgung der Quelle von böswilligem Datenverkehr
- Netzwerkprotokolle, die Daten und Steuerung in separate Verbindungen trennen
Mal sehen, ob ich jeden dieser Punkte erklären kann.
Unabhängigkeit von der Netzwerkschicht
ISPs sollen nur Layer-3-Pakete weitergeben und sich nicht darum kümmern, was sich in den darüber liegenden Layern befindet. Unabhängig davon, ob Sie TCP, UDP oder etwas Besseres / Exotischeres (SCTP vielleicht? Oder sogar ein anderes Protokoll, das besser als TCP / UDP ist, aber aufgrund mangelnder NAT-Unterstützung unklar ist) verwenden, sollte Ihr ISP dies nicht tun Pflege; Für sie soll alles wie Daten aussehen.
Dies ist jedoch nicht der Fall - nicht, wenn sie die "zweite Welle" von NAT, "Carrier Grade" NAT, implementieren. Dann müssen sie sich unbedingt die Layer 4-Protokolle ansehen und unterstützen, die Sie verwenden möchten. Im Moment bedeutet dies praktisch, dass Sie nur TCP und UDP verwenden können. Andere Protokolle würden entweder nur blockiert / verworfen (in den meisten Fällen meiner Erfahrung nach) oder nur an den letzten Host "innerhalb" des NAT weitergeleitet, der dieses Protokoll verwendet hat (ich habe 1 Implementierung gesehen, die dies ausführt). Selbst die Weiterleitung an den letzten Host, der dieses Protokoll verwendet hat, ist keine echte Lösung - sobald zwei Hosts es verwenden, bricht es.
Ich stelle mir vor, dass es einige Ersatzprotokolle für TCP und UDP gibt, die derzeit nicht getestet und nur aufgrund dieses Problems nicht verwendet werden. Verstehen Sie mich nicht falsch, TCP & UDP waren beeindruckend gut gestaltet und es ist erstaunlich, wie sich beide auf die Art und Weise skalieren ließen, wie wir das Internet heute nutzen. Aber wer weiß, was wir verpasst haben? Ich habe über SCTP gelesen und es hört sich gut an, habe es aber nie benutzt, weil es wegen NAT unpraktisch war.
Peer-to-Peer-Verbindungen
Dies ist eine große. Eigentlich die größte meiner Meinung nach. Wenn Sie zwei Endbenutzer haben, die sich beide hinter ihrem eigenen NAT befinden, wird das NAT des anderen Benutzers das Paket verwerfen, und die Verbindung wird nicht erfolgreich sein.
Dies betrifft Spiele, Sprach- / Video-Chat (wie Skype), das Hosten Ihrer eigenen Server usw.
Es gibt Problemumgehungen. Das Problem ist, dass diese Problemumgehungen entweder Entwicklerzeit, Zeit und Unannehmlichkeiten für Endbenutzer oder Kosten für die Serviceinfrastruktur kosten. Und sie sind nicht narrensicher und brechen manchmal. (Siehe die Kommentare anderer Benutzer zu dem Ausfall von Skype.)
Eine Problemumgehung ist die Portweiterleitung, bei der Sie das NAT-Gerät so programmieren, dass ein bestimmter eingehender Port an einen bestimmten Computer hinter dem NAT-Gerät weitergeleitet wird. Es gibt ganze Websites, auf denen erklärt wird, wie dies für die verschiedenen NAT-Geräte gemacht werden kann. Siehe https://portforward.com/ . Dies kostet den Endbenutzer in der Regel Zeit und Frustration.
Eine weitere Problemumgehung besteht darin, Anwendungen um die Unterstützung von Lücken zu erweitern und die Serverinfrastruktur zu warten, die sich nicht hinter einem NAT befindet, um zwei NAT-Clients einzuführen. Dies kostet normalerweise Entwicklungszeit und versetzt Entwickler in die Lage, die Serverinfrastruktur möglicherweise dort zu warten, wo dies zuvor nicht erforderlich gewesen wäre.
(Erinnern Sie sich, was ich über die Bereitstellung von NAT anstelle von IPv6 gesagt habe, um das Gewicht des Problems von Netzwerkadministratoren auf Endbenutzer und Anwendungsentwickler zu verlagern?)
Konsistente Benennung / Position der Netzwerkressourcen
Da innerhalb eines NAT ein anderer Adressraum als außerhalb verwendet wird, verfügt jeder Dienst, der von einem Gerät innerhalb eines NAT angeboten wird, über mehrere Adressen, über die es erreichbar ist. Die richtige Adresse hängt davon ab, von wo aus der Client auf ihn zugreift . (Dies ist auch dann noch ein Problem, wenn die Portweiterleitung funktioniert.)
Wenn Sie einen Webserver in einem NAT haben, sagen wir an Port 192.168.0.23, Port 80, und Ihr NAT-Gerät (Router / Gateway) hat eine externe Adresse von 35.72.216.228, und Sie richten die Portweiterleitung für TCP-Port 80 ein Auf den Webserver kann entweder über den 192.168.0.23-Port 80 ODER den 35.72.216.228-Port 80 zugegriffen werden. Der zu verwendende Port hängt davon ab, ob Sie sich innerhalb oder außerhalb des NAT befinden. Wenn Sie sich außerhalb des NAT befinden und die Adresse 192.168.0.23 verwenden, gelangen Sie nicht zu dem Punkt, den Sie erwarten. Wenn Sie sich innerhalb des NAT befinden und die externe Adresse 35.72.216.228 verwenden, können Sie möglicherweise dort ankommen, wo Sie möchten, wenn Ihre NAT-Implementierung fortgeschritten ist und Haarnadel unterstütztDer Webserver, der Ihre Anfrage bearbeitet, erkennt die Anfrage jedoch als von Ihrem NAT-Gerät stammend. Dies bedeutet, dass der gesamte Datenverkehr über das NAT-Gerät geleitet werden muss, auch wenn sich hinter dem NAT ein kürzerer Pfad im Netzwerk befindet, und dass Protokolle auf dem Webserver weniger nützlich sind, da alle das NAT-Gerät als Quelle von angeben die Verbindung. Wenn Ihre NAT-Implementierung Haarnadel nicht unterstützt, werden Sie nicht dahin gelangen, wo Sie es erwartet hatten.
Und dieses Problem wird schlimmer, sobald Sie DNS verwenden. Plötzlich, wenn Sie möchten, dass für etwas, das hinter NAT gehostet wird, alles ordnungsgemäß funktioniert, möchten Sie unterschiedliche Antworten auf die Adresse des in einem NAT gehosteten Dienstes geben, je nachdem, wer fragt (Split-Horizon-DNS von AKA, IIRC). Yuck.
Und das alles setzt voraus, dass Sie jemanden haben, der sich mit Portweiterleitung und Haarnadel-NAT und Split-Horizon-DNS auskennt. Was ist mit Endbenutzern? Wie stehen ihre Chancen, alles richtig einzurichten, wenn sie einen Consumer-Router und eine IP-Überwachungskamera kaufen und möchten, dass sie "einfach funktioniert"?
Und das führt mich zu:
Optimale Weiterleitung des Datenverkehrs, Hosts kennen ihre wahre Adresse
Wie wir gesehen haben, fließt der NAT-Verkehr auch mit fortgeschrittenen Haarnadeln nicht immer über den optimalen Pfad. Dies gilt auch für den Fall, dass ein sachkundiger Administrator einen Server einrichtet und über Haarnadel-NAT verfügt. (Zugegeben, Split-Horizon-DNS kann dazu führen, dass der interne Datenverkehr von einem Netzwerkadministrator optimal weitergeleitet wird.)
Was passiert, wenn ein Anwendungsentwickler ein Programm wie Dropbox erstellt und an Endbenutzer verteilt, die sich nicht auf die Konfiguration von Netzwerkgeräten spezialisiert haben? Was passiert konkret, wenn ich eine 4-GB-Datei in meine Freigabedatei lege und dann versuche, auf dem nächsten Computer erneut darauf zuzugreifen? Wird es direkt zwischen den Computern übertragen, oder muss ich warten, bis es über eine langsame WAN-Verbindung auf einen Cloud-Server hochgeladen wird, und dann ein zweites Mal warten, bis es über dieselbe langsame WAN-Verbindung heruntergeladen wird?
Für eine naive Implementierung wird es hochgeladen und dann heruntergeladen, wobei die Serverinfrastruktur von Dropbox verwendet wird, die sich nicht hinter einem NAT als Vermittler befindet. Wenn die beiden Computer jedoch nur feststellen könnten, dass sie sich im selben Netzwerk befinden, könnten sie die Datei einfach viel schneller direkt übertragen. Bei unserem ersten, weniger naiven Implementierungsversuch fragen wir möglicherweise das Betriebssystem, welche IP-Adresse (v4) der Computer hat, und vergleichen Sie dies dann mit anderen Computern, die auf demselben Dropbox-Konto registriert sind. Wenn es sich im selben Bereich wie wir befindet, übertragen Sie die Datei einfach direkt. Das könnte in vielen Fällen funktionieren. Aber auch dann gibt es ein Problem: NAT funktioniert nur, weil wir Adressen wiederverwenden können. Also was ist, wenn die 192.168.0.23 Adresse und die 192.168.0. 42 Adressen, die auf demselben Dropbox-Konto registriert sind, befinden sich tatsächlich in verschiedenen Netzwerken (wie Ihrem Heimnetzwerk und Ihrem Arbeitsnetzwerk)? Jetzt müssen Sie nicht mehr auf die Dropbox-Serverinfrastruktur zurückgreifen, um zu vermitteln. (Letztendlich versuchte Dropbox, das Problem zu lösen, indem jeder Dropbox-Client im lokalen Netzwerk gesendet wurde, in der Hoffnung, andere Clients zu finden. Diese Sendungen kreuzen jedoch keine Router, die sich möglicherweise hinter dem NAT befinden, was bedeutet, dass dies keine vollständige Lösung ist ,vor allem im Fall von CGN .)
Statische IPs
Da der erste Engpass (und die erste Welle von NAT) auftrat, als viele Kundenverbindungen nicht immer über Verbindungen (wie z. B. Einwählen) verfügten, konnten ISPs ihre Adressen besser nutzen, indem sie nur öffentliche / externe IP-Adressen zuwiesen, wenn Sie tatsächlich verbunden waren. Das bedeutet, dass Sie beim Herstellen einer Verbindung die verfügbare Adresse erhalten haben, anstatt immer dieselbe zu erhalten. Dies erschwert die Ausführung Ihres eigenen Servers und die Entwicklung von Peer-to-Peer-Anwendungen, da Peers nicht an festen Adressen arbeiten müssen, sondern sich bewegen müssen.
Verschleierung der Quelle des böswilligen Verkehrs
Da NAT ausgehende Verbindungen so umschreibt, als ob sie vom NAT-Gerät selbst stammen, wird das gesamte Verhalten, ob gut oder schlecht, in einer externen IP-Adresse zusammengefasst. Ich habe kein NAT-Gerät gesehen, das standardmäßig alle ausgehenden Verbindungen protokolliert. Dies bedeutet, dass die Quelle des böswilligen Datenverkehrs in der Vergangenheit standardmäßig nur auf das NAT-Gerät zurückzuführen ist, das es durchlaufen hat. Während mehr Geräte der Enterprise- oder Carrier-Klasse so konfiguriert werden können, dass sie jede ausgehende Verbindung protokollieren, habe ich keine Consumer-Router gesehen, die dies tun. Ich denke auf jeden Fall, dass es interessant sein wird zu sehen, ob (und wie lange) ISPs ein Protokoll aller TCP- und UDP-Verbindungen führen, die über CGNs hergestellt werden, während sie sie ausrollen. Solche Aufzeichnungen wären erforderlich, um Missbrauchsbeschwerden und DMCA-Beschwerden zu bearbeiten.
Einige Leute denken, dass NAT die Sicherheit erhöht. Wenn dies der Fall ist, geschieht dies durch Unbekanntheit. Der von NAT festgelegte Standardverlust an eingehendem Datenverkehr entspricht dem einer Stateful Firewall. Meines Erachtens sollte jede Hardware, die das für NAT erforderliche Verbindungs-Tracking durchführen kann, eine Stateful Firewall ausführen können, sodass NAT dort eigentlich keine Punkte verdient.
Protokolle, die eine zweite Verbindung verwenden
Protokolle wie FTP und SIP (VoIP) verwenden in der Regel separate Verbindungen für die Steuerung und den tatsächlichen Dateninhalt. Für jedes Protokoll, das dies ausführt, muss auf jedem NAT-Gerät, das es durchläuft, eine Hilfssoftware namens ALG (Application Layer Gateway) installiert sein, oder das Problem muss mit einer Art Vermittler oder Locher umgangen werden. Meiner Erfahrung nach werden ALGs selten oder nie aktualisiert und waren die Ursache für mindestens ein paar Probleme, mit denen ich mich mit SIP befasst habe. Jedes Mal, wenn jemand meldet, dass VoIP bei ihm nicht funktioniert hat, weil Audio nur in eine Richtung funktioniert hat, vermute ich sofort, dass irgendwo ein NAT-Gateway UDP-Pakete verwirft, mit denen er nichts anfangen kann.
Zusammenfassend neigt NAT dazu, zu brechen:
- alternative Protokolle zu TCP oder UDP
- Peer-to-Peer-Systeme
- Zugriff auf etwas hinter dem NAT gehostet
- Dinge wie SIP und FTP. ALGs, die dies umgehen, verursachen auch heute noch zufällige und verrückte Probleme, insbesondere bei SIP.
Im Kern ist der mehrschichtige Ansatz des Netzwerkstapels relativ einfach und elegant. Versuchen Sie, es jemandem zu erklären, der neu im Networking ist, und er geht unweigerlich davon aus, dass sein Heimnetzwerk wahrscheinlich ein gutes, einfaches Netzwerk ist, das er zu verstehen versucht. Ich habe gesehen, dass dies in einigen Fällen zu ziemlich interessanten (übermäßig komplizierten) Vorstellungen über die Funktionsweise des Routings geführt hat, da die externen und internen Adressen verwechselt wurden.
Ich vermute, dass VoIP ohne NAT allgegenwärtig und in das öffentliche Telefonnetz integriert wäre und dass das Tätigen von Anrufen über ein Mobiltelefon oder einen Computer kostenlos wäre (mit Ausnahme des Internets, für das Sie bereits bezahlt haben). Warum sollte ich für das Telefon bezahlen, wenn Sie und ich nur einen 64K-VoIP-Stream öffnen können und dieser genauso gut funktioniert wie das öffentliche Telefonnetz? Es scheint, als würde das Hauptproblem bei der Bereitstellung von VoIP heute durch NAT-Geräte gehen.
Ich vermute, wir wissen normalerweise nicht, wie viel einfacher viele Dinge sein könnten, wenn wir die durch NAT unterbrochene End-to-End-Konnektivität hätten. Die Leute mailen (oder Dropboxen) sich immer noch Dateien, weil das Hauptproblem darin besteht, einen Vermittler zu benötigen, wenn sich zwei Clients hinter NAT befinden.