Get best of the week

Migration von OpenVPN zu WireGuard, um Netzwerke zu einem L2-Netzwerk zusammenzuführen



Ich möchte die Erfahrung der Kombination von Netzwerken in drei geografisch abgelegenen Wohnungen teilen, in denen Router mit OpenWRT jeweils als Gateway zu einem gemeinsamen Netzwerk verwendet werden. Bei der Auswahl einer Methode zum Kombinieren von Netzwerken zwischen L3 mit dem Routing von Subnetzen und L2 mit Bridging, wenn sich alle Knoten des Netzwerks im selben Subnetz befinden, wurde die zweite Methode bevorzugt, die schwieriger zu konfigurieren war, aber mehr Möglichkeiten bot, da das Netzwerk transparente Technologien verwenden sollte Wake-on-Lan und DLNA.

Teil 1: Hintergrund


OpenVPN wurde ursprünglich als Protokoll für die Implementierung dieser Aufgabe ausgewählt, da zum einen ein Tap-Gerät erstellt werden kann, das problemlos zur Bridge hinzugefügt werden kann, und zum anderen unterstützt OpenVPN den TCP-Protokollbetrieb, was ebenfalls wichtig war, da Keine der Wohnungen hatte eine dedizierte IP-Adresse, und ich konnte STUN nicht verwenden, da mein Provider aus irgendeinem Grund eingehende Verbindungen über UDP aus ihren Netzwerken blockiert, während TCP es mir ermöglichte, den Port des VPN-Servers an weiterzuleiten geleaste VPS mit SSH. Ja, dieser Ansatz ist sehr belastend, da die Daten zweimal verschlüsselt werden. Ich wollte jedoch kein VPS in mein privates Netzwerk eingeben, da das Risiko bestand, dass Dritte die Kontrolle darüber erlangenEin solches Gerät im Heimnetzwerk zu haben, war äußerst unerwünscht und es wurde beschlossen, die Sicherheit mit einem hohen Overhead zu bezahlen.

Um den Port auf dem Router weiterzuleiten, auf dem der Server bereitgestellt werden sollte, wurde das Programm sshtunnel verwendet. Ich werde die Feinheiten seiner Konfiguration nicht beschreiben - dies ist recht einfach, ich stelle nur fest, dass seine Aufgabe darin bestand, den TCP-Port 1194 vom Router an VPS weiterzuleiten. Als nächstes wurde der OpenVPN-Server auf dem tap0-Gerät konfiguriert, das in der br-lan-Brücke landete. Nachdem ich die Verbindung zu dem Server überprüft hatte, den Sie gerade vom Laptop aus erstellt hatten, wurde klar, dass sich die Idee der Portweiterleitung ausgezahlt hatte und mein Laptop Mitglied des Routernetzwerks wurde, obwohl ich physisch nicht dort war.

Die Angelegenheit blieb klein: Es war notwendig, IP-Adressen in verschiedenen Wohnungen zu verteilen, damit sie nicht in Konflikt gerieten, und Router als OpenVPN-Clients zu konfigurieren.
Die folgenden Router-IP-Adressen und DHCP-Serverbereiche wurden ausgewählt:

  • 192.168.10.1 mit einem Bereich von 192.168.10.2 - 192.168.10.80 für den Server
  • 192.168.10.100 mit einem Bereich von 192.168.10.101 - 192.168.10.149 für den Router in Wohnung Nr. 2
  • 192.168.10.150 mit einem Bereich von 192.168.10.151 - 192.168.10.199 für den Router in Wohnung Nr. 3

Diese Adressen mussten auch den Client-Routern des OpenVPN-Servers zugewiesen werden, indem der Konfiguration die folgenden Zeilen hinzugefügt wurden:

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

und Hinzufügen der folgenden Zeilen zur Datei /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

Dabei sind flat1_id und flat2_id die Gerätenamen, die beim Erstellen von Zertifikaten für die Verbindung mit OpenVPN angegeben werden

Als nächstes wurden OpenVPN-Clients auf den Routern konfiguriert, tap0-Geräte auf beiden wurden der br-lan-Brücke hinzugefügt. Zu diesem Zeitpunkt schien alles in Ordnung zu sein, da sich alle drei Netzwerke sehen und als Ganzes arbeiten. Es stellte sich jedoch als nicht sehr angenehmes Detail heraus: Manchmal konnten Geräte keine IP-Adresse von ihrem Router erhalten, was alle Konsequenzen hatte. Aus irgendeinem Grund hatte der Router in einigen Apartments keine Zeit, rechtzeitig auf DHCPDISCOVER zu antworten, und das Gerät erhielt seine Adresse nicht. Ich erkannte, dass ich solche Anforderungen in tap0 auf jedem der Router filtern muss, aber wie sich herausstellte, können iptables nicht mit dem Gerät funktionieren, wenn es Teil der Bridge ist und ebtables mir helfen sollten. Leider war es nicht in meiner Firmware und ich musste die Images für jedes Gerät neu erstellen.Nachdem dies geschehen war und solche Zeilen zu /etc/rc.local jedes Routers hinzugefügt wurden, wurde das Problem gelöst:

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

