OpenVPN-Tunnel zu FunkFeuer: Unterschied zwischen den Versionen

Aus FunkFeuer Wiki
Zur Navigation springen Zur Suche springen
K (CamelCase zur besseren Unterscheidung von 0xFF und generischem Begriff)
 
(5 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Funkfeuer betreibt im Housing einen OpenVPN-Server mit dedizierten Tunnelports.
FunkFeuer betreibt im Housing einen OpenVPN-Server mit dedizierten Tunnelports.


Der Sinn dieses Tunnelservers ist es, über kommerzielle Providernetze
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“.
* 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.
* 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¹.
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 [[mailto:wien@lists.funkfeuer.at Mailingliste „Wien“]]. Die Administratoren des Tunnelservers werden darauf mit Konfigurationsdaten antworten oder Rückfragen stellen.
Wer einen Tunnel dieser Art benötigt, schreibt seinen Wunsch mit Erläuterungen seines Vorhabens an die [[mailto:wien@lists.funkfeuer.at 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:
Nachfolgend sind Anleitungen zu finden, wie Ihr Euren Tunnel konfiguriert:
Zeile 20: Zeile 18:
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.
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
* 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.
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.
== OpenVPN Konfiguration am Server ==
Standardmäßig sieht diese folgendermaßen aus:
common2.ovpn
local          78.41.115.16
down-pre
fast-io
# multihome
# mute          3
ping-restart    60
proto          udp4
script-security 2
up-delay
verb            0
# speed tunings
rcvbuf          524288
sndbuf          524288
txqueuelen      1000
auth-nocache
# socket-flags    TCP_NODELAY
mtu-disc        no
Optional wird eingebunden: tuningmtu1500.ovpn
fragment 1472
tun-mtu 1500
mssfix

Aktuelle Version vom 14. Mai 2021, 23:31 Uhr

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.

OpenVPN Konfiguration am Server

Standardmäßig sieht diese folgendermaßen aus: common2.ovpn 

local           78.41.115.16
down-pre
fast-io
# multihome
# mute          3
ping-restart    60
proto           udp4
script-security 2
up-delay
verb            0
# speed tunings
rcvbuf          524288
sndbuf          524288
txqueuelen      1000
auth-nocache
# socket-flags    TCP_NODELAY
mtu-disc        no

Optional wird eingebunden: tuningmtu1500.ovpn 

fragment 1472
tun-mtu 1500
mssfix
Abgerufen von „https://wiki.funkfeuer.at/index.php?title=OpenVPN-Tunnel_zu_FunkFeuer&oldid=3231“