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
Het protocol dat gekozen werd om deze taak uit te voeren was aanvankelijk OpenVPN, omdat het ten eerste een tapapparaat kan creëren dat zonder problemen aan de brug kan worden toegevoegd, en ten tweede, OpenVPN Het ondersteunt TCP, wat ook belangrijk was, aangezien geen van de appartementen een eigen IP-adres had. Ik kon geen STUN gebruiken omdat mijn internetprovider om de een of andere reden inkomende UDP-verbindingen vanuit zijn netwerken blokkeert. TCP stelde me in staat om de VPN-serverpoort via SSH door te sturen naar de gehuurde VPS. Hoewel deze aanpak aanzienlijke overhead met zich meebrengt, omdat de gegevens dubbel versleuteld zijn, wilde ik de VPS niet in mijn privénetwerk integreren, omdat er een risico bestond dat derden er controle over zouden krijgen. Het was daarom zeer onwenselijk om zo'n apparaat op mijn thuisnetwerk te hebben, dus besloot ik een aanzienlijk bedrag te betalen voor extra beveiliging.
Om de poort op de router waar de server zou worden geplaatst door te sturen, gebruikte ik het programma sshtunnel. Ik zal niet ingaan op de details van de configuratie – die is vrij eenvoudig. Ik wil alleen vermelden dat het doel ervan was om TCP-poort 1194 van de router naar de VPS door te sturen. Vervolgens heb ik de server geconfigureerd. OpenVPN Op het tap0-apparaat, dat was verbonden met de br-lan bridge. Na het testen van de verbinding met de nieuw gecreëerde server vanaf mijn laptop, werd duidelijk dat het idee van port forwarding had gewerkt en dat mijn laptop lid was geworden van het netwerk van de router, ook al maakte deze er fysiek geen deel van uit.
Het enige wat nog restte, was het toewijzen van IP-adressen aan de verschillende appartementen zodat er geen conflicten zouden ontstaan en het configureren van de routers. OpenVPN-klanten.
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 deze adressen aan de clientrouters toe te wijzen. OpenVPN-server, door de volgende 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 aanmaken van certificaten voor de verbinding met OpenVPN
Vervolgens werden de routers geconfigureerd. OpenVPN- Clients, tap0-apparaten op beide netwerken werden toegevoegd aan de br-lan bridge. Op dit punt leek alles in orde, aangezien alle drie de netwerken elkaar konden zien en als één geheel functioneerden. Er deed zich echter een vervelend detail voor: soms kregen apparaten een IP-adres van de verkeerde router, met alle gevolgen van dien. Om de een of andere reden reageerde de router in een van de appartementen niet op tijd op DHCPDISCOVER, waardoor het apparaat het verkeerde adres kreeg. Ik realiseerde me dat ik dergelijke verzoeken in tap0 op elke router moest filteren, maar het bleek dat iptables niet werkt met een apparaat dat deel uitmaakt van een bridge, dus moest ik ebtables gebruiken. Helaas bevatte mijn firmware dit niet, dus moest ik de images voor elk apparaat opnieuw compileren. Nadat ik dit had gedaan en de volgende regels aan /etc/rc.local op elke router had toegevoegd, was 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: Kennismaken WireGuard
De laatste tijd wordt er op internet steeds vaker over gesproken. WireGuardIk was onder de indruk van het configuratiegemak, de hoge overdrachtssnelheid, de lage ping en de vergelijkbare beveiliging. Een zoektocht naar aanvullende informatie bracht echter aan het licht dat het apparaat geen ondersteuning biedt voor bridge members of het TCP-protocol, waardoor ik tot de conclusie kwam dat er geen alternatief was. OpenVPN Voor mij is het er nog steeds niet. Dus stel ik het leren kennen steeds maar uit. WireGuard.
Een paar dagen geleden verspreidde zich via diverse IT-gerelateerde bronnen het nieuws dat WireGuard zal uiteindelijk in de kernel worden opgenomen Linuxvanaf versie 5.6. Nieuwsartikelen werden, zoals altijd, geprezen. WireGuardIk stortte me opnieuw op de zoektocht naar manieren om het goede oude te vervangen. OpenVPNDeze 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 je uitschakelen OpenVPN:
/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 haal het grelan0-apparaat uit de bridge en start het. OpenVPN Op de router in appartement 2 heb ik gecontroleerd of het netwerk weer goed werkte en of er geen verbindingen meer wegvielen. Tijdens mijn zoektocht kwam ik forums tegen waar mensen klaagden over dezelfde problemen en waar hen werd aangeraden de MTU te verhogen. Dat heb ik dan ook gedaan. Totdat de MTU echter hoog genoeg was ingesteld – 7000 voor gretap-apparaten – ondervond ik ofwel weggevallen TCP-verbindingen of lage overdrachtssnelheden. Vanwege de hoge MTU voor gretap was de MTU voor de verbindingen te hoog. WireGuard Het eerste en tweede niveau werden respectievelijk op 8000 en 7500 ingesteld.
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
Na het herstarten van de clientrouters ontdekte ik dat ze om de een of andere reden geen verbinding maakten met de server. Nadat ik via SSH verbinding had gemaakt (gelukkig had ik hiervoor al sshtunnel geconfigureerd), ontdekte ik dat WireGuard Om de een of andere reden wordt er een route voor het eindpunt aangemaakt, maar deze is onjuist. Bijvoorbeeld, voor 192.168.30.2 specificeerde de routetabel een route via de pppoe-wan-interface, oftewel via het internet, terwijl de route ernaartoe via de wg0-interface had moeten lopen. Na het verwijderen van deze route werd de verbinding hersteld. Kan ik ergens instructies vinden over hoe ik dit kan afdwingen? WireGuard Ik kon niet voorkomen dat ik deze routes moest aanmaken. Bovendien begreep ik niet eens of dit een functie van OpenWRT was of van de rest. WireGuardZonder veel tijd te besteden aan het uitzoeken van het probleem, heb ik simpelweg een regel aan het timer-loop-script op beide routers toegevoegd die deze route verwijdert:
route del 192.168.30.2
Samenvattend
Volledige afwijzing OpenVPN Ik heb dit nog niet bereikt, omdat ik af en toe vanaf een laptop of telefoon verbinding moet maken met een nieuw netwerk, en het instellen van een Gretap-apparaat daarop is meestal onmogelijk. Desondanks heb ik wel een voordeel behaald qua gegevensoverdrachtssnelheid tussen appartementen, en het gebruik van VNC is bijvoorbeeld nu probleemloos. De ping is iets afgenomen, maar wel stabieler geworden.
Bij gebruik van de 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 de 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 het appartement met de router-server heb ik nu een internetverbinding van 30 Mbps, terwijl dat in de andere appartementen slechts 5 Mbps is. Bovendien is de snelheid tijdens gebruik aanzienlijk verbeterd. OpenVPN Volgens iperf-metingen kon ik geen gegevensoverdrachtssnelheid tussen netwerken bereiken die hoger was dan 3,8 Mbps, terwijl WireGuard Ze hebben het opgeschroefd naar dezelfde 5 Mbit/sec.
Configuratie WireGuard op VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Gelijke]
PublicKey = <VPN_1_MS_PUBLIC_KEY>
Toegestane IP's = 192.168.30.2/32
[Gelijke]
PublicKey = <VPN_2_MK2_PUBLIC_KEY>
Toegestane IP's = 192.168.30.3/32
[Gelijke]
PublicKey = <VPN_2_MK3_PUBLIC_KEY>
Toegestane IP's = 192.168.30.4/32
Configuratie WireGuard 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'
Configuratie WireGuard 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'
Configuratie WireGuard 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 de VPN van het tweede niveau geef ik aan de clients aan WireGuard Poort 51821. Dit zou niet nodig moeten zijn, aangezien de client een verbinding tot stand brengt vanaf elke vrije, niet-bevoorrechte poort, maar ik heb het zo gedaan zodat ik alle inkomende verbindingen op de wg0-interfaces van alle routers kon weigeren, 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 OpenVPN-servers 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-cliënt
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
