O servidor A não possui uma rota sugerindo conectar-se à rede 10.199.115.0/24 através da VPN, portanto, usa sua rota padrão (ou seja, tente acessar B pelo seu IP público).
Tente ver se a execução
ip route add 10.199.115.0/24 via 10.1.1.2
no servidor A permitirá a conexão de A a B (sem qualquer regra NAT no firewall F)
Se isso funcionar, você pode configurar o openvpn para criar automaticamente a rota para você quando iniciar a conexão de A
Uma explicação do que acontece na sua configuração.
Aqui está como o roteamento / NAT acontece nos três casos
Caso 1: B pings PUBLIC_IP
- O pacote sai de B usando a rota
default, porque é o único que corresponde aPUBLIC_IP. Ele é enviado para ser roteado no endereço IP10.199.115.1, com o destino finalPUBLIC_IPe o endereço de origem10.199.115.146. - O pacote é roteado por F. Muitas rotas se aplicam: a mais específica é
PUBLIC_IP/32, que envia o pacote a ser roteado na máquina10.0.2.2oneth0, que eu acho que é a máquina A (a conexão openvpn subjacente). - A máquina A recebe o pacote e responde ao endereço de origem
10.199.115.146. Sem a regra que mostrei, isso seria interpretado como um endereço na Internet e, portanto, a resposta seria enviada pela Internet. - usando a rota que propus, o pacote retorna através de
tun0para a máquina F. A Máquina F roteia isso de volta paraeth1, onde a máquina B recebe o pacote de resposta. No entanto, sua origem é marcada como10.1.1.1, portanto, não é reconhecida como a resposta ao pacote original. Ping falhou.
Caso 2: B pings 10.1.1.1
- O mesmo que antes, o pacote deixa B para ser roteado por F
- Desta vez, o destino corresponde à regra 10.1.1.1/32, portanto, o pacote é enviado por
tun0 - À medida que o pacote sai por
tun0, a regraMASQUERADEentra em ação, alterando a origem do pacote como10.1.1.2. (isso não é necessário se estiver usando a regra de rota que propus, veja abaixo). - A máquina A recebe o pacote e responde de volta a
10.1.1.2(máquina F). SemMASQUERADE, isso seria enviado de volta para10.199.115.146. Com a entrada da minha tabela de roteamento proposta, isso não mudaria muito, porque o pacote seria enviado para10.1.1.2para roteamento, no entanto, se você não tiver o destino10.199.115.146será roteado pela Internet. - O pacote de resposta é recebido pela máquina F. Se o mascaramento foi executado, o pacote é reconhecido como resposta e seu endereço de destino é alterado de volta para
10.199.115.146. O pacote é encaminhado através deeth1para o seu destino final. - A máquina B reconhece isso como o pacote de resposta. Ping bem sucedido.
Caso 3: Um pings 10.199.115.146
- Sem minha regra proposta, o pacote original é enviado para a Internet e perdido. Caso contrário, ele será enviado para
10.1.1.2para roteamento, com endereço de origem =10.1.1.1. - A máquina F recebe o pacote e o encaminha através de
eth1. - O pacote é recebido por B e uma resposta é enviada para
10.1.1.1. - A resposta é encaminhada através de
tun0. A regraMASQUERADEaltera o endereço de origem para10.1.1.2. - A máquina A recebe uma resposta de
10.1.1.2, que não é o destino original, e a descarta como não relacionada. Ping falhou
Como você pode ver, há duas maneiras de conectar máquinas da rede interna à VPN:
- Roteamento público: as duas redes conhecem o endereço IP da outra e têm entradas específicas na tabela de rotas para encontrá-las (como a que mostrei para você).
- SNAT / MASQUERADE: Apenas uma rede sabe como alcançar a outra, e o firewall altera o endereço IP de origem dos pacotes de saída dessa rede para o IP do firewall (que é conhecido pela outra rede).
Não use os dois. Se você usar SNAT / MASQUERADE, as tabelas de roteamento em hosts externos não serão aplicáveis, porque o pacote proveniente da rede privada nunca utilizará o endereço original como origem.
Você pode escolher se a máquina A deve estar acessível a partir de B usando PUBLIC_IP ou 10.1.1.1 . Talvez seja possível configurar o firewall de tal forma que ambos funcionem, mas provavelmente não vale a pena o esforço.