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.
Nachfolgend sind Anleitungen zu finden, wie Ihr Euren Tunnel konfiguriert:
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.16
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.
OLSR - Versionen
Der OpenVPN-Server hat drei ebtables-separierte Bridges für das Mesh, denen die tap-Devices je nach Konfiguration beim jeweiligen erfolgreichen Tunnelaufbau zugeordnet werden:
- br-641: Dual Stack - OLSRv1 mit IPv4 und IPv6 (2a02:60:100::/40)
- br-642: Dual Stack - OLSRv1 mit IPv4 und OLSRv2 für IPv6 (2a02:61::/32) „Projekt v642“; die Verwendung des bei v642 vorgesehenen 4in6 ist freilich möglich aber nicht sinnvoll, da IPv6 über IPv4 (Provider) über OpenVPN gesendet und dann v4 in v6 verkapselt würde...
- br-64a: OLSRv1 mit IPv4 und IPv6, sowie OLSRv2 mit IPv6 stehen zur Verfügung. In dieser Konfiguration wird viel Traffic generiert, und sie erfordert Maßnahmen wie Policy-Routing, damit die Default-Routen nicht konkurrieren.
Es wird empfohlen, eine eigene IP für den Tunnel im Redeemer anzulegen.
Das hat folgende Hintergründe:
- OLSR läuft auf der Bridge und muss nicht neu gestartet werden. Es ist, als ob bloß das Kabel angesteckt würde. Das Tap-Device, sofern nicht als persistent angelegt, würde sonst einen Neustart des OLSRd erfordern.
- OLSR trifft seine Routingentscheidungen durch die Bewertung seiner via UDP gesendeten und empfangenen Pakete. Es erfordert eine IP-Adresse pro Interface. Wenn man eine ebtables-separierte Bridge verwendet (der Tunnelserver ist ein Endpunkt, der direkt Uplink bereitstellen kann, da ist es egal), kann OLSR keine Routingentscheidung oder eben keine manuelle Gewichtung mehr vornehmen. Es würde als vermutlich aller Traffic über den Tunnel laufen, weil der die häufig die beste ETX haben wird.