To Nat or not to Nat

Geschrieben von Beat Rubischon (Link) am Montag, 12. Juni 2006, 21:17 aus dem networking dept. Letzte Woche hatte ich einen Kunden, der ein NFS Share durch ein NAT hindurch mountet. Ich überlegte mir lange, warum ich das eine schlechte Idee finde und möchte Euch diese Gedanken nicht vorenthalten. In der heutigen Welt ist NAT an der Tagesordnung. Nur wenige Spinner setzen ihre Workstations ins public Internet. Man versteckt sein Netz hinter einer Firewall, die NAT macht und ist so unerreichbar aus dem Netz. Für einige Protokolle ist das kein Problem - zum Beispiel HTTP, SSH, POP, IMAP, SMB aka CIFS etc. All das, was auf einer einzelnen TCP Verbindung basiert. Auch UDP geht weitgehendst problemlos. So zum Beispiel DNS. Dann kommen die Protokolle, die ohne Hilfe der Firewall nicht funktionieren. So zum Beispiel FTP oder DCC im IRC. Hier wird eine IP Nummer über einen stehenden TCP Kanal geschickt, die von der Gegenstelle als Kontaktpunkt verwendet wird. Diese IP muss von der Firewall modifiziert werden, damit das Protokoll weiterhin funktioniert. Dann gibt es Protokolle, zu denen es nicht wirklich solche Helper gibt. H.323, SIP, PPTP. Bei den ersten beiden ist die IP Nummer derart Scheisse verpackt, dass ein Helper keine Chance hat, sie zu tracken. Bei PPTP werden die Daten über ein eigenes Protokoll - GRE - verschickt, welches keine Portnummern kennt. Einer kann hinter einem NAT PPTP benutzen - danach ist Schluss. IPSec hinkt am selben Problem und bringt zusätzlich noch die Problematik mit sich, dass die IP Nummer ein Bestandteil der signierten Daten darstellt. Sie zu ändern macht das Paket kaputt. Mit einem riesigen Murks wurde IPSec so zurechtgestutzt, dass es nur noch eine UDP Verbindung benötigt - auf die daraus resultierenden Probleme gehe ich hier aber besser nicht ein. Und dann haben wir die ganze RPC Geschichte. Egal ob SUNRPC oder DCERPC aka MSRPC - beide haben die Eigenschaft, dass es nicht wirklich Server und Client gibt, sondern zwei gleichberechtigte Partner, die sich Messages senden. Sei dies beispielsweise bei Exchange und Outlook - bekommt ein User eine Mail, so signalisiert der Exchange dem Outlook diese. Outlook muss daher nicht die ganze Zeit den Server pollen - auf Kosten der NAT-barkeit des Protokolles. Während alle für eine Exchange MAPI-Verbindung ein VPN ausrollen, wird NFS gerne einmal über ein NAT gemountet - und wir sind am Anfang dieses Artikels. Bestellt der Client beim Server ein Datenpaket, so wird die Antwort den Weg zum Client finden. Egal ob UDP oder TCP unter dem NFS benutzt wird. Dann kommt aber das Locking - bestellt ein Client einen Lock, so geht auch das noch gut. Eine Stunde später gibt ein anderer Client den Lock frei, der Lockserver will den ersten Client darüber informieren - wird aber durch die verfallene Session nie damit Erfolg haben. Noch schlimmer wird es mit NFSv3. Mein Programm macht einen write() und einen fsync(). Der Client speichert den Datenblock im Memory und schickt ihn an den Server. Ohne eine Quittung abzuwarten übergibt der Kernel dem Programm die Kontrolle. Der Server schreibt nun das Datenpaket auf die Platte und gibt dem Client die Quittung zurück. Bleibt diese aus, so wird der Client früher oder später das Paket noch einmal senden. Um die ganze Cache- und Locksynchronisation über Reboots zu informieren, existiert der rpc.statd - Clients wie Server informieren damit ihre Partner über ihren eigenen Zustand. Was, wenn nun Sessions ablaufen? Das ganze Cache und Lockmanagement gerät aus den Fugen, Datenverluste sind an der Tagesordnung. Was, wenn mehrere Clients von derselben IP her kommen? Der Server hat keine Chance herauszufinden, welcher Client es genau war, der einen Lock bestellt hat und wird ihn nicht mehr wegwerfen. Wenn ein Client sagt, lieber Server, schmeiss bitte alles weg was ich gesagt habe, ich bin frisch gebootet worden? Der Server wird alle offenen Transaktionen wegschmeissen. Datenverlust pur. Ich muss aufhören, solches Wissen als Grundvoraussetzung für den Betrieb einer UNIX, BSD oder Linux Umgebung vorauszusetzen. Und ich werde lernen müssen zu akzeptieren, dass es Leute gibt, die solche Probleme hinnehmen... Permalink

Das Kleingedruckte: Der Besitzer der folgenden Kommentare ist wer immer sie eingeschickt hat. Wir sind in keiner Weise für sie verantwortlich.