In Episode zwei nehmen wir eine andere Perspektive ein und betrachten Netzwerke aus der Sicht des Application Developments. Mein Gast ist Dom und wir unterhalten uns erst einmal über den dreiseitigen RFC 768, also UDP. Wie man in einem Netzwerk freundlich kommuniziert, erklärt Dom dann am Beispiel des UDP-basierten NAT-PMP (NAT-Port Mapping Protocol). Der Informational RFC 6886 ist ein Beispiel für ein simples Protokoll, das sich durch einen rücksichtsvollen Umgang mit begrenzten Ressourcen in einem Heimnetzwerk auszeichnet und von dem man einiges lernen kann. Das dachte man sich wohl auch, als man mit dem Standard RFC 6887 auf NAT-PMP aufsetzte und diesen erweiterte.
Zwei Stunden kürzer und wieder ein anderes Audio Setup. Wird aber. Vielen Dank für das Feedback zur ersten Folge!
| Feed | Enclosure |
|---|---|
| Podcast Feed: Request for Comments (Request for Comments (MPEG-4 AAC Audio)) | MPEG-4 AAC Audio |
| Podcast Feed: Request for Comments (Request for Comments (MP3 Audio)) | MP3 Audio |
| Podcast Feed: Request for Comments (Request for Comments (Opus Audio)) | Opus Audio |
| Podcast Feed: Request for Comments (Request for Comments (Ogg Vorbis Audio)) | Ogg Vorbis Audio |
Shownotes
[shownotes mode=”block”]
Hallo Anna-Lena! Dein Podcast gefällt mir außerordentlich gut. Vor allem deshalb, weil er dem Zuhörer die nötige Muße einräumt, die Zusammenhänge nachvollziehen zu können.
Bei Minute 23:30 ist zu hören, NAT trüge etwas zur Sicherheit bei, indem das NAT-System Pakete verwirft, die es nicht zuordnen kann. Vorsicht! :-) Traditional NAT spezifiziert dieses Verhalten nicht. Wie mit jenen Paketen verfahren wird, hängt von der konkreten NAT-Implementierung ab.
Zitat aus der FAQ der Newsgroup de.comp.security.firewall http://altlasten.lutz.donnerhacke.de/mitarb/lutz/usenet/Firewall.html#NAT zur Frage “Ist NAT ein ausreichender Schutz für Surfer?”: “Erreicht einen NAT-Router ein Paket für eine umgesetze Adresse, so wird er versuchen, irgendwie den eigentlichen Empfänger zu erraten und das Paket zuzustellen. Das gilt insbesondere dann, wenn der NAT-Router keine intime Protokollkenntnis der Anwendung hat. Oft besteht keine Chance für den NAT-Router, selbst bei Kenntnis des Protokolls, den Empfänger sicher zu ermitteln. Dann wird mittels einer Heuristik der Empfänger erraten. Dies gilt insbesondere bei verschlüsselten Verbindungen und verbindungslosen Protokollen. Ein NAT-Router ist deswegen keine Sicherheitskomponente.”
Mit anderen Worten: NAT ermöglicht Kommunikation zwischen Hosts, die eigentlich nicht miteinander reden können. So gesehen untergräbt NAT die Sicherheit. ;-)
Ein kleiner Hinweis: Dom redete mehrmals von “broadcast” Adressen auf die Geräte hören würden. In der Tat werden aber Multicast Adressen genutzt. Für den eigentlichen mDNS Dienst 224.0.0.51 (siehe https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/NetServices/Introduction.html). Zudem gibt es auch eine Reihe von reservierten Multicast Adressen (z.B 224.0.0.1 für alle “Hosts”, 224.0.0.2 für alle Router, siehe http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml).
Jupp, Du hast recht. Ist uns nachher auch aufgefallen. Gemeint war Multicast.. :)
Falls Unitymedia genauso tickt wie Vodafone/KabelD, dann hast Du auf deren Webseite im Kundenbereich die Möglichkeit, Deinen kompletten Anschluss in den “Bridgemode” zu setzen. Wenn Dein UBNT Router dann den DHCP Request nach “oben” macht, bekommt er die öffentliche IP und keine RFC1918 Adresse (vorausgesetzt Dein ISP macht kein CGN).
Das erspart Dir vielleicht eine unnötige Indirektionsschicht.
Ahoi,
ich glaube man soll nicht auf 0.0.0.0 binden, weil man dann auf dem Socket nicht mehr erkennen kann, auf welchem Interface eine Broadcastmessage reinkam. Ich erinnere mich da dunkel an so ein Problem das ich mal hatte.
IPv6 von Unitymedia in Hessen? Dann hast du sogar Dreifach-NAT bei v4, da UM in Hessen und NRW nur IPv4 nativ ohne IPv6 oder Dual-Stack-Lite macht.