Nenhuma rota para hospedar com roteamento para interface para porta específica

Nenhuma rota para hospedar com roteamento para interface para porta específica

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 AllowedIPsconfiguraçã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 AllowedIPsconfiguraçã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/24bloco (e, em particular, havia um servidor 192.0.2.123com o qual você está testando). Digamos também que você definiu inicialmente sua AllowedIPsconfiguração no Servidor A para o Servidor B para incluir o 10.12.0.0/24bloco. 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 200tabela 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/24bloco:

$ 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

informação relacionada