Ich möchte meine Erfahrungen mit der Kombination von Netzwerken in drei geografisch weit entfernten Wohnungen, die jeweils Router mit OpenWRT als Gateway verwenden, zu einem gemeinsamen Netzwerk teilen. Bei der Auswahl einer Methode zum Kombinieren von Netzwerken zwischen L3 mit Subnetz-Routing und L2 mit Bridging, bei der sich alle Netzwerkknoten im selben Subnetz befinden, wurde der zweiten Methode der Vorzug gegeben, die schwieriger zu konfigurieren ist, aber mehr Möglichkeiten bietet, da transparent Der Einsatz von Technologien war im geschaffenen Netzwerk Wake-on-Lan und DLNA geplant.
Teil 1: Hintergrund
Das zur Durchführung dieser Aufgabe gewählte Protokoll war zunächst OpenVPNDenn erstens kann damit ein Tap-Gerät erstellt werden, das problemlos in die Bridge integriert werden kann, und zweitens, OpenVPN Es unterstützt TCP, was ebenfalls wichtig war, da keine der Wohnungen über eine eigene IP-Adresse verfügte. STUN konnte ich nicht nutzen, da mein Internetanbieter aus irgendeinem Grund eingehende UDP-Verbindungen aus seinen Netzwerken blockiert. Dank TCP konnte ich den VPN-Server-Port per SSH an den gemieteten VPS weiterleiten. Obwohl dieser Ansatz einen erheblichen Mehraufwand verursacht, da die Daten doppelt verschlüsselt werden, wollte ich den VPS nicht in mein privates Netzwerk integrieren, da die Gefahr bestand, dass Dritte die Kontrolle darüber erlangen könnten. Daher war ein solches Gerät in meinem Heimnetzwerk äußerst unerwünscht, weshalb ich mich entschied, für mehr Sicherheit einen höheren Aufwand zu betreiben.
Um den Port des Routers, auf dem der Server bereitgestellt werden sollte, weiterzuleiten, verwendete ich das Programm sshtunnel. Auf die Konfiguration gehe ich nicht näher ein – sie ist recht einfach. Es diente lediglich dazu, TCP-Port 1194 vom Router zum VPS weiterzuleiten. Anschließend konfigurierte ich den Server. OpenVPN Auf dem Gerät tap0, das mit der br-lan-Bridge verbunden war. Nachdem ich die Verbindung zum neu erstellten Server von meinem Laptop aus getestet hatte, wurde deutlich, dass die Portweiterleitung funktioniert hatte und mein Laptop nun Teil des Router-Netzwerks war, obwohl er physisch nicht dazu gehörte.
Es blieb nur noch, die IP-Adressen auf die verschiedenen Wohnungen zu verteilen, damit es keine Konflikte gab, und die Router entsprechend zu konfigurieren. OpenVPN-Kunden.
Die folgenden Router-IP-Adressen und DHCP-Serverbereiche wurden ausgewählt:
- 192.168.10.1 mit Reichweite 192.168.10.2 - 192.168.10.80 für den Server
- 192.168.10.100 mit Reichweite 192.168.10.101 - 192.168.10.149 für einen Router in Wohnung Nr. 2
- 192.168.10.150 mit Reichweite 192.168.10.151 - 192.168.10.199 für einen Router in Wohnung Nr. 3
Es war außerdem notwendig, diese Adressen den Client-Routern zuzuweisen. OpenVPN-Server, indem Sie die folgende Zeile zu seiner Konfiguration hinzufügen:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0und Hinzufügen der folgenden Zeilen zur Datei /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
wobei flat1_id und flat2_id die Gerätenamen sind, die beim Erstellen von Zertifikaten für die Verbindung zu angegeben wurden OpenVPN
Als nächstes wurden die Router konfiguriert. OpenVPNDie Clients und tap0-Geräte beider Router wurden zur br-lan-Bridge hinzugefügt. Zunächst schien alles in Ordnung, da alle drei Netzwerke einander erkennen und als Einheit funktionieren konnten. Es trat jedoch ein unangenehmes Problem auf: Manchmal erhielten Geräte eine IP-Adresse vom falschen Router, was entsprechende Konsequenzen nach sich zog. Aus irgendeinem Grund reagierte der Router in einer der Wohnungen nicht rechtzeitig auf DHCPDISCOVER, und das Gerät erhielt die falsche Adresse. Mir wurde klar, dass ich solche Anfragen in tap0 auf jedem Router filtern musste. Wie sich herausstellte, funktioniert iptables jedoch nicht mit Geräten, die Teil einer Bridge sind, weshalb ich ebtables verwenden musste. Da meine Firmware dies leider nicht enthielt, musste ich die Images für jedes Gerät neu erstellen. Nachdem ich dies getan und die folgenden Zeilen in die Datei /etc/rc.local auf jedem Router eingefügt hatte, war das Problem behoben:
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: Kennenlernen WireGuard
In letzter Zeit wird im Internet vermehrt darüber gesprochen WireGuardIch war von der einfachen Konfiguration, der hohen Übertragungsgeschwindigkeit, dem niedrigen Ping und der vergleichbaren Sicherheit angetan. Eine Suche nach weiteren Informationen ergab jedoch, dass es weder Bridge-Member noch das TCP-Protokoll unterstützt, weshalb ich annahm, es gäbe keine Alternative. OpenVPN Für mich ist das noch nicht da. Deshalb habe ich das Kennenlernen immer wieder aufgeschoben. WireGuard.
Vor einigen Tagen verbreitete sich die Nachricht über Quellen, die in irgendeiner Weise mit IT zu tun haben, dass WireGuard wird schließlich in den Kernel aufgenommen. Linuxab Version 5.6. Die Nachrichtenartikel wurden wie immer gelobt. WireGuardIch stürzte mich erneut in die Suche nach Möglichkeiten, das gute alte zu ersetzen. OpenVPNDieses Mal bin ich auf jemanden gestoßen . Darin ging es um die Erstellung eines Ethernet-Tunnels über L3 mithilfe von GRE. Dieser Artikel hat mir Hoffnung gegeben. Es blieb unklar, was mit dem UDP-Protokoll geschehen soll. Die Suche führte mich zu Artikeln über die Verwendung von socat in Verbindung mit einem SSH-Tunnel zur Weiterleitung eines UDP-Ports. Sie stellten jedoch fest, dass dieser Ansatz nur im Einzelverbindungsmodus funktioniert, was bedeutet, dass mehrere VPN-Clients unmöglich wären. Ich hatte die Idee, einen VPN-Server auf einem VPS einzurichten und GRE für Clients zu konfigurieren, aber wie sich herausstellte, unterstützt GRE keine Verschlüsselung, was dazu führen wird, dass, wenn Dritte Zugriff auf den Server erhalten, Der gesamte Datenverkehr zwischen meinen Netzwerken liegt in ihren Händen, was mir überhaupt nicht gefiel.
Auch hier fiel die Entscheidung zugunsten einer redundanten Verschlüsselung, indem VPN über VPN nach folgendem Schema genutzt wird:
Layer-XNUMX-VPN:
VPS ist Server mit interner Adresse 192.168.30.1
MS ist vom Kunden VPS mit interner Adresse 192.168.30.2
MK2 ist vom Kunden VPS mit interner Adresse 192.168.30.3
MK3 ist vom Kunden VPS mit interner Adresse 192.168.30.4
Layer-XNUMX-VPN:
MS ist Server mit externer Adresse 192.168.30.2 und interner 192.168.31.1
MK2 ist vom Kunden MS mit der Adresse 192.168.30.2 und hat eine interne IP von 192.168.31.2
MK3 ist vom Kunden MS mit der Adresse 192.168.30.2 und hat eine interne IP von 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.
Und so gehen die Pings zwischen den Knoten des Netzwerks 192.168.31.0/24 weiter, es ist Zeit, mit dem Einrichten des GRE-Tunnels fortzufahren. Um den Zugriff auf Router nicht zu verlieren, lohnt es sich vorher, SSH-Tunnel einzurichten, um Port 22 an den VPS weiterzuleiten, sodass beispielsweise ein Router aus Wohnung 10022 auf Port 2 des VPS verfügbar ist und a Router aus Wohnung 11122 wird auf Port 3 des VPS verfügbar sein. Router aus Wohnung XNUMX. Am besten konfigurieren Sie die Weiterleitung mit demselben SSH-Tunnel, da dieser den Tunnel bei einem Ausfall wiederherstellt.
Der Tunnel ist konfiguriert, Sie können über den weitergeleiteten Port eine Verbindung zu SSH herstellen:
ssh root@МОЙ_VPS -p 10022Als Nächstes sollten Sie deaktivieren OpenVPN:
/etc/init.d/openvpn stopNun richten wir einen GRE-Tunnel auf dem Router von Wohnung 2 ein:
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
Führen wir einen ähnlichen Vorgang auf dem Server-Router durch:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Und fügen Sie außerdem die erstellte Schnittstelle zur Bridge hinzu:
brctl addif br-lan grelan0
Von diesem Moment an beginnen Pings erfolgreich in das neue Netzwerk zu gelangen und ich gehe zufrieden Kaffee trinken. Um dann zu sehen, wie das Netzwerk am anderen Ende der Leitung funktioniert, versuche ich, eine SSH-Verbindung zu einem der Computer in Wohnung 2 herzustellen, aber der SSH-Client friert ein, ohne mich zur Eingabe eines Passworts aufzufordern. Ich versuche, über Telnet auf Port 22 eine Verbindung zu diesem Computer herzustellen und sehe eine Zeile, aus der man erkennen kann, dass die Verbindung hergestellt wird, der SSH-Server antwortet, aber aus irgendeinem Grund bietet er mir keinen Zugang an.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Ich versuche, über VNC eine Verbindung herzustellen und sehe einen schwarzen Bildschirm. Ich überzeuge mich davon, dass die Sache am entfernten Computer liegt, da ich mich von dieser Wohnung aus über die interne Adresse problemlos mit dem Router verbinden kann. Ich entscheide mich jedoch, über den Router eine SSH-Verbindung zu diesem Computer herzustellen, und stelle zu meiner Überraschung fest, dass die Verbindung erfolgreich ist und der Remote-Computer einwandfrei funktioniert, aber auch keine Verbindung zu meinem Computer herstellen kann.
Ich nehme das Gerät grelan0 aus der Bridge und starte es. OpenVPN Am Router in Wohnung 2 stellte ich fest, dass das Netzwerk wieder einwandfrei funktionierte und keine Verbindungen mehr abbrachen. Bei meiner Suche stieß ich auf Foren, in denen Nutzer dieselben Probleme schilderten und den Rat erhielten, die MTU zu erhöhen. Gesagt, getan. Doch solange die MTU nicht hoch genug eingestellt war – 7000 für Gretap-Geräte –, traten entweder TCP-Verbindungsabbrüche oder niedrige Übertragungsgeschwindigkeiten auf. Aufgrund der hohen MTU für Gretap war die MTU für Verbindungen WireGuard Die erste und zweite Stufe wurden auf 8000 bzw. 7500 festgelegt.
Ich habe ein ähnliches Setup auf dem Router aus Wohnung 3 durchgeführt, mit dem einzigen Unterschied, dass eine zweite Gretap-Schnittstelle namens grelan1 zum Server-Router hinzugefügt wurde, die auch zur Br-LAN-Bridge hinzugefügt wurde.
Alles arbeitet. Jetzt können Sie die Gretap-Assembly in den Autoload-Modus versetzen. Dafür:
Habe diese Zeilen in /etc/rc.local auf dem Router in Apartment 2 platziert:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
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 7000
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 7000
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 7000
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 herstellen konnten. Nachdem ich mich per SSH mit ihnen verbunden hatte (glücklicherweise hatte ich zuvor sshtunnel dafür konfiguriert), stellte ich fest, dass WireGuard Aus irgendeinem Grund wird eine Route für den Endpunkt erstellt, die jedoch fehlerhaft ist. Beispielsweise war für 192.168.30.2 in der Routingtabelle eine Route über die PPPoE-WAN-Schnittstelle, also über das Internet, angegeben, obwohl die Route über die WG0-Schnittstelle hätte verlaufen sollen. Nach dem Löschen dieser Route wurde die Verbindung wiederhergestellt. Gibt es irgendwo eine Anleitung, wie man dies erzwingen kann? WireGuard Ich konnte die Erstellung dieser Routen nicht vermeiden. Außerdem verstand ich nicht einmal, ob dies eine Funktion von OpenWRT oder von der WireGuardOhne lange über die Ursache des Problems nachzudenken, habe ich einfach auf beiden Routern eine Zeile zum Timer-Loop-Skript hinzugefügt, die diese Route löscht:
route del 192.168.30.2
Zusammenfassend
Vollständige Ablehnung OpenVPN Ich habe das noch nicht vollständig erreicht, da ich mich gelegentlich von einem Laptop oder Smartphone aus mit einem neuen Netzwerk verbinden muss und die Einrichtung eines Gretap-Geräts darauf in der Regel nicht möglich ist. Trotzdem habe ich einen Vorteil bei der Datenübertragungsgeschwindigkeit zwischen den Wohnungen erzielt, und die Nutzung von VNC beispielsweise ist jetzt problemlos. Der Ping ist zwar leicht gesunken, aber stabiler geworden.
Wenn Sie 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
Wenn Sie 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 wird hauptsächlich durch einen hohen Ping zum VPS beeinträchtigt, der etwa 61.5 ms beträgt
Die Geschwindigkeit hat sich jedoch deutlich erhöht. In der Wohnung mit dem Router-Server habe ich eine Internetverbindung mit 30 Mbit/s, in den anderen Wohnungen sind es nur noch 5 Mbit/s. Außerdem während der Nutzung OpenVPN Laut iperf-Messungen konnte ich keine Datenübertragungsgeschwindigkeit zwischen den Netzwerken von mehr als 3,8 Mbit/s erreichen, während WireGuard hat es auf die gleichen 5 Mbit/s "aufgepumpt".
Konfiguration WireGuard auf VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Peer]
PublicKey = <VPN_1_MS_PUBLIC_KEY>
Zulässige IPs = 192.168.30.2/32
[Peer]
PublicKey = <VPN_2_MK2_PUBLIC_KEY>
Zulässige IPs = 192.168.30.3/32
[Peer]
PublicKey = <VPN_2_MK3_PUBLIC_KEY>
Zulässige IPs = 192.168.30.4/32
Konfiguration WireGuard 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'
option mtu '8000'
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 '7500'
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'
Konfiguration WireGuard 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'
option mtu '8000'
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 '7500'
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'
Konfiguration WireGuard 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'
option mtu '8000'
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 '7500'
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 weise ich die Clients darauf hin, dass WireGuard Port 51821. Dies sollte eigentlich nicht notwendig sein, da der Client eine Verbindung von jedem freien, nicht privilegierten Port aus herstellen wird. Ich habe es jedoch so gemacht, um alle eingehenden Verbindungen auf den wg0-Schnittstellen aller Router zu blockieren, mit Ausnahme eingehender UDP-Verbindungen zu Port 51821.
Ich hoffe, dass der Artikel für jemanden nützlich sein wird.
PS Außerdem möchte ich mein Skript teilen, das mir in der WirePusher-Anwendung eine PUSH-Benachrichtigung an mein Telefon sendet, wenn ein neues Gerät in meinem Netzwerk erscheint. Hier ist ein Link zum Skript: .
AKTUALISIEREN: Konfiguration OpenVPN-Server und Clients
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-lzoOpenVPN-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 Ich habe easy-rsa verwendet, um Zertifikate zu erstellen.
Source: habr.com