Diese Konfiguration dauerte drei Jahre.

Teil 2: Einführung in WireGuard


Vor kurzem wurde im Internet immer mehr über WireGuard gesprochen, wobei die Einfachheit der Konfiguration, die hohe Übertragungsgeschwindigkeit und der niedrige Ping-Wert bei vergleichbarer Sicherheit bewundert wurden. Die Suche nach zusätzlichen Informationen über ihn machte deutlich, dass sie weder die Arbeit als Mitglied der Bridge noch die Arbeit mit dem TCP-Protokoll unterstützten, was mich glauben ließ, dass es für mich immer noch keine Alternativen zu OpenVPN gab. Also habe ich es verschoben, WireGuard kennenzulernen.

Vor einigen Tagen wurde über die Ressourcen, die auf die eine oder andere Weise mit der IT verbunden sind, bekannt, dass WireGuard ab Version 5.6 endlich im Linux-Kernel enthalten sein wird. Nachrichtenartikel lobten wie immer WireGuard. Ich machte mich erneut auf die Suche nach Möglichkeiten, das gute alte OpenVPN zu ersetzen. Diesmal bin ich auf diesen Artikel gestoßen. Es ging um den Bau eines Ethernet-Tunnels über L3 mit GRE. Dieser Artikel gab mir Hoffnung. Es blieb unklar, was mit dem UDP-Protokoll zu tun ist. Die Suche führte mich zu Artikeln über die Verwendung von socat in Verbindung mit einem SSH-Tunnel zum Weiterleiten eines UDP-Ports. Sie stellten jedoch fest, dass dieser Ansatz nur im Einzelverbindungsmodus funktioniert, dh die Arbeit mehrerer VPN-Clients wäre unmöglich. Ich hatte die Idee, einen VPN-Server auf VPS zu erstellen und GRE für Clients einzurichten. Wie sich jedoch herausstellte, unterstützt GRE keine Verschlüsselung, was dazu führt, dass beim Zugriff Dritter auf den Server der gesamte Datenverkehr zwischen meinen Netzwerken in ihren Händen liegt das passte mir grundsätzlich nicht.

Auch hier wurde die Entscheidung zugunsten einer übermäßigen Verschlüsselung getroffen, indem ein VPN über ein VPN gemäß dem folgenden Schema verwendet wurde:

VPN der ersten Ebene:
VPS ist ein Server mit einer internen Adresse von 192.168.30.1
MS ist ein VPS- Client mit einer internen Adresse von 192.168.30.2
MK2 ist ein VPS- Client mit einer internen Adresse von 192.168.30.3
MK3 ist ein VPS- Client mit einer internen Adresse von 192.168.30.3 MK2 ist ein

VPN der zweiten Ebene:
MS ist ein Server mit einer externen Adresse 192.168.30.2 und einer internen Adresse 192.168.31.1
MK2 ist ein MS- Client mit einer Adresse von 192.168.30.2 und einer internen IP 192.168.31.2
MK3 ist ein MS- Clientmit der Adresse 192.168.30.2 und einer internen IP 192.168.31.3

* MS - Router-Server in Wohnung 1, MK2 - Router in Wohnung 2, MK3 - Router in Wohnung 3
* Gerätekonfigurationen werden im Spoiler am Ende des Artikels veröffentlicht.

Wenn also Pings zwischen den Knoten des Netzwerks 192.168.31.0/24 losgehen, ist es an der Zeit, mit dem Einrichten des GRE-Tunnels fortzufahren. Um den Zugriff auf die Router nicht zu verlieren, sollten zuvor SSH-Tunnel eingerichtet werden, um 22 Ports auf dem VPS weiterzuleiten, sodass beispielsweise der Router aus Apartment 2 auf dem 10022. VPS-Port und auf dem 11122. Port der VPS verfügbar ist Der Router stammt aus Apartment 3. Es ist am besten, die Weiterleitung mit demselben Sshtunnel zu konfigurieren, da er den Tunnel wiederherstellt, wenn er herunterfällt.

Wenn der Tunnel konfiguriert ist, können Sie über den weitergeleiteten Port eine Verbindung zu SSH herstellen:

ssh root@_VPS -p 10022

Deaktivieren Sie als Nächstes OpenVPN:

/etc/init.d/openvpn stop

Konfigurieren Sie nun den GRE-Tunnel auf dem Router von Apartment 2 aus:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

Und fügen Sie die erstellte Schnittstelle zur Bridge hinzu:

brctl addif br-lan grelan0

Wir werden ein ähnliches Verfahren auf dem Router-Server durchführen:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

Fügen Sie der Bridge außerdem die erstellte Schnittstelle hinzu:

brctl addif br-lan grelan0

Ab diesem Moment gehen Pings erfolgreich in das neue Netzwerk und ich werde mit Zufriedenheit Kaffee trinken. Um zu bewerten, wie das Netzwerk am anderen Ende des Kabels funktioniert, versuche ich, eine Verbindung über SSH zu einem der Computer in Wohnung 2 herzustellen, aber der SSH-Client friert ein, ohne nach einem Kennwort zu fragen. Ich versuche, über Telnet eine Verbindung zu diesem Computer mit Port 22 herzustellen, und ich sehe eine Zeile, aus der hervorgeht, dass die Verbindung hergestellt wird. Der SSH-Server antwortet, bietet mir jedoch aus irgendeinem Grund nicht an, mich anzumelden.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Ich versuche, eine Verbindung über VNC herzustellen, und sehe einen schwarzen Bildschirm. Ich versichere mir, dass es sich um einen Remotecomputer handelt, da ich von dieser Wohnung aus unter der internen Adresse problemlos eine Verbindung zum Router herstellen kann. Ich entscheide mich jedoch, über einen Router eine Verbindung zum SSH dieses Computers herzustellen, und bin überrascht, dass die Verbindung erfolgreich ist und der Remotecomputer ordnungsgemäß funktioniert, aber auch keine Verbindung zu meinem Computer herstellen kann.

Ich entferne das grelan0-Gerät von der Bridge und starte OpenVPN auf dem Router in Apartment 2 und stelle sicher, dass das Netzwerk wieder wie erwartet funktioniert und die Verbindungen nicht unterbrochen werden. Wenn ich suche, stoße ich auf Foren, in denen sich Leute über dieselben Probleme beschweren und denen geraten wird, die MTU zu erhöhen. Ich konnte die MTU für das VPN der ersten Ebene (wg0) jedoch nicht erhöhen: Bei MTUs über 1420, die automatisch eingestellt werden, beginnen die Pausen, aber gleichzeitig funktionierte das VPN der zweiten Ebene wg1, das über wg0 arbeitet, ordnungsgemäß mit der MTU 1600. Dies reicht für die Installation aus Die MTU für das Gretap-Gerät beträgt 1500, sodass diese Schnittstelle den gleichen MTU-Wert hat wie die br-lan-Brücke, zu der Gretap hinzugefügt werden soll. So wie ich es verstehe, setzt die Bridge die MTU gleich dem kleineren der verfügbaren Werte auf allen Geräten.

Ich habe eine ähnliche Konfiguration auf dem Router aus Apartment 3 vorgenommen, mit dem einzigen Unterschied, dass der Server auf dem Router eine zweite Gretap-Schnittstelle namens grelan1 hinzugefügt hat, die auch der br-lan-Brücke hinzugefügt wurde.

Alles arbeitet. Jetzt können Sie die Gretap-Baugruppe beim Start platzieren.

Gehen Sie dazu folgendermaßen vor: Setzen Sie diese Zeilen in /etc/rc.local auf den Router in Apartment 2:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

Dies wurde zu /etc/rc.local auf dem Router in Apartment 3 hinzugefügt:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

Und auf dem Server-Router:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 1500
ip link set grelan1 up
brctl addif br-lan grelan1

Nach dem Neustart der Client-Router stellte ich fest, dass sie aus irgendeinem Grund keine Verbindung zum Server herstellten. Nachdem eine Verbindung zu ihrem SSH hergestellt wurde (zum Glück habe ich sshtunnel dafür vorkonfiguriert), wurde festgestellt, dass WireGuard aus irgendeinem Grund eine Route für den Endpunkt erstellt hat, diese war jedoch falsch. Für 192.168.30.2 gab die Routentabelle die Route über die pppoe-wan-Schnittstelle an, dh über das Internet, obwohl die Route dorthin über die wg0-Schnittstelle hätte geroutet werden müssen. Nach dem Löschen dieser Route wurde die Verbindung wiederhergestellt. Ich konnte nirgendwo Anweisungen finden, wie WireGuard diese Routen nicht erstellen kann. Außerdem habe ich nicht einmal verstanden, dass eine Funktion OpenWRT oder WireGuard selbst ist. Ohne mich lange mit diesem Problem befassen zu müssen, habe ich diesem Router eine Zeile zu dem Skript hinzugefügt, das von einem Timer zur Timer-Schleife durchgeschleift wurde:

route del 192.168.30.2

Zusammenfassen


Ich habe OpenVPN noch nicht vollständig abgelehnt, da ich manchmal von einem Laptop oder Telefon aus eine Verbindung zu einem neuen Netzwerk herstellen muss und das Einrichten eines Gretap-Geräts auf diesen im Allgemeinen unmöglich ist. Trotzdem habe ich einen Vorteil bei der Datenübertragungsgeschwindigkeit zwischen Wohnungen und zum Beispiel verursacht die Verwendung von VNC jetzt keine Unannehmlichkeiten. Der Ping nahm leicht ab, wurde jedoch stabiler:

Bei Verwendung von OpenVPN:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

Bei Verwendung von WireGuard:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

Es ist stärker von dem hohen Ping vor VPS betroffen, der ungefähr 61,5 ms beträgt.

Die Geschwindigkeit hat sich jedoch erheblich erhöht. In einer Wohnung mit einem Router-Server habe ich eine Internetverbindungsgeschwindigkeit von 30 Mbit / s und in anderen Wohnungen 5 Mbit / s. Gleichzeitig konnte ich bei Verwendung von OpenVPN laut iperf keine Datenübertragungsrate zwischen Netzwerken von mehr als 3,8 Mbit / s erreichen, während WireGuard diese auf die gleichen 5 Mbit / s „pumpte“.

WireGuard-Konfiguration auf VPS
[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <___VPS>

[Peer]
PublicKey = <__VPN_1_>
AllowedIPs = 192.168.30.2/32

[Peer]
PublicKey = <__VPN_2_2>
AllowedIPs = 192.168.30.3/32

[Peer]
PublicKey = <__VPN_2_3>
AllowedIPs = 192.168.30.4/32

WireGuard-Konfiguration auf MS (hinzugefügt zu / etc / config / network)
#VPN   - 
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key '__VPN_1_'
        option auto '1'

config wireguard_wg0
        option public_key '__VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP__VPS'

#VPN   - 
config interface 'wg1'
        option proto 'wireguard'
        option private_key '__VPN_2_'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '1600'

config wireguard_wg1
        option public_key '__VPN_2_2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
        option public_key '__VPN_2_3'
        list allowed_ips '192.168.31.3'


WireGuard-Konfiguration auf MK2 (hinzugefügt zu / etc / config / network)
#VPN   - 
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key '__VPN_1_2'
        option auto '1'

config wireguard_wg0
        option public_key '__VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP__VPS'

#VPN   - 
config interface 'wg1'
        option proto 'wireguard'
        option private_key '__VPN_2_2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '1600'

config wireguard_wg1
        option public_key '__VPN_2_'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'


WireGuard-Konfiguration auf MK3 (hinzugefügt zu / etc / config / network)
#VPN   - 
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key '__VPN_1_3'
        option auto '1'

config wireguard_wg0
        option public_key '__VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP__VPS'

#VPN   - 
config interface 'wg1'
        option proto 'wireguard'
        option private_key '__VPN_2_3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '1600'

config wireguard_wg1
        option public_key '__VPN_2_'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'


In den beschriebenen Konfigurationen für das VPN der zweiten Ebene gebe ich den 51821-Port für WireGuard-Clients an. Im Prinzip ist dies nicht erforderlich, da der Client eine Verbindung von jedem freien, nicht privilegierten Port herstellt, aber ich habe es so gemacht, dass ich alle eingehenden Verbindungen auf den wg0-Schnittstellen aller Router außer blockieren kann eingehende UDP-Verbindungen zu Port 51821.

Ich hoffe, dieser Artikel ist für jemanden nützlich.

PS Außerdem möchte ich mein Skript freigeben, das mir eine PUSH-Benachrichtigung auf dem Telefon an die WirePusher-Anwendung sendet, wenn ein neues Gerät in meinem Netzwerk angezeigt wird. Hier ist der Link zum Skript: github.com/r0ck3r/device_discover .

UPDATE: OpenVPN-Server und -Clients konfigurieren

OpenVPN-Server
client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo


OpenVPN-Client
client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3



Zum Generieren von Zertifikaten verwendet easy-rsa

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles