Quero conectar várias LANs localizadas em prédios remotos.
O site "central" possui um computador Linux executando o OpenVPN. Cada site remoto também executa o OpenVPN.
- o site central possui uma LAN numerada 192.168.0.0/24
- vários sites remotos também são numerados 192.168.0.0/24
- Não posso / não quero / não quero / modificar a numeração da LAN
- Não tenho controle na maioria dos OpenVPNs remotos
Em seguida, preciso:
1. definir LANs virtuais
2. configurar um NAT 1: 1 para cada site
3. o 1: 1 NAT deve ser configurado no roteador central
.
Portanto, cada site possui uma LAN 10.10.x.0 / 24.
Quando um computador deseja acessar, digamos, 192.168.0.44 no site 12, basta enviar um paquet para 10.10.12.44
Operar uma VPN não é um problema para mim. Atualmente, conecto mais de 60 sites. Mas não encontro uma maneira simples de fazer isso NAT 1: 1.
Aqui está um exemplo de um pacote enviado do site central para um site remoto e seu pacote de resposta:
Fiz alguns testes com o iptables NETMAP, mas não consigo fazê-lo funcionar porque não encontro uma maneira de modificar a origem + o destino após a decisão de roteamento.
Prefiro evitar o novo --client-nat
recurso do OpenVPN.
Talvez eu tenha que forçar o roteamento com ip route
? Ou para fazer um loop duas vezes na pilha de rede com veth
?
Nota: Não quero usar máscaras. Apenas 1/1 NAT.
EDIT:
Não é possível com uma configuração openVPN regular. Como um pacote de um site remoto é indistinguível de um pacote de outro site: ambos têm endereços de origem e destino semelhantes e ambos vêm da mesma interface de tun (ou toque). Portanto, não é possível obter o NAT da fonte.
Solução 1: faça o NAT nos sites remotos. Não é possível no meu caso. Eu tenho que fazer isso apenas no site central.
Solução 2: configure uma VPN para cada site remoto. Então eu vou ter um tun para cada um. Eu acho que isso pode estar bem. Memória não muito eficiente, mas ok.
Solução 3: configure um túnel (não criptografado) dentro da VPN para cada site. Isso dará uma interface para cada um. Túneis simples não são multiplataforma (até onde eu sei). Por exemplo, GRE ou ipip ou sit são válidos para Linux, mas alguns sites distantes estão executando apenas um computador Windows, portanto o openVPN está instalado nele. Tão impossível configurar um túnel simples. Outra opção é usar um túnel mais complicado (qual?), Mas a sobrecarga no sistema e no administrador de sistemas pode ser maior do que ter várias VPNs
Solução 4: compile o openVPN mais recente, pois inclui um recurso NAT 1: 1. Eu testei esta semana.
Respostas:
Uma solução muito básica é:
1. use o OpenVPN 2.3 ou mais (atualmente, o mais recente é o 2.3-alpha) para servidores + clientes
2. use a opção de configuração do OpenVPN abaixo
3. não use mais nada (sem ipfilter, sem truques)
No lado do servidor, você precisa distribuir manualmente os endereços VPN (portanto, nenhuma
server
opção, você deve usarifconfig
ouifconfig-push
):As linhas
route
epush route
eclient-nat
são necessárias se você deseja se comunicar diretamente entre roteadores (ping 10.99.99.1
de um site distante através da VPN). Senão você pode descartá-los..
.
Agora você tem que escolher um endereço de rede virtual. Eu mantive o mesmo que você usou no seu exemplo: 10.10.0.0/16
Você permite o roteamento para isso:
.
.
Agora você precisa instruir o cliente a usar o NAT 1: 1:
A primeira linha define o endereço do roteador remoto. Cuidado com o driver do Windows que requer endereços especiais.
A segunda e a última linha permitem que o roteador distante se comunique a partir da interface 10.99.99.x.
Terceira e quarta linhas fazem o NAT 1: 1 de origem e destino
A quinta linha diz ao OpenVPN o que fazer com os pacotes correspondentes.
Este método permite conectar sites com endereços LAN idênticos (ou não), sem nenhum host sombreado.
fonte
Fiz algo semelhante com interfaces reais, mas não vejo por que não funcionaria com interfaces VPN.
A idéia é que, como você tem a mesma sub-rede disponível em interfaces diferentes nesse roteador, isso complica o roteamento. Basicamente, quando um pacote para 10.10.13.123 entra no roteador, ele é DNATed antes de rotear para 192.168.0.123, portanto, você deve poder dizer ao roteamento que ele foi destinado ao 192.168.0.123 na interface VPN13 .
Isso pode ser feito usando marcas de firewall e regras de roteamento que usam essas marcas. SNAT e DNAT devem ser feitos com o destino do firewall NETMAP. Para SNAT, é o mesmo problema: em POSTROUTING, você perdeu as informações de que o pacote veio dessa ou daquela interface e todos eles têm o endereço de origem 192.168.0.x. Portanto, você também precisa de uma marca para transportar essas informações de mangle-PREROUTING para nat-POSTROUTING. Você pode usar a mesma marca, mas isso significaria que esses pacotes usariam essa tabela de roteamento alternativa, portanto, seria necessário duplicar a tabela de roteamento global.
Para cada rede, você faria:
Acima, estamos usando os primeiros 4 bits da marca , para permitir que até 7 redes sejam roteadas dessa maneira.
fonte