[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel 3.1 und UDP (OpenVPN) - Pakete an vermeintliche Broadcast-Adresse



Hallo Dirk, Hallo alle anderen

Dirk schrub am Sun, 5 Feb 2012 13:17:44 +0100:
> Hallo Leute,
> 
> ich nutze OpenVPN schon seit Jahren erfolgreich über das UDP
> Protokoll. Einer meiner Clients hat vom ISP eine XXX.XXX.XXX.255
> Internetadresse zugewiesen bekommen. Seitdem ich den Kernel des
> Servers auf Version 3.1 aktualisiert habe, kann der eine bewusste
> Client keine Verbindung mehr mit dem Server aufbauen. 

Eine IP-Adresse mit .255 im letzten Doppelbyte muss kein Problem
sein, denn ob es eine Broadcast-Adresse ist, ergibt sich aus der
Netzmaske.

Aber warum aktualisiert man auf einem Server den Kernel auf eine
ungerade Version? Oder sind die ungeraden Versionen keine
Entwicklerversionen mehr?

Ich hab bei mir noch den 3.0er drauf und keine Probleme mit OpenVPN.

> Da ich mit der .255er Client auf OpenVPN-Server mit 2.6 Kernel über
> UDP Kontakt aufnehmen kann, muss es an der Kernelversion 3.1 liegen.
> Nun habe ich als Hack auf das TCP Protokoll umgestellt, bin nur
> nicht sehr zufrieden mit der Performance.

Naja, hier werden die Pakete bestätigt. UDP-Pakete werden
"rausgefeuert" und gut ist. Wenn alle beim Empfänger ankommen, ist
das natürlich schneller und es bringt auch keine Probleme. 

Wenn aber Pakete verloren gehen, wird das auf der IP-Verbindungsebene
nicht bemerkt und der Tunnel kann einfach so zusammenbrechen. Sicher
baut OpenVPN den dann wieder neu auf - aber das dauert dann und
wahrscheinlich sind auch Daten weg. 
UDP würde ich also für eine VPN-Verbindung wirklich nur in einem
stabilen Netz einsetzen. Aber über das Internet?

> Hat jemand einen Rat für mich, wie ich das Problem gelöst bekomme?

Ich denke, du hast schon eine gute Lösung gefunden. Klar ist TCP
wegen der Empfangsbestätigung jedes Paketes ein wenig langsamer, aber
geht ein Paket verloren, wird es nach fehlender Empfangsquittung eben
noch einmal gesendet.

-- 
LG Maxx


Reply to: