OpenVPN-Tunnel zu FunkFeuer - Versionsgeschichte

PK: CamelCase zur besseren Unterscheidung von 0xFF und generischem Begriff

2021-05-14T22:31:24Z

CamelCase zur besseren Unterscheidung von 0xFF und generischem Begriff

← Nächstältere Version		Version vom 14. Mai 2021, 22:31 Uhr
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¹.

Damadmai: Damadmai verschob die Seite OpenVPN-Tunnel zu Funkfeuer nach OpenVPN-Tunnel zu FunkFeuer: verlinkung repariert

2020-05-08T19:52:57Z

Damadmai verschob die Seite OpenVPN-Tunnel zu Funkfeuer nach OpenVPN-Tunnel zu FunkFeuer: verlinkung repariert

← Nächstältere Version	Version vom 8. Mai 2020, 19:52 Uhr
(kein Unterschied)

Damadmai: /* OpenVPN Konfiguration am Server */

2019-08-08T11:59:08Z

OpenVPN Konfiguration am Server

← Nächstältere Version		Version vom 8. August 2019, 11:59 Uhr
Zeile 56:		Zeile 56:
	mtu-disc no		mtu-disc no

	Optional wird tuningmtu1500.ovpn ~~eingebunden:~~		Optional wird eingebunden: tuningmtu1500.ovpn
	fragment 1472		fragment 1472
	tun-mtu 1500		tun-mtu 1500
	mssfix		mssfix

Damadmai: OpenVPN Server Config hinzugefügt

2019-08-08T11:27:47Z

OpenVPN Server Config hinzugefügt

← Nächstältere Version		Version vom 8. August 2019, 11:27 Uhr
Zeile 34:		Zeile 34:
	* 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 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.		* 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 tuningmtu1500.ovpn eingebunden:
			fragment 1472
			tun-mtu 1500
			mssfix

Damadmai: Info über verschiedene OLSR Versionen hinzugefügt

2019-01-20T20:40:13Z

Info über verschiedene OLSR Versionen hinzugefügt

← Nächstältere Version		Version vom 20. Januar 2019, 20:40 Uhr
Zeile 8:		Zeile 8:

	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 23:		Zeile 21:

	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.

Pocki am 19. Juni 2018 um 07:38 Uhr

2018-06-19T07:38:42Z

← Nächstältere Version		Version vom 19. Juni 2018, 07:38 Uhr
Zeile 20:		Zeile 20:
	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.

Erich am 31. Januar 2018 um 02:04 Uhr

2018-01-31T02:04:22Z

← Nächstältere Version		Version vom 31. Januar 2018, 02:04 Uhr
Zeile 13:		Zeile 13:
	Nachfolgend sind Anleitungen zu finden, wie Ihr Euren Tunnel konfiguriert:		Nachfolgend sind Anleitungen zu finden, wie Ihr Euren Tunnel konfiguriert:

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

Erich: /* Tunnelserver allgemein */

2018-01-31T02:04:01Z

Tunnelserver allgemein

Neue Seite

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 [[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:

[[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.