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
El protocol escollit inicialment per implementar aquesta tasca va ser OpenVPN, perquè, en primer lloc, pot crear un dispositiu de tap que es pot afegir al pont sense cap problema, i en segon lloc, OpenVPN Admet TCP, cosa que també era important, ja que cap dels apartaments tenia una adreça IP dedicada. No podia utilitzar STUN perquè el meu proveïdor d'Internet, per alguna raó, bloqueja les connexions UDP entrants de les seves xarxes. TCP em permetia reenviar el port del servidor VPN al VPS llogat mitjançant SSH. Tot i que aquest enfocament crea una despesa important, ja que les dades estan doblement xifrades, no volia integrar el VPS a la meva xarxa privada, ja que hi havia el risc que tercers en guanyessin el control. Per tant, tenir un dispositiu d'aquest tipus a la meva xarxa domèstica era altament indesitjable, així que vaig decidir pagar una despesa important per seguretat.
Per reenviar el port del router on es tenia previst desplegar el servidor, vaig fer servir el programa sshtunnel. No entraré en detalls de la seva configuració; és força fàcil. Només diré que el seu propòsit era reenviar el port TCP 1194 del router al VPS. A continuació, vaig configurar el servidor. OpenVPN Al dispositiu tap0, que estava connectat al pont br-lan. Després de provar la connexió al servidor recentment creat des del meu portàtil, va quedar clar que la idea del redireccionament de ports havia funcionat i el meu portàtil s'havia convertit en membre de la xarxa del router, tot i que físicament no en formava part.
L'única cosa que quedava per fer era distribuir les adreces IP en diferents apartaments perquè no entressin en conflicte i configurar els encaminadors com a OpenVPN-clients.
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 aquestes adreces als encaminadors clients. OpenVPN-server, afegint la següent 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 crear certificats per connectar-se a OpenVPN
A continuació, es van configurar els encaminadors OpenVPN- clients, dispositius tap0 en tots dos es van afegir al pont br-lan. En aquest punt, tot semblava correcte, ja que les tres xarxes es podien veure entre si i funcionar com una sola unitat. Tanmateix, va sorgir un detall força desagradable: de vegades els dispositius rebien una adreça IP del router equivocat, amb totes les conseqüències que això comportava. Per alguna raó, el router d'un dels apartaments no va respondre a DHCPDISCOVER a temps i el dispositiu va rebre l'adreça incorrecta. Em vaig adonar que havia de filtrar aquestes sol·licituds a tap0 a cada router, però va resultar que iptables no pot funcionar amb un dispositiu si forma part d'un pont, així que vaig haver d'utilitzar ebtables. Malauradament, el meu firmware no ho incloïa, així que vaig haver de reconstruir les imatges per a cada dispositiu. Després de fer això i afegir les línies següents a /etc/rc.local a cada router, 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: Coneixent WireGuard
Últimament, s'ha parlat cada cop més a Internet sobre WireGuard, admirant la seva facilitat de configuració, alta velocitat de transferència, baix ping amb seguretat comparable. Una cerca d'informació addicional va revelar que no admet ni els protocols de membres del pont ni els protocols TCP, cosa que em va fer creure que no hi havia alternatives. OpenVPN per a mi encara no hi és. Així que vaig ajornar conèixer WireGuard.
Fa uns dies, es va difondre la notícia a través de recursos relacionats amb les TI d'una manera o altra que WireGuard finalment s'inclourà al nucli Linux, començant per la versió 5.6. Els articles de notícies, com sempre, van ser elogiats WireGuardUn cop més, em vaig submergir en la recerca de maneres de substituir el bon vell OpenVPNAquesta vegada vaig topar amb . 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ó, hauríeu de desactivar 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 l'executo. OpenVPN Al router de l'apartament 2, vaig confirmar que la xarxa tornava a funcionar correctament i que les connexions no es perdien. Buscant, vaig trobar fòrums on la gent es queixava dels mateixos problemes i on se'ls aconsellava que augmentessin l'MTU. Dit i fet. Tanmateix, fins que l'MTU no es va establir prou alt (7000 per a dispositius gretap), vaig experimentar connexions TCP perdudes o velocitats de transferència baixes. A causa de l'alt MTU per a gretap, l'MTU per a connexions WireGuard El primer i el segon nivells 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 dels clients, vaig descobrir que per alguna raó no es connectaven al servidor. Després de connectar-me al seu SSH (per sort, havia configurat prèviament sshtunnel per a això), vaig descobrir que WireGuard Per alguna raó, crea una ruta per al punt final, però és incorrecta. Per exemple, per a 192.168.30.2, la taula d'encaminament especificava una ruta a través de la interfície pppoe-wan, és a dir, a través d'Internet, tot i que la ruta cap a aquesta hauria d'haver estat dirigida a través de la interfície wg0. Després d'eliminar aquesta ruta, la connexió es va restaurar. Puc trobar instruccions en algun lloc sobre com forçar WireGuard No vaig poder evitar crear aquestes rutes. A més, ni tan sols entenia si això era una característica d'OpenWRT o de WireGuardSense perdre gaire temps esbrinant el problema, simplement vaig afegir una línia a l'script del bucle del temporitzador en tots dos encaminadors que eliminava aquesta ruta:
route del 192.168.30.2
Resumint
Rebuig complet OpenVPN Encara no ho he aconseguit, ja que de vegades necessito connectar-me a una xarxa nova des d'un ordinador portàtil o telèfon, i configurar-hi un dispositiu gretap generalment és impossible. Tot i això, he guanyat un avantatge en la velocitat de transferència de dades entre apartaments, i utilitzar VNC, per exemple, ara és sense problemes. El ping ha disminuït lleugerament però s'ha tornat més estable:
Quan s'utilitza el 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 s'utilitza el 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í doncs, a l'apartament amb el router-servidor, tinc una velocitat de connexió a Internet de 30 Mbps, i als altres apartaments és de 5 Mbps. A més, durant l'ús OpenVPN No vaig poder aconseguir una velocitat de transferència de dades entre xarxes superior a 3,8 Mbps segons les lectures d'iperf, mentre que WireGuard ho va "bombejar" fins als mateixos 5 Mbit/seg.
Configuració WireGuard en VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Company]
Clau_pública = <VPN_1_MS_CLAU_PÚBLICA>
AllowedIPs = 192.168.30.2/32
[Company]
ClauPública = <VPN_2_MK2_CLAU_PÚBLICA>
AllowedIPs = 192.168.30.3/32
[Company]
ClauPública = <VPN_2_MK3_CLAU_PÚBLICA>
AllowedIPs = 192.168.30.4/32
Configuració WireGuard a MS (afegit 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ó WireGuard a MK2 (afegit 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ó WireGuard a MK3 (afegit 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, indico als clients WireGuard Port 51821. Això no hauria de ser necessari, ja que el client establirà una connexió des de qualsevol port lliure i sense privilegis, però ho vaig fer d'aquesta manera per poder denegar totes les connexions entrants 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ó OpenVPN-servidors i clients
OpenVPN-servidor
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 Vaig utilitzar easy-rsa per generar certificats.
Font: www.habr.com
