OpenVPN-Tunnel zu FunkFeuer

Funkfeuer betreibt im Housing einen OpenVPN-Server mit dedizierten Tunnelports.

Der Sinn dieses Tunnelservers ist es, über kommerzielle Providernetze

• entlegene Standorte, wo bisher kein Funkfeuer-Signal zu empfangen ist, an das restliche Netz anzubinden. Wir nennen solche Knoten eine „Funkinsel“.
• wichtige Standorte -das sind vor allem Transitknoten- mittels einer Backupleitung an das restliche Funkfeuer-Netz anzukoppeln.

OpenVPN ist dann im Vorteil, wenn der kommerzielle Anbieter Carrier Grade NAT (CGN), also kaskadiertes NAT verwendet, wie etwa bei der Mehrheit der „Mobilem Breitband“-Angebote. Die UDP-Pakete passieren es in aller Regel problemlos¹.

Wer einen Tunnel dieser Art benötigt, schreibt seinen Wunsch mit Erläuterungen seines Vorhabens an die [Mailingliste „Wien“]. Die Administratoren des Tunnelservers werden darauf mit Konfigurationsdaten antworten oder Rückfragen stellen.

Derzeit erlaubt der Tunnelserver nur mittels OLSRv1 zu routen. Das soll sich in Kürze ändern, wenn auch OLSRv2 unterstützt wird.

Nachfolgend sind Anleitungen zu finden, wie Ihr Euren Tunnel konfiguriert:

OpenVPN mit EdgeRouter X-SFP OpenVPN mit Debian/Ubuntu OpenVPN mit LEDE/OpenWRT oder „Bubbles“

1: Wenn doch einmal Problem auftreten, liegt es daran, dass die Pakete beim Verkapseln „aufgebläht“ werden, also um Overhead angereichert werden. Das sorgt insbesondere mit 3G/UMTS-Sticks, die noch als virtuelles serielles Modem angesprochen werden, im Zusammenspiel mit CGN mitunter Probleme, denn CGN unterdrücken in eine Richtung Antwortpakete für eine automatische Ermittlung der höchzulässigen Paketgröße mittels Path MTU Discovery (PMTUd). Moderne LTE-Sticks verhalten sich selbst wie Router und regeln das Problem der Fragmentierung, also das Zerlegen und Zusammenfügen zu grosser Pakete zumeist selbständig - zumindest für TCP. Bei UDP klappt das nicht immer - da muss die effektive MTU ermittelt und im Tunnel eingestellt werden. Dazu sendet Ihr mittels ping-Befehl ein Paket mit höherer Nutzlast als üblich, sowie mit „Don't Fragment Flag“. Der höchste Wert, bei dem eine Antwort zurückkommt, ist der, den die Tunnel berücksichtigen müssten.

• ping -c1 -M do -s1472 78.41.115.228

Dieser Befehl sendet dem Tunnelserver eine Antwortanfrage mittels ICMP echo request. Die Nutzlast von 1472 Byte wird um 8 Byte ICMP-Header und um 20 Byte IP-Header vermehrt. Das ergibt in Summe 1500 Byte. Für PPP-Verbindungen ist die MTU üblicherweise 1492 Byte. Es sind somit nur 1464 Byte Nutzdaten möglich. Bei manchen DSL-Anschlüssen, sofern das Modem und der Provider dabei mitspielt, kann man Baby Jumbo Frames nach RFC4638 verwenden, um effektiv wieder eine MTU von 1500 zu erhalten. Die fehlenden Bytes werden dabei „oben drauf gelegt“, sodass der übertragene Frame 1508 oder im Fall eines VLANs über DSL (v.a. bei VDSL/PPPoE gebräuchlich), 1512 Byte Nutzdaten umfasst. Steht diese Option nicht offen, bleibt nur, solange den Anfangswert des obigen Ping-Befehls zu reduzieren, bis der Server erstmals mit einer Laufzeit in Millisekunden (ms) antwortet. Dieser Wert plus 28 (20+8) ergibt eure effektive MTU.