Encaminhe entre LANs privadas antes de adicionar outro NAT

Duas firewalls internas, um segmento de trânsito privado e um pedido para deixar alguns hosts de cada LAN falar com os da outra. O reflexo é levantar uma VPN ou acrescentar uma segunda camada de NAT, e ambos os reflexos custam mais do que o problema merece. O encaminhamento comum basta quando três condições se verificam: as faixas de endereços não se sobrepõem, os dois lados conseguem devolver tráfego à outra LAN e o segmento de trânsito já é suficientemente confiável para os dados. Verifique essas três antes de projetar qualquer coisa, porque cada uma muda a resposta.

Três condições que decidem o projeto

A primeira condição é o espaço de endereços. Se as duas LANs usam o mesmo bloco RFC 1918, o encaminhamento não consegue distingui-las e a tradução torna-se inevitável em vez de opcional. A segunda é um caminho de retorno: uma rota de A para B é inútil a menos que B também saiba como chegar à LAN de A, e o conhecimento assimétrico é a razão mais comum de um projeto encaminhado descartar respostas em silêncio.

A terceira é a confiança. O encaminhamento move pacotes; não os protege. Um segmento de trânsito privado dentro de um edifício é coisa diferente de uma entrega a um provedor ou de um link que cruza uma espinha dorsal de campus partilhada. Se o segmento não é confiável, a resposta é um túnel entre as duas firewalls, e o plano de rotas abaixo continua a aplicar-se dentro dele.

Só quando as três apontam no mesmo sentido o projeto simples ganha. Quando uma falha, corrija essa condição explicitamente em vez de a cobrir com tradução, porque o NAT esconde a falha em vez de a resolver.

Construa o plano de rotas na rede de trânsito

Dê a cada firewall um endereço no segmento partilhado e acrescente uma rota específica por cada LAN remota. Mais nada da configuração existente precisa de se mexer, e em particular a rota predefinida para a internet deve ficar exatamente onde está. Substituir uma rota predefinida pela firewall par enviaria cada destino não relacionado através do trânsito, o que é uma alteração muito maior do que a pedida. A documentação do pfSense sobre encaminhamento estático descreve o mesmo modelo de rota mais gateway para essa plataforma, e o controlo equivalente existe em qualquer firewall que execute realmente.

A firewall A serve 10.30.0.0/24 e a firewall B serve 10.40.0.0/24, com os dois endereços de trânsito em 192.0.2.0/24. Cada host da LAN mantém a firewall local como gateway, pelo que o único estado novo é uma rota de cada lado. Numa firewall baseada em Linux o mesmo plano aparece assim, e o encaminhamento tem de estar ativo, senão a rota resolve-se mas o pacote é descartado.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Mantenha a filtragem separada da tradução

Encaminhamento e política são controlos diferentes, e é no segundo que a maioria dos projetos encaminhados falha de facto. Permita as fontes, destinos e serviços concretos na fronteira de entrada que os pacotes realmente atravessam, e lembre-se de que um rótulo de interface como WAN é um nome, não uma afirmação sobre confiança. Uma porta de trânsito que transporta tráfego privado pode continuar a ter o bloqueio de endereços privados ativo por omissão.

Depois olhe para a tradução de saída antes de concluir que não há NAT. Regras de saída automáticas podem reescrever tráfego que nunca foi destinado a ser traduzido, e isso destrói os endereços de origem de que o outro lado precisa para a sua própria política e registos. Confirme que os fluxos selecionados mantêm os endereços originais e deixe as regras de tradução da internet em paz para o tráfego que ainda precisa delas.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Quando o NAT é a resposta honesta

A tradução ganha o seu lugar quando as faixas de endereços se sobrepõem de facto e a renumeração não está disponível, ou quando uma política exige que um lado veja um único endereço em vez de uma sub-rede. Nesses casos, um mapeamento deliberado um-para-um ou restrito por portas é uma decisão de projeto com consequências conhecidas, não um remendo.

A consequência que tem de ser dita em voz alta é que o outro lado deixa de poder ver ou filtrar fontes individuais. Os registos colapsam no endereço tradutor, a política por host deixa de funcionar e a resolução de problemas passa a ser uma caça a que host interno detinha um fluxo num dado momento. Se nada disso importar para o tráfego em causa, o NAT está bem.

Quando o próprio trânsito é a suposição errada

Se o segmento partilhado atravessa um provedor, uma matriz de comutação partilhada ou qualquer caminho onde outra parte pudesse ler o tráfego, o encaminhamento sozinho não é uma resposta completa. Um túnel entre as duas firewalls dá confidencialidade e autenticação do par, e a tabela de rotas lá dentro é a mesma tabela que teria escrito no trânsito.

Decida isso a partir da pergunta de confiança da primeira secção, não de um hábito de que as VPN são mais seguras. Um túnel sobre um segmento que já é privado acrescenta custo operacional e mais um modo de falha sem ganho, enquanto o encaminhamento sobre um segmento não confiável troca confidencialidade por uma simplicidade que não pode pagar. Anote qual das três condições conduziu a escolha, e o próximo engenheiro não terá de a discutir outra vez.