Get best of the week

Migrando do OpenVPN para o WireGuard para ingressar em redes em uma rede L2



Eu gostaria de compartilhar a experiência de combinar redes em três apartamentos geograficamente remotos, em cada um dos quais roteadores com o OpenWRT são usados ​​como gateway para uma rede comum. Ao escolher um método para combinar redes entre L3 com sub-redes de roteamento e L2 com bridging, quando todos os nós da rede estarão na mesma sub-rede, o segundo método foi preferido, mais difícil de configurar, mas oferecendo mais oportunidades, pois a rede foi planejada para usar tecnologias transparentes Wake-on-Lan e DLNA.

Parte 1: Antecedentes


O OpenVPN foi originalmente escolhido como o protocolo para implementar esta tarefa, porque, em primeiro lugar, ele pode criar um dispositivo de toque que pode ser facilmente adicionado à ponte e, em segundo lugar, o OpenVPN suporta a operação do protocolo TCP, o que também foi importante, porque nenhum dos apartamentos tinha um endereço IP dedicado e eu não pude usar o STUN, porque, por algum motivo, meu provedor bloqueia as conexões de entrada via UDP de suas redes, enquanto o TCP me permitiu encaminhar a porta do servidor VPN para VPS alugado usando SSH. Sim, essa abordagem gera uma grande carga, porque os dados são criptografados duas vezes, mas eu não queria inserir o VPS na minha rede privada, pois havia o risco de terceiros ganharem controle sobre eles, portanto,ter esse dispositivo na rede doméstica era extremamente indesejável e foi decidido pagar pela segurança com uma grande sobrecarga.

Para encaminhar a porta no roteador no qual foi planejado implantar o servidor, o programa sshtunnel foi usado. Não descreverei os meandros de sua configuração - isso é feito com bastante facilidade, apenas observei que sua tarefa era encaminhar a porta TCP 1194 do roteador para o VPS. Em seguida, o servidor OpenVPN foi configurado no dispositivo tap0, que acabou na ponte br-lan. Depois de verificar a conexão com o servidor que você acabou de criar a partir do laptop, ficou claro que a idéia de encaminhamento de porta valeu a pena e meu laptop se tornou membro da rede do roteador, embora eu não estivesse lá fisicamente.

O assunto permaneceu pequeno: era necessário distribuir endereços IP em apartamentos diferentes para que eles não entrassem em conflito e configurassem roteadores como clientes OpenVPN.
Os seguintes endereços IP do roteador e intervalos de servidores DHCP foram selecionados:

  • 192.168.10.1 com uma gama de 192.168.10.2 - 192.168.10.80 para o servidor
  • 192.168.10.100 com um intervalo de 192.168.10.101 - 192.168.10.149 para o roteador no apartamento n ° 2
  • 192.168.10.150 com um intervalo de 192.168.10.151 - 192.168.10.199 para o roteador no apartamento n ° 3

Também foi necessário atribuir esses endereços aos roteadores clientes do servidor OpenVPN adicionando as seguintes linhas à sua configuração:

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

e adicionando as seguintes linhas ao arquivo /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

em que flat1_id e flat2_id são os nomes de dispositivos especificados ao criar certificados para conectar-se ao OpenVPN

Em seguida, os clientes OpenVPN foram configurados nos roteadores, os dispositivos tap0 nos dois foram adicionados à ponte br-lan. Nesta fase, parecia que tudo estava em ordem, pois as três redes se veem e funcionam como um todo. No entanto, acabou sendo um detalhe não muito agradável: às vezes, os dispositivos não conseguiam obter um endereço IP do roteador, com todas as conseqüências resultantes. Por algum motivo, o roteador em alguns apartamentos não teve tempo de responder a tempo a DHCPDISCOVER e o dispositivo não recebeu seu endereço. Percebi que preciso filtrar essas solicitações no tap0 em cada um dos roteadores, mas, como se viu, o iptables não pode funcionar com o dispositivo se ele faz parte da ponte e o ebtables deve me ajudar. Infelizmente, não estava no meu firmware e tive que reconstruir as imagens para cada dispositivo.Depois de fazer isso e adicionar essas linhas ao /etc/rc.local de cada roteador, o problema foi resolvido:

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

Essa configuração durou três anos.

Parte 2: Apresentando o WireGuard


Recentemente, a Internet começou a falar cada vez mais sobre o WireGuard, admirando a simplicidade de sua configuração, alta velocidade de transmissão, baixo ping e segurança comparável. A busca por informações adicionais sobre ele deixou claro que eles não apoiavam o trabalho como membro da ponte ou o protocolo TCP, o que me fez pensar que ainda não havia alternativas ao OpenVPN para mim. Então adiei a conhecer o WireGuard.

Alguns dias atrás, sobre os recursos, de uma maneira ou de outra conectados à TI, surgiram as notícias de que o WireGuard finalmente será incluído no kernel do Linux, começando na versão 5.6. Os artigos de notícias, como sempre, elogiaram o WireGuard. Novamente, mergulhei na busca de maneiras de substituir o bom e velho OpenVPN. Desta vez, encontrei este artigo. Ele falou sobre a construção de um túnel Ethernet sobre L3 usando GRE. Este artigo me deu esperança. Ainda não está claro o que fazer com o protocolo UDP. A pesquisa me levou a artigos sobre o uso do socat em conjunto com um túnel SSH para encaminhar uma porta UDP, no entanto, eles observaram que essa abordagem funciona apenas no modo de conexão única, ou seja, o trabalho de vários clientes VPN seria impossível. Tive a ideia de criar um servidor VPN no VPS e configurar o GRE para clientes, mas, como se viu, o GRE não suporta criptografia, o que levará ao fato de que, no caso de acesso ao servidor por terceiros, todo o tráfego entre minhas redes está nas mãos deles. isso não me serviu em princípio.

Novamente, a decisão foi tomada em favor da criptografia excessiva, usando uma VPN em uma VPN, de acordo com o seguinte esquema:

VPN de primeiro nível:
VPS é um servidor com um endereço interno 192.168.30.1
MS é um cliente VPS com um endereço interno 192.168.30.2
MK2 é um cliente VPS com um endereço interno 192.168.30.3
MK3 é um cliente VPS com um endereço interno 192.168.30.3 MK2 é um

VPN de segundo nível:
MS é um servidor com um endereço externo 192.168.30.2 e um 192.168.31.1 interno
MK2 é um cliente MS com um endereço 192.168.30.2 e tem um IP interno 192.168.31.2
MK3 é um cliente MScom o endereço 192.168.30.2 e tem um IP interno 192.168.31.3

* MS - roteador-servidor no apartamento 1, MK2 - roteador no apartamento 2, MK3 - roteador no apartamento 2, MK3 - roteador no apartamento 3
* As configurações do dispositivo são publicadas no spoiler no final do artigo.

E assim, pings entre os nós da rede 192.168.31.0/24, é hora de seguir para a configuração do túnel GRE. Antes disso, para não perder o acesso aos roteadores, vale a pena configurar túneis SSH para encaminhar 22 portas no VPS, para que, por exemplo, o roteador do apartamento 2 esteja disponível na porta 10022nd VPS e na 11122th porta o VPS esteja disponível o roteador é do apartamento 3. É melhor configurar o encaminhamento com o mesmo sshtunnel, pois restaurará o túnel se cair.

O túnel está configurado, você pode se conectar ao SSH através da porta encaminhada:

ssh root@_VPS -p 10022

Em seguida, desative o OpenVPN:

/etc/init.d/openvpn stop

Agora configure o túnel GRE no roteador do apartamento 2:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

E adicione a interface criada à ponte:

brctl addif br-lan grelan0

Vamos executar um procedimento semelhante no roteador-servidor:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

E, também, adicione a interface criada à ponte:

brctl addif br-lan grelan0

a partir deste momento, os pings começam a ir com sucesso para a nova rede e eu, com satisfação, vou tomar café. Em seguida, para avaliar como a rede funciona na outra extremidade do fio, tento conectar-me via SSH a um dos computadores do apartamento 2, mas o cliente ssh congela sem solicitar uma senha. Tento conectar-me a este computador via telnet na porta 22 e vejo uma linha na qual se entende que a conexão está sendo estabelecida, o servidor SSH está respondendo, apenas por algum motivo não me permite efetuar login.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Eu tento conectar a ele via VNC e vejo uma tela preta. Garanto a mim mesmo que é um computador remoto, porque posso me conectar facilmente ao roteador deste apartamento no endereço interno. No entanto, decido conectar-me ao SSH deste computador através de um roteador e fico surpreso ao descobrir que a conexão foi bem-sucedida e o computador remoto está funcionando corretamente, mas também não pode se conectar ao meu computador.

Eu removo o dispositivo grelan0 da ponte e executo o OpenVPN no roteador no apartamento 2 e verifique se a rede funciona novamente conforme o esperado e as conexões não quebram. Quando procuro, encontro fóruns onde as pessoas reclamam dos mesmos problemas e são aconselhadas a aumentar o MTU. No entanto, não foi possível aumentar o MTU para a VPN de primeiro nível (wg0): com MTUs acima de 1420, definidas automaticamente, as quebras são iniciadas, mas, ao mesmo tempo, o segundo nível de VPN wg1 que trabalha em cima de wg0 funcionou corretamente com o MTU 1600. Isso é suficiente para instalar O MTU é 1500 para o dispositivo Gretap, para que essa interface tenha o mesmo valor de MTU que a ponte br-lan na qual o Gretap foi planejado para ser adicionado. Pelo que entendi, a ponte define o MTU igual ao menor dos valores disponíveis em todos os dispositivos.

Fiz uma configuração semelhante no roteador do Apartamento 3, com a única diferença: no roteador, o servidor adicionou uma segunda interface gretap chamada grelan1, que também foi adicionada à ponte br-lan.

Tudo está funcionando. Agora você pode colocar o conjunto do Gretap na inicialização. Para fazer isso:

Coloque estas linhas em /etc/rc.local no roteador no apartamento 2:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

Isso foi adicionado ao /etc/rc.local no roteador no apartamento 3:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

E no roteador do servidor:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 1500
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 1500
ip link set grelan1 up
brctl addif br-lan grelan1

Após reiniciar os roteadores clientes, descobri que, por algum motivo, eles não se conectavam ao servidor. Após conectar-se ao SSH (felizmente, eu pré-configurei o sshtunnel para isso), descobriu-se que o WireGuard estava criando uma rota para o endpoint por algum motivo, mas estava incorreto. Portanto, para 192.168.30.2, a tabela de rotas indicava a rota através da interface pppoe-wan, ou seja, via Internet, embora a rota para ela devesse ter sido roteada através da interface wg0. Depois de excluir esta rota, a conexão foi restaurada. Não encontrei instruções em algum lugar sobre como fazer o WireGuard não criar essas rotas. Além disso, eu nem entendi, um recurso é o OpenWRT ou o próprio WireGuard. Não tendo que lidar com esse problema por um longo tempo, simplesmente adicionei uma linha a esse roteador no script repetido por um timer para excluir esta rota:

route del 192.168.30.2

Resumir


Ainda não consegui uma rejeição completa do OpenVPN, já que às vezes preciso me conectar a uma nova rede a partir de um laptop ou telefone, e a configuração de um dispositivo Gretap neles geralmente é impossível, mas, apesar disso, tenho uma vantagem na velocidade de transferência de dados entre apartamentos e, por exemplo, o uso do VNC agora não causa transtornos. O ping diminuiu um pouco, mas ficou mais estável:

ao usar o 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

Ao usar o 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

É mais afetado pelo alto ping antes do VPS, que é de aproximadamente 61,5 ms

, mas a velocidade aumentou significativamente. Assim, em um apartamento com um roteador-servidor, eu tenho uma velocidade de conexão à Internet de 30 Mbit / s, e em outros apartamentos - 5 Mbit / s. Ao mesmo tempo, enquanto usava o OpenVPN, não consegui obter uma taxa de transferência de dados entre redes de mais de 3,8 Mb / s, de acordo com o iperf, enquanto o WireGuard o "bombeava" para os mesmos 5 Mb / s.

Configuração do WireGuard no 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

Configuração do WireGuard no MS (adicionada 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'

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 '1600'

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'


Configuração do WireGuard no MK2 (adicionada 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'

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 '1600'

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'


Configuração do WireGuard no MK3 (adicionada 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'

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 '1600'

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'


Nas configurações descritas para a VPN de segundo nível, eu especifico a porta 51821 para os clientes WireGuard.Em princípio, isso não é necessário, pois o cliente estabelecerá uma conexão a partir de qualquer porta livre e sem privilégios, mas fiz isso para poder bloquear todas as conexões de entrada nas interfaces wg0 de todos os roteadores, exceto conexões UDP de entrada à porta 51821.

Espero que este artigo seja útil para alguém.

PS Além disso, quero compartilhar meu script que me envia uma notificação PUSH no telefone para o aplicativo WirePusher quando um novo dispositivo aparece na minha rede. Aqui está o link para o script: github.com/r0ck3r/device_discover .

ATUALIZAÇÃO: Configurando servidor e clientes 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-lzo


Cliente 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



Para gerar certificados usados ​​easy-rsa

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles