OpenVPN e pings unidirecionais

Question

Configuração de rede

Eu configurei uma rede:

Portasapropriadasdecomputadoresem192.168.87.0/24sãoencaminhadasemTP-LINKrouterparaseremvistas"em todo o mundo".

Encaminhamento de IP ativado em OpenVPN server .

Eu posso me conectar do OfficeB de client1 a OpenVPN server no OfficeA. client1 e server se vêem - eles respondem por pings (ambos em 192.168.87.0/24 e 10.8.0.0/24 network), enviam dados, criam conexões (por exemplo, ssh).

Tabela de roteamento em TP-LINK router ( a.b.c.d é um IP da WAN):

DST             MASK                GATEWAY         IFACE
a.b.c.d         255.255.255.255     0.0.0.0         WAN
192.168.87.0    255.255.255.0       0.0.0.0         LAN & WLAN
10.8.0.0        255.255.255.0       192.168.87.2    LAN & WLAN (route added by hand)
239.0.0.0       255.0.0.0           0.0.0.0         LAN & WLAN
0.0.0.0         0.0.0.0             a.b.c.d         WAN

O problema

E agora ... De QUALQUER computador em 192.168.87.0/24 , posso pingar 10.8.0.6 . Infelizmente 10.8.0.6 pode pingar APENAS 87.1 , 87.2 .

Mas ... 10.8.0.6 começaria a fazer ping em um computador em 87.0/24 (por exemplo, 87.104 ) somente se eu pingasse primeiro deste computador para 10.8.0.6 :

1. 10.8.0.6 : ping 192.168.87.104 - falhou, tempo excedido.
2. 192.168.87.104 : ping 10.8.0.6 - ok.
3. 10.8.0.6 : ping 192.168.87.104 - ok.

O que eu verifiquei

Eu verifiquei com tcpdump , que 192.168.87.104 sempre recebe solicitações envia respostas para pings de 10.8.0.6 . Mas as respostas parecem não passar pelo gateway TP-LINK router de volta para 10.8.0.6 - não consigo vê-las com tcpdump on OpenVPN server em ambas as interfaces.

Também verifiquei se adicionei uma rota em 192.168.87.104 :

(1) route add 10.8.0.0 netmask 255.255.255.0 gw 192.168.87.2

então 10.8.0.6 sempre receberia uma resposta de ping, mesmo que eu não tivesse pingado de 192.168.87.104 antes.

Outra coisa que descobri é: o ping de 192.168.87.104 para 10.8.0.6 é adicionado ao cache de roteamento ( route -C ) uma entrada (1) . E no primeiro ping '' (antes da entrada ser adicionada) eu recebo:

PING 10.8.0.6 (10.8.0.6) 56(84) bytes of data.
64 bytes from 10.8.0.6: icmp_req=1 ttl=127 time=37.0 ms
From 192.168.87.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.87.2)
64 bytes from 10.8.0.6: icmp_req=2 ttl=127 time=93.0 ms

Eu li que esse era um comportamento normal, porque o gateway para 10.8.0.0 estava no mesmo segmento de rede. E depois de icmp redirect host , uma nova entrada foi criada no cache de roteamento.

O TP-LINK router , no painel de configuração da web, possui uma caixa de seleção SPI Firewall - Stateful Packet Inspection . Desativar isso não resolve o problema.

Minha pergunta

Não consigo entender por que uma resposta de ping 192.168.87.104 > 10.8.0.6 não passa por TP-LINK router , apesar de TP-LINK router saber uma rota para 10.8.0.0 e a solicitação de ping de 192.168.87.104 a 10.8.0.6 ser aprovada.

Então, minha pergunta é: qual é o motivo? Existe alguma coisa que eu possa fazer para resolver a situação (exceto para adicionar uma rota (1) em cada computador no OfficeA ...)? Pessoalmente, acho que um problema está em TP-LINK router .

OpenVPN server arquivo de configuração:

port 1194
proto udp
dev tun

ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem

server 10.8.0.0 255.255.255.0
push "route 192.168.87.0 255.255.255.0"

client-to-client

keepalive 10 120
comp-lzo

persist-key
persist-tun

    

Answer 1

Meu palpite é que o TP-LINK está inicialmente descartando as respostas de ping de .87.104 para .0.6 devido a uma regra de firewall com estado. Observe que quando .0.6 pings .87.104 , o roteador TP-LINK nunca vê os pacotes de solicitação de ping. Do ponto de vista de um firewall com estado, é perfeitamente razoável descartar respostas de ping se ele nunca tiver visto as solicitações de ping originais indo na direção oposta. Posteriormente, depois que .87.104 enviar algumas solicitações de ping para .0.6 , o firewall poderá permitir respostas de ping de .84.104 a .0.6 , pois viu .87.104 iniciar a comunicação com .0.6 recentemente.

Pode ser possível modificar as regras de firewall do TP-LINK. Mas como se trata de um roteador de marca "orçamento", suspeito que suas opções estarão limitadas a algo como uma caixa de seleção "Stateful Firewall on / off". Ou você pode nem perceber isso.

Uma possível solução é adicionar uma segunda NIC ao servidor Debian OpenVPN e torná-la roteador de gateway de internet do Office A. Dessa forma, a rota de gateway padrão nos clientes do Office A também funcionará para 10.8 tráfego e você não precisará adicionar uma entrada extra às tabelas de roteamento de todos os clientes. E como um bônus adicional, você terá a oportunidade de usar o iptables para adaptar suas regras de firewall ao desejo do seu coração.