Ik zou graag mijn ervaring willen delen met het combineren van netwerken in drie geografisch afgelegen appartementen, die elk OpenWRT-routers als gateway gebruiken, tot één gemeenschappelijk netwerk. Bij het kiezen van een methode voor het combineren van netwerken tussen L3 met subnetrouting en L2 met bridging, waarbij alle netwerkknooppunten zich in hetzelfde subnet bevinden, werd de voorkeur gegeven aan de tweede methode, die moeilijker te configureren is, maar grotere mogelijkheden biedt, aangezien de transparant gebruik van technologieën was gepland in het netwerk dat Wake-on-Lan en DLNA werd gecreëerd.
Deel 1: Achtergrond
OpenVPN werd aanvankelijk gekozen als protocol voor het uitvoeren van deze taak, omdat het ten eerste een tapapparaat kan creëren dat zonder problemen aan de bridge kan worden toegevoegd, en ten tweede OpenVPN de werking via het TCP-protocol ondersteunt, wat ook belangrijk was omdat er geen van de appartementen had een speciaal IP-adres, en ik kon STUN niet gebruiken, omdat mijn provider om de een of andere reden inkomende UDP-verbindingen van hun netwerken blokkeerde, terwijl het TCP-protocol mij toestond de VPN-serverpoort door te sturen naar gehuurde VPS met behulp van SSH. Ja, deze aanpak levert een grote belasting op, aangezien de gegevens tweemaal worden gecodeerd, maar ik wilde geen VPS in mijn privénetwerk introduceren, omdat er nog steeds een risico bestond dat derden er controle over zouden krijgen, daarom heb ik zo'n apparaat op mijn thuisnetwerk was uiterst ongewenst en er werd besloten om voor beveiliging te betalen met een grote overhead.
Om de poort door te sturen op de router waarop de server zou worden ingezet, werd het sshtunnel-programma gebruikt. Ik zal de fijne kneepjes van de configuratie niet beschrijven - het is vrij eenvoudig gedaan, ik merk alleen op dat het zijn taak was om TCP-poort 1194 door te sturen van de router naar de VPS. Vervolgens werd de OpenVPN-server geconfigureerd op het tap0-apparaat, dat was verbonden met de br-lan-bridge. Nadat ik de verbinding met de nieuw gecreëerde server vanaf de laptop had gecontroleerd, werd het duidelijk dat het idee van port forwarding gerechtvaardigd was en werd mijn laptop lid van het netwerk van de router, hoewel deze er fysiek niet in zat.
Er zat nog maar één klein dingetje op: het was nodig om IP-adressen in verschillende appartementen te verdelen zodat ze niet in conflict kwamen en de routers te configureren als OpenVPN-clients.
De volgende router-IP-adressen en DHCP-serverbereiken zijn geselecteerd:
- 192.168.10.1 met bereik 192.168.10.2 - 192.168.10.80 voor de server
- 192.168.10.100 met bereik 192.168.10.101 - 192.168.10.149 voor de router in appartement nr. 2
- 192.168.10.150 met bereik 192.168.10.151 - 192.168.10.199 voor de router in appartement nr. 3
Het was ook nodig om precies deze adressen toe te wijzen aan de clientrouters van de OpenVPN-server door de regel aan de configuratie toe te voegen:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0en het toevoegen van de volgende regels aan het bestand /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
waarbij flat1_id en flat2_id de apparaatnamen zijn die zijn opgegeven bij het maken van certificaten voor verbinding met OpenVPN
Vervolgens werden OpenVPN-clients op de routers geconfigureerd en op beide werden tap0-apparaten aan de br-lan-bridge toegevoegd. In dit stadium leek alles in orde te zijn, aangezien alle drie de netwerken elkaar konden zien en als één konden werken. Er kwam echter een niet erg prettig detail naar voren: soms konden apparaten een IP-adres ontvangen dat niet van hun router afkomstig was, met alle gevolgen van dien. Om de een of andere reden had de router in een van de appartementen geen tijd om op tijd op DHCPDISCOVER te reageren en ontving het apparaat een adres dat niet bedoeld was. Ik realiseerde me dat ik dergelijke verzoeken in tap0 op elk van de routers moet filteren, maar het bleek dat iptables niet met het apparaat kan werken als het deel uitmaakt van een bridge en dat ebtables mij te hulp moet komen. Tot mijn spijt zat het niet in mijn firmware en moest ik de afbeeldingen voor elk apparaat opnieuw opbouwen. Door dit te doen en deze regels toe te voegen aan /etc/rc.local van elke router, werd het probleem opgelost:
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
Deze configuratie duurde drie jaar.
Deel 2: Introductie van WireGuard
De laatste tijd beginnen mensen op internet steeds vaker over WireGuard te praten, waarbij ze de eenvoud van de configuratie, de hoge transmissiesnelheid en de lage ping met vergelijkbare beveiliging bewonderen. Zoekend naar meer informatie hierover werd duidelijk dat noch het werken als bridgelid, noch het werken via het TCP-protocol erdoor werd ondersteund, waardoor ik dacht dat er voor mij nog steeds geen alternatieven voor OpenVPN waren. Daarom heb ik de kennismaking met WireGuard uitgesteld.
Een paar dagen geleden verspreidde het nieuws zich onder bronnen op de een of andere manier gerelateerd aan IT dat WireGuard eindelijk zou worden opgenomen in de Linux-kernel, te beginnen met versie 5.6. In nieuwsartikelen werd, zoals altijd, WireGuard geprezen. Ik stortte me opnieuw op de zoektocht naar manieren om de goede oude OpenVPN te vervangen. Deze keer kwam ik tegen . Er werd gesproken over het creëren van een Ethernet-tunnel over L3 met behulp van GRE. Dit artikel gaf mij hoop. Het bleef onduidelijk wat te doen met het UDP-protocol. De zoektocht leidde me naar artikelen over het gebruik van socat in combinatie met een SSH-tunnel om een UDP-poort door te sturen, maar ze merkten op dat deze aanpak alleen werkt in de enkele verbindingsmodus, dat wil zeggen dat het werk van meerdere VPN-clients onmogelijk zou zijn. Ik kwam op het idee om een VPN-server op een VPS te installeren en GRE voor klanten in te stellen, maar het bleek dat GRE geen encryptie ondersteunt, wat ertoe zal leiden dat als derden toegang krijgen tot de server , al het verkeer tussen mijn netwerken zal in hun handen zijn, wat helemaal niet bij mij paste.
Opnieuw werd besloten ten gunste van redundante encryptie, door VPN via VPN te gebruiken met behulp van het volgende schema:
Niveau XNUMX VPN:
VPS is server met intern adres 192.168.30.1
MS is cliënt VPS met intern adres 192.168.30.2
MK2 is cliënt VPS met intern adres 192.168.30.3
MK3 is cliënt VPS met intern adres 192.168.30.4
Tweede niveau VPN:
MS is server met extern adres 192.168.30.2 en intern 192.168.31.1
MK2 is cliënt MS met het adres 192.168.30.2 en heeft een intern IP-adres 192.168.31.2
MK3 is cliënt MS met het adres 192.168.30.2 en heeft een intern IP-adres 192.168.31.3
* MS — router-server in appartement 1, MK2 - router in appartement 2, MK3 - router in appartement 3
*Apparaatconfiguraties worden gepubliceerd in de spoiler aan het einde van het artikel.
En dus lopen er pings tussen netwerkknooppunten 192.168.31.0/24, het is tijd om verder te gaan met het opzetten van een GRE-tunnel. Om de toegang tot routers niet te verliezen, is het vooraf de moeite waard om SSH-tunnels op te zetten om poort 22 door te sturen naar de VPS, zodat bijvoorbeeld de router van appartement 10022 toegankelijk is op poort 2 van de VPS, en de router van appartement 11122 zal toegankelijk zijn op poort 3 router van appartement XNUMX. Het is het beste om het doorsturen te configureren met dezelfde sshtunnel, aangezien deze de tunnel zal herstellen als deze mislukt.
De tunnel is geconfigureerd, je kunt verbinding maken met SSH via de doorgestuurde poort:
ssh root@МОЙ_VPS -p 10022Vervolgens moet u OpenVPN uitschakelen:
/etc/init.d/openvpn stopLaten we nu een GRE-tunnel opzetten op de router van appartement 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
En voeg de gemaakte interface toe aan de bridge:
brctl addif br-lan grelan0
Laten we een soortgelijke procedure uitvoeren op de serverrouter:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
En voeg ook de gemaakte interface toe aan de bridge:
brctl addif br-lan grelan0
vanaf dit moment beginnen de pings met succes naar het nieuwe netwerk te gaan en ga ik met voldoening koffie drinken. Om vervolgens te evalueren hoe het netwerk aan de andere kant van de lijn werkt, probeer ik een SSH-verbinding te maken met een van de computers in appartement 2, maar de ssh-client loopt vast zonder om een wachtwoord te vragen. Ik probeer verbinding te maken met deze computer via telnet op poort 22 en ik zie een regel waaruit ik kan begrijpen dat de verbinding tot stand wordt gebracht, de SSH-server reageert, maar om de een of andere reden wordt ik gewoon niet gevraagd om in te loggen in.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Ik probeer verbinding te maken via VNC en zie een zwart scherm. Ik overtuig mezelf ervan dat het probleem bij de externe computer ligt, omdat ik vanuit dit appartement gemakkelijk verbinding kan maken met de router via het interne adres. Ik besluit echter via de router verbinding te maken met de SSH van deze computer en ben verrast om te ontdekken dat de verbinding succesvol is en dat de externe computer vrij normaal werkt, maar ook geen verbinding kan maken met mijn computer.
Ik verwijder het grelan0-apparaat van de bridge en draai OpenVPN op de router in appartement 2 en zorg ervoor dat het netwerk weer werkt zoals verwacht en dat de verbindingen niet worden verbroken. Door te zoeken kom ik forums tegen waar mensen klagen over dezelfde problemen, waarbij hen wordt geadviseerd de MTU te verhogen. Zo gezegd zo gedaan. Echter, totdat de MTU hoog genoeg was ingesteld (7000 voor gretap-apparaten), werden ofwel verbroken TCP-verbindingen of lage overdrachtssnelheden waargenomen. Vanwege de hoge MTU voor gretap zijn de MTU's voor Layer 8000- en Layer 7500 WireGuard-verbindingen respectievelijk ingesteld op XNUMX en XNUMX.
Ik voerde een soortgelijke installatie uit op de router van appartement 3, met als enige verschil dat een tweede gretap-interface genaamd grelan1 werd toegevoegd aan de serverrouter, die ook werd toegevoegd aan de br-lan-bridge.
Alles werkt. Nu kunt u de gretap-assemblage opstarten. Voor deze:
Ik heb deze regels in /etc/rc.local op de router in appartement 2 geplaatst:
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
Dit toegevoegd aan /etc/rc.local op de router in appartement 3:
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
En op de serverrouter:
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
Nadat ik de clientrouters opnieuw had opgestart, ontdekte ik dat ze om de een of andere reden geen verbinding met de server maakten. Nadat ik verbinding had gemaakt met hun SSH (gelukkig had ik hiervoor sshtunnel eerder geconfigureerd), werd ontdekt dat WireGuard om de een of andere reden een route voor het eindpunt aan het creëren was, maar dat was onjuist. Dus voor 192.168.30.2 gaf de routetabel een route aan via de pppoe-wan-interface, dat wil zeggen via internet, hoewel de route ernaartoe via de wg0-interface had moeten lopen. Na het verwijderen van deze route werd de verbinding hersteld. Ik kon nergens instructies vinden over hoe u WireGuard kunt dwingen deze routes niet te maken. Bovendien begreep ik niet eens of dit een functie van OpenWRT of WireGuard zelf was. Zonder lang met dit probleem te hoeven omgaan, heb ik eenvoudigweg een regel aan beide routers toegevoegd in een getimed script dat deze route verwijderde:
route del 192.168.30.2
Samenvattend
Ik heb OpenVPN nog niet volledig verlaten, omdat ik soms verbinding moet maken met een nieuw netwerk vanaf een laptop of telefoon, en het opzetten van een gretap-apparaat daarop over het algemeen onmogelijk is, maar desondanks kreeg ik een voordeel in de snelheid van gegevensoverdracht tussen appartementen en bijvoorbeeld het gebruik van VNC is niet langer lastig. Ping daalde lichtjes, maar werd stabieler:
Bij gebruik van 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
Bij gebruik van 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
Het heeft meer last van de hoge ping naar de VPS, die ongeveer 61.5 ms bedraagt
De snelheid is echter aanzienlijk toegenomen. In een appartement met een serverrouter heb ik dus een internetverbindingssnelheid van 30 Mbit/sec, en in andere appartementen is dit 5 Mbit/sec. Tegelijkertijd kon ik tijdens het gebruik van OpenVPN geen gegevensoverdrachtsnelheid tussen netwerken bereiken van meer dan 3,8 Mbit/sec volgens iperf-metingen, terwijl WireGuard deze “opvoerde” naar dezelfde 5 Mbit/sec.
WireGuard-configuratie op 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-configuratie op MS (toegevoegd aan /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'
WireGuard-configuratie op MK2 (toegevoegd aan /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'
WireGuard-configuratie op MK3 (toegevoegd aan /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 de beschreven configuraties voor VPN op het tweede niveau wijs ik WireGuard-clients naar poort 51821. In theorie is dit niet nodig, aangezien de client een verbinding tot stand zal brengen vanaf elke vrije, onbevoorrechte poort, maar ik heb het zo gemaakt dat het mogelijk was om te verbieden alle inkomende verbindingen op de wg0-interfaces van alle routers behalve inkomende UDP-verbindingen naar poort 51821.
Ik hoop dat het artikel nuttig zal zijn voor iemand.
PS Ik wil ook mijn script delen dat mij een PUSH-melding naar mijn telefoon stuurt in de WirePusher-applicatie wanneer er een nieuw apparaat op mijn netwerk verschijnt. Hier is de link naar het script: .
BIJWERKEN: Configuratie van OpenVPN-server en 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
Ik heb easy-rsa gebruikt om certificaten te genereren
Bron: www.habr.com