
Eu tenho um servidor A com uma VPN configurada para outro servidor B. Atualmente, o servidor A pode executar ping no servidor B usando o endereço VPN 10.12.0.1
.
Gostaria de rotear todo o tráfego HTTPS através do servidor B e permitir que outro tráfego usasse a interface padrão.
Para fazer isso, me inspirei emesta resposta unix stackexchangee executei os seguintes comandos:
# define route
echo "200 myroute" >> /etc/iproute2/rt_tables
# seems necessary
sysctl -w net.ipv4.conf.wg1.rp_filter=2
# actual routing
ip route add table 200 10.12.0.0/24 dev wg1 src 10.12.0.10
ip route add table 200 default via 10.12.0.1
# actual rule telling HTTPS traffic to use table 200
ip rule add iif lo ipproto tcp dport 443 lookup 200
Então, executo curl https://1.1.1.1
(ou qualquer outro host) e recebo o erro Failed to connect to 1.1.1.1 port 443: No route to host
. Quando removo a regra, tudo funciona novamente.
Acho que meu roteamento para a tabela 200 não está correto, mas parece corresponder ao da resposta original e ao da interface padrão.
Você sabe como posso investigar e depurar o problema?
Obrigado
Informações adicionais:
$ ip route show table 200
default via 10.12.0.1 dev wg1
10.12.0.0/24 dev wg1 scope link src 10.12.0.10
$ ip route show dev wg1
10.12.0.0/24 proto kernel scope link src 10.12.0.10
$ ip route get 1.1.1.1 ipproto tcp dport 443
1.1.1.1 via 10.12.0.1 dev wg1 table 200 src 10.12.0.10 uid 1001
cache
$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
10.12.0.0/24 dev wg1 proto kernel scope link src 10.12.0.10
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202
A VPN é uma VPN Wireguard. Quando configurado para rotear todo o tráfego pela VPN, tudo funciona.
Responder1
O erro "sem rota para host" provavelmente ocorre devido à tentativa de conexão com um host ( 1.1.1.1
) não incluído na AllowedIPs
configuração do WireGuard. Supondo que você esteja usando o wg-quick, faça o seguinte:
Comopasso 1, na configuração WireGuard do Servidor A, ajuste a AllowedIPs
configuração na [Peer]
seção do Servidor B para incluir os endereços IP (ou blocos de endereços IP) aos quais você deseja se conectar.
Em vez de 1.1.1.1
, digamos que do Servidor A você queira se conectar a qualquer servidor HTTPS no 192.0.2.0/24
bloco (e, em particular, havia um servidor 192.0.2.123
com o qual você está testando). Digamos também que você definiu inicialmente sua AllowedIPs
configuração no Servidor A para o Servidor B para incluir o 10.12.0.0/24
bloco. Altere esta configuração para o seguinte:
AllowedIPs = 10.12.0.0/24, 192.0.2.0/24
Livre-se das rotas e regras que você definiu anteriormente para a tabela 200 no Servidor A, reinicie o WireGuard (por exemplo sudo wg-quick down wg1; sudo wg-quick up wg1
) e teste essa alteração executando o seguinte:
$ curl -k https://192.0.2.123
Isso deve pelo menos levá-lo além do erro "sem rota para hospedar". Se você ainda estiver recebendo erros apenas com isso, provavelmente precisará ajustar suas regras de firewall/roteamento no Servidor B para permitir o encaminhamento de pacotes do Servidor A para o 192.0.2.0/24
.
Comopasso 2, na [Interface]
seção de configuração do WireGuard do Servidor A, adicione a seguinte configuração:
Table = 200
Isso direcionará o wg-quick para adicionar as rotas que ele cria automaticamente para você à sua 200
tabela de roteamento personalizada, em vez de à sua tabela principal. Reinicie o WireGuard novamente e verifique suas tabelas de roteamento:
$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202
$ ip route show table 200
10.12.0.0/24 dev wg1 scope link
192.0.2.0/24 dev wg1 scope link
Agora adicione sua regra de política HTTPS especial:
$ sudo ip rule add iif lo ipproto tcp dport 443 lookup 200
E teste:
$ curl -k https://192.0.2.123
Comoetapa 3, supondo que você ainda queira se conectar diretamente do Servidor A ao Servidor B através do WireGuard para serviços diferentes de HTTPS (como SSH etc.), adicione outra regra de política no Servidor A para todas as conexões ao 10.12.0.0/24
bloco:
$ sudo ip rule add to 10.12.0.0/24 table 200 priority 201
Agora você poderá usar o WireGuard para conectar-se do Servidor A ao Servidor B novamente:
$ ssh 10.12.0.1