In my opinion (I'm not an expert) we should just do the VPN to the subnet where the server is, or add this subnet to the VPN configuration on the clinet side.
Sim. Você está certo. Você tem 3 opções:
-
A) Crie uma conexão VPN diretamente com a LAN do servidor (se houver é um firewall habilitado para vpn conectado diretamente à Internet).
-
B) Adicione a sub-rede do servidor à configuração da VPN nos dois lados o túnel e fazer alguma configuração de roteamento (no seu cliente rede) se a LAN do servidor não estiver diretamente conectada ao firewall ou o firewall não é o principal gateway do servidor rede.
-
C) Faça alguma magia de NAT se as opções A e B não estiverem disponíveis (detalhes abaixo).
Assuma o seguinte diagrama (sua configuração atual):
# Duke's Network # # Client's Network #
[ 110.110.1.0/24 ] <----------- VPN Tunnel -----------> [ 192.168.100.0/24 ]
Feitiço NAT # 1: A bola de fogo
Na rede do seu cliente, escolha um endereço IP disponível na rede 192.168.100.0/24 (por exemplo, 192.168.100.254) e crie regras 1-para-1 DNAT e SNAT no firewall de seus clientes apontando para o endereço IP do servidor.
# Connection from Duke's Network to server on client's network
110.110.1.0/24 ------> 192.168.100.254 [DNAT] ------> 192.168.1.68
# Response from the server
192.168.1.68 --------> [SNAT] 192.168.100.254 ------> 110.110.1.0/24
Isso funcionará bem se o firewall for o gateway do servidor ou se for possível configurar algumas rotas no servidor ou ao longo do caminho. A conexão também funcionará nos dois sentidos, o que significa que sua rede ou o servidor podem iniciar conexões entre si.
Se o seu cliente não puder alterar a configuração de roteamento e o firewall não for o gateway do servidor, mas o servidor ainda puder acessar o firewall na rede interna do cliente, faça o seguinte:
Magia NAT, Feitiço # 2: O Portão Arcano
Aqui você irá criar um NAT duplo, um 1-para-1 e um muitos-para-1 (também conhecido como masquerade, na terminologia do iptables):
### REQUEST ###
# Duke's network perspective (notice the 1-to-1 DNAT from Spell #1)
[Duke FW OUT ] 110.110.1.0/24 ---- VPN ----> 192.168.100.254 [ Client FW IN ]
# The packet is inside de Client's FW, here we do another NAT (many-to-1)
# and change de source addr of your network to the internal IP addr of the FW
[ Firewall OUT ] 192.168.100.1 (FW LAN IP) -----> 192.168.1.68
Dessa forma, a conexão parecerá vir do firewall para o servidor. Quando o servidor responder ao FW, inverteremos os NATs.
Observe que, ao usar essa configuração, as conexões só podem ser iniciadas em sua rede. O servidor do cliente poderá responder aos seus pacotes, mas não poderá iniciar qualquer conexão com sua rede.
NAT-Magia, Feitiço # 3: O "Estranho" (também conhecido como O Pesadelo da Administração Abismal)
Aqui, o custo de administração e manutenção aumentará exponencialmente, dependendo de quantos hosts da sua rede o servidor precisa para iniciar conexões .
Essencialmente, existem duas maneiras de fazer essa configuração e se arrepender pelo resto de seus dias (na verdade, lamentar o cliente, já que ele será executado em seu firewall).
-
3a) Vincule um novo endereço IP não utilizado à interface de LAN do firewall do cliente e crie um NAT 1-para-1 apontando para o endereço IP em sua rede que precisa ser acessado por o servidor do cliente. Você precisará fazer isso para cada novo IP em sua rede que precisa ser acessado pelo servidor do cliente.
-
3b) Crie um PAT (Port Address Translation). Nesta configuração, você pode mapear portas TCP | UPD específicas de um endereço IP (o Firewall) para qualquer porta de sua escolha em outro endereço IP (em sua rede). Isso precisará ser executado para cada serviço / porta que precisa ser acessado pelo servidor do cliente em sua rede.
TL; DR: Escolha a opção B e corrija qualquer problema de roteamento.