M'agradaria compartir la meva experiència de combinar xarxes en tres apartaments distants geogràficament, cadascun dels quals utilitza encaminadors amb OpenWRT com a porta d'entrada, en una xarxa comuna. Quan es va triar un mètode per combinar xarxes entre L3 amb enrutament de subxarxa i L2 amb pont, quan tots els nodes de xarxa estaran a la mateixa subxarxa, es va donar preferència al segon mètode, que és més difícil de configurar, però ofereix més oportunitats, ja que és transparent. Es va planificar l'ús de tecnologies a la xarxa creada Wake-on-Lan i DLNA.
Part 1: Antecedents
OpenVPN va ser escollit inicialment com a protocol per implementar aquesta tasca, ja que, en primer lloc, pot crear un dispositiu de tap que es pugui afegir al pont sense cap problema, i en segon lloc, OpenVPN admet el funcionament a través del protocol TCP, que també era important, perquè cap dels apartaments tenia una adreça IP dedicada i no vaig poder utilitzar STUN, perquè per algun motiu el meu ISP bloqueja les connexions UDP entrants de les seves xarxes, mentre que el protocol TCP em va permetre reenviar el port del servidor VPN al VPS llogat mitjançant SSH. Sí, aquest enfocament suposa una gran càrrega, ja que les dades es xifren dues vegades, però no volia introduir el VPS a la meva xarxa privada, ja que encara hi havia el risc que tercers en tinguessin el control, per tant, tenir aquest dispositiu. a la xarxa domèstica era extremadament indesitjable i es va decidir pagar la seguretat amb una gran sobrecàrrega.
Per reenviar el port de l'encaminador on s'havia previst desplegar el servidor, es va utilitzar el programa sshtunnel. No descriuré les complexitats de la seva configuració: això es fa amb força facilitat, només tinc present que la seva tasca era reenviar el port TCP 1194 des de l'encaminador al VPS. A continuació, es va configurar el servidor OpenVPN al dispositiu tap0, que estava connectat al pont br-lan. Després de comprovar la connexió amb el servidor de nova creació des de l'ordinador portàtil, va quedar clar que la idea del reenviament de ports es justificava i el meu ordinador portàtil es va convertir en membre de la xarxa de l'encaminador, tot i que no hi era físicament.
L'assumpte va quedar petit: calia distribuir les adreces IP en diferents apartaments perquè no entraven en conflicte i configurar els encaminadors com a clients OpenVPN.
S'han seleccionat les següents adreces IP de l'encaminador i intervals de servidor DHCP:
- 192.168.10.1 amb abast 192.168.10.2 - 192.168.10.80 per al servidor
- 192.168.10.100 amb abast 192.168.10.101 - 192.168.10.149 per a un router a l'apartament núm. 2
- 192.168.10.150 amb abast 192.168.10.151 - 192.168.10.199 per a un router a l'apartament núm. 3
També va ser necessari assignar exactament aquestes adreces als encaminadors de clients del servidor OpenVPN afegint la línia a la seva configuració:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0i afegint les línies següents al fitxer /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
on flat1_id i flat2_id són els noms de dispositiu especificats en generar certificats per connectar-se a OpenVPN
A continuació, es van configurar els clients OpenVPN als encaminadors, els dispositius tap0 d'ambdós es van afegir al pont br-lan. En aquesta etapa, tot semblava estar en ordre, ja que les tres xarxes es veuen i funcionen com un tot. No obstant això, va resultar un detall poc agradable: de vegades els dispositius podien obtenir una adreça IP que no des del seu encaminador, amb totes les conseqüències que se'n deriven. Per alguna raó, l'encaminador d'un dels apartaments no va tenir temps de respondre a DHCPDISCOVER a temps i el dispositiu va rebre l'adreça incorrecta. Em vaig adonar que necessitava filtrar aquestes sol·licituds a tap0 a cadascun dels encaminadors, però va resultar que iptables no pot funcionar amb un dispositiu si forma part d'un pont i ebtables hauria de venir al meu rescat. Per la meva pena, no estava al meu microprogramari i vaig haver de reconstruir les imatges per a cada dispositiu. Fent això i afegint aquestes línies a /etc/rc.local de cada encaminador, el problema es va resoldre:
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
Aquesta configuració va durar tres anys.
Part 2: Presentació de WireGuard
Recentment, Internet parla cada cop més de WireGuard, admirant la senzillesa de la seva configuració, l'alta velocitat de transferència, el baix ping amb una seguretat comparable. En cercar més informació al respecte, va deixar clar que ni treballar com a membre del pont ni treballar amb el protocol TCP és compatible, la qual cosa em va fer pensar que encara no hi ha alternatives a OpenVPN per a mi. Així que vaig deixar de conèixer WireGuard.
Fa uns dies es va difondre a través de recursos d'una o altra manera relacionats amb les TI la notícia que WireGuard s'inclourà finalment al nucli de Linux, a partir de la versió 5.6. Els articles de notícies, com sempre, van elogiar WireGuard. Em vaig submergir de nou a la recerca de maneres de substituir el bon vell OpenVPN. Aquesta vegada m'he topat . Es va parlar de la creació d'un túnel Ethernet sobre L3 mitjançant GRE. Aquest article em va donar esperança. No estava clar què fer amb el protocol UDP. La cerca em va portar a articles sobre l'ús de socat juntament amb un túnel SSH per reenviar un port UDP, però, van assenyalar que aquest enfocament només funciona en mode de connexió única, la qual cosa significa que seria impossible diversos clients VPN. Vaig tenir la idea de configurar un servidor VPN en un VPS i configurar GRE per als clients, però, com va resultar, GRE no admet el xifratge, cosa que comportarà que si tercers accedeixen al servidor, tot el trànsit entre les meves xarxes està a les seves mans, cosa que no em va bé.
De nou, la decisió es va prendre a favor del xifratge redundant, utilitzant VPN sobre VPN segons el següent esquema:
VPN de capa XNUMX:
VPS és servidor amb adreça interna 192.168.30.1
MS és client VPS amb adreça interna 192.168.30.2
MK2 és client VPS amb adreça interna 192.168.30.3
MK3 és client VPS amb adreça interna 192.168.30.4
VPN de capa XNUMX:
MS és servidor amb adreça externa 192.168.30.2 i interna 192.168.31.1
MK2 és client MS amb l'adreça 192.168.30.2 i té una IP interna de 192.168.31.2
MK3 és client MS amb l'adreça 192.168.30.2 i té una IP interna de 192.168.31.3
* MS - servidor d'encaminador a l'apartament 1, MK2 - encaminador a l'apartament 2, MK3 - Encaminador a l'apartament 3
* Les configuracions del dispositiu es publiquen al spoiler al final de l'article.
I així, els pings entre els nodes de la xarxa 192.168.31.0/24 van, és hora de passar a configurar el túnel GRE. Abans d'això, per no perdre l'accés als encaminadors, val la pena configurar túnels SSH per reenviar el port 22 al VPS, de manera que, per exemple, un encaminador de l'apartament 10022 estarà disponible al port 2 del VPS, i un l'encaminador de l'apartament 11122 estarà disponible al port 3 del VPS, l'encaminador de l'apartament XNUMX. El millor és configurar el reenviament amb el mateix sshtunnel, ja que restaurarà el túnel en cas que cau.
El túnel està configurat, podeu connectar-vos a SSH a través del port reenviat:
ssh root@МОЙ_VPS -p 10022A continuació, desactiveu OpenVPN:
/etc/init.d/openvpn stopAra configurem un túnel GRE al router des de l'apartament 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
I afegiu la interfície creada al pont:
brctl addif br-lan grelan0
Realitzem un procediment similar al router del servidor:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
I, també, afegiu la interfície creada al pont:
brctl addif br-lan grelan0
a partir d'aquest moment, els pings comencen a anar amb èxit a la nova xarxa i jo, amb satisfacció, vaig a prendre un cafè. Aleshores, per veure com funciona la xarxa a l'altre extrem del cable, intento fer SSH a un dels ordinadors de l'apartament 2, però el client ssh es congela sense demanar-me una contrasenya. Intento connectar-me a aquest ordinador a través de telnet al port 22 i veig una línia des de la qual podeu entendre que la connexió s'està establint, el servidor SSH respon, però per alguna raó no m'ofereix entrar.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Estic intentant connectar-hi mitjançant VNC i veig una pantalla negra. Em convenc que l'assumpte està a l'ordinador remot, perquè em puc connectar fàcilment al router des d'aquest apartament mitjançant l'adreça interna. Tanmateix, decideixo fer SSH a aquest ordinador a través de l'encaminador i em sorprèn veure que la connexió té èxit i que l'ordinador remot funciona bé, però tampoc no es connecta al meu ordinador.
Trec el dispositiu grelan0 del pont i engego OpenVPN a l'encaminador de l'apartament 2 i m'asseguro que la xarxa torna a funcionar correctament i que les connexions no cauen. Buscant em trobo amb fòrums on la gent es queixa dels mateixos problemes, on se'ls aconsella augmentar el MTU. No més aviat dir que fet. Tanmateix, fins que la MTU es va establir en un valor prou gran de 7000 per als dispositius gretap, es van observar connexions TCP caigudes o transmissions lentes. A causa de l'elevat MTU per a gretap, els MTU per a les connexions WireGuard del primer i segon nivell es van establir en 8000 i 7500, respectivament.
Vaig fer una configuració similar a l'encaminador de l'apartament 3, amb l'única diferència que es va afegir una segona interfície gretap anomenada grelan1 al router del servidor, que també es va afegir al pont br-lan.
Tot funciona. Ara podeu posar el conjunt gretap a la càrrega automàtica. Per això:
Col·loca aquestes línies a /etc/rc.local a l'encaminador de l'apartament 2:
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
S'ha afegit això a /etc/rc.local a l'encaminador de l'apartament 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
I al router del servidor:
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
Després de reiniciar els encaminadors del client, vaig trobar que per algun motiu no es connectaven al servidor. En connectar-se al seu SSH (afortunadament, abans havia configurat sshtunnel per a això), es va descobrir que WireGuard, per algun motiu, crea una ruta per al punt final, tot i ser incorrecte. Així, per a 192.168.30.2, la taula de rutes es va especificar a la taula de rutes a través de la interfície pppoe-wan, és a dir, a través d'Internet, tot i que la ruta a ella s'hauria d'haver dirigit a través de la interfície wg0. Després de suprimir aquesta ruta, la connexió es va restablir. No he pogut trobar instruccions enlloc sobre com forçar WireGuard a no crear aquestes rutes. A més, ni tan sols vaig entendre si aquesta és una característica d'OpenWRT o del mateix WireGuard. Sense haver de fer front a aquest problema durant molt de temps, simplement vaig afegir als dos encaminadors en un script fet en bucle per un temporitzador, una línia que eliminava aquesta ruta:
route del 192.168.30.2
Resumint
Encara no he aconseguit un rebuig complet d'OpenVPN, ja que de vegades necessito connectar-me a una xarxa nova des d'un ordinador portàtil o un telèfon, i instal·lar-hi un dispositiu gretap generalment és impossible, però malgrat això, vaig obtenir un avantatge en la transferència de dades. la velocitat entre apartaments i, per exemple, utilitzar VNC ja no és inconvenient. El ping va disminuir lleugerament, però es va tornar més estable:
Quan utilitzeu 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
Quan utilitzeu 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 veu principalment afectat per un ping alt a VPS, que és d'aproximadament 61.5 ms
No obstant això, la velocitat ha augmentat significativament. Així, en un apartament amb un encaminador-servidor, tinc una velocitat de connexió a Internet de 30 Mbps, i en altres apartaments, de 5 Mbps. Al mateix temps, mentre utilitzava OpenVPN, no vaig poder aconseguir una velocitat de transferència de dades entre xarxes de més de 3,8 Mbps segons iperf, mentre que WireGuard la va "bombar" fins als mateixos 5 Mbps.
Configuració de WireGuard a 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
Configuració de WireGuard a MS (afegida a /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'
Configuració de WireGuard a MK2 (afegida a /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'
Configuració de WireGuard a MK3 (afegida a /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'
A les configuracions descrites per a la VPN de segon nivell, especifico als clients WireGuard el port 51821. En teoria, això no és necessari, ja que el client establirà una connexió des de qualsevol port gratuït no privilegiat, però ho vaig fer perquè totes les connexions entrants es pot denegar a les interfícies wg0 de tots els encaminadors, excepte les connexions UDP entrants al port 51821.
Espero que l'article sigui útil a algú.
PS A més, vull compartir el meu script que m'envia una notificació PUSH al meu telèfon a l'aplicació WirePusher quan apareix un dispositiu nou a la meva xarxa. Aquí teniu un enllaç al guió: .
ACTUALITZACIÓ: Configuració del servidor i clients OpenVPN
Servidor OpenVPN
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-lzoClient OpenVPN
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
Vaig utilitzar easy-rsa per generar certificats.
Font: www.habr.com