Atualmente estou construindo um cluster de nuvem privada usando Proxmox. Meu cluster contém um nó principal e dois nós de computação.
Meu nó principal hospeda um servidor NAT e um servidor openvpn e três NICs: um para saída e um por nó de computação. O NAT me permite fazer interface com ambos os nós de computação. Em ambos os nós de computação, estou hospedando um roteador com aproximadamente 30 vlans por roteador.
Meu objetivo é poder ver o endereço do cliente VPN ao me conectar aos roteadores. Atualmente, eu me conecto ao cabeçote usando o VPN, tento fazer ping ou ssh no roteador e ele mostra a conexão como proveniente do endereço IP do nó principal. Qualquer ajuda é muito apreciada!
Minhas rotas são as seguintes:
default via *.*.*.1 dev eno1 onlink
10.10.1.0/24 via 10.10.1.2 dev tun0
10.10.1.2 dev tun0 proto kernel scope link src 10.10.1.1
*.*.*.0/25 dev eno1 proto kernel scope link src *.*.*.46
192.168.0.0/19 via 192.168.77.1 dev vmbr0
192.168.32.0/19 via 192.168.76.6 dev vmbr1
192.168.76.0/24 dev vmbr1 proto kernel scope link src 10.10.1.1
192.168.77.0/24 dev vmbr0 proto kernel scope link src 192.168.77.1
E a regra NAT (atualmente estou usando o firewalld):
-A POST_public_allow ! -o lo -j MASQUERADE
Responder1
A regra NAT que você mostrou fornece quase nenhuma informação porque modifica umpersonalizadochain, que supostamente é chamada de outras cadeias (padrão) em outras tabelas (supostamente POSTROUTING
da nat
tabela; você pode ver isso usando iptables -t nat -L POSTROUTING
).
O problema que você está enfrentando é que supostamente o mascaramento é aplicado na interface que conecta o nó principal aos nós de computação.
Uma maneira de lidar com isso é ter apenas SNAT na interface que o nó principal usa para se conectar à Internet.
Observe um problema. O fato de você estar usando VPN para acessar o nó principal (se eu li a pergunta corretamente) significa que quando você desativar o mascaramento excessivo no nó principal, seus nós de computação verão os pacotes que você está enviandosobreA VPN vem de qualquer rede em que seu programa de envio esteja localizado. Como é supostamente uma sub-rede privada, você deve garantir que - Tanto a rede de origem quanto a rede que conecta o nó principal e os nós de computação tenham endereços diferentes (e ambos devem ser distintos da sub-rede que o túnel usa) - Os nós de computação deve ter uma regra de rota para sua rede de origem (para enviar os pacotes destinados ao nó principal). - O nó principal deve ter o encaminhamento de IP habilitado.