Encamina entre LAN privadas antes de engadir outro NAT

Dous devasas internas, un segmento de tránsito privado e unha petición para que uns cantos equipos de cada LAN falen cos da outra. O reflexo é levantar unha VPN ou engadir unha segunda capa de NAT, e ambos os reflexos custan máis do que o problema merece. O encamiñamento ordinario abonda cando se cumpren tres condicións: os rangos de enderezos non se solapan, ambos os lados poden devolver tráfico á outra LAN e o segmento de tránsito xa é o bastante fiable para os datos. Comproba eses tres antes de deseñar nada, porque cada un cambia a resposta.

Tres condicións que deciden o deseño

A primeira condición é o espazo de enderezos. Se ambas as LAN usan o mesmo bloque RFC 1918, o encamiñamento non pode distinguilas e a tradución pasa a ser inevitable en lugar de opcional. A segunda é unha ruta de volta: unha ruta de A a B é inútil se B tampouco sabe como chegar á LAN de A, e o coñecemento asimétrico é a razón máis común de que un deseño encamiñado descarte respostas en silencio.

A terceira é a confianza. O encamiñamento move paquetes; non os protexe. Un segmento de tránsito privado dentro dun edificio é algo distinto dunha entrega a un provedor ou dunha ligazón que cruza unha columna vertebral compartida de campus. Se o segmento non é fiable, a resposta é un túnel entre as dúas devasas, e o plan de encamiñamento de abaixo segue aplicándose dentro del.

Só cando as tres apuntan na mesma dirección gaña o deseño simple. Cando unha falla, corrixe esa condición de forma explícita en lugar de tapala con tradución, porque o NAT oculta o fallo en vez de resolvelo.

Constrúe o plan de rutas sobre a rede de tránsito

Dálle a cada devasa un enderezo no segmento compartido e engade unha ruta concreta por cada LAN remota. Nada máis da configuración existente ten que moverse, e en particular a ruta por defecto a internet debe quedar exactamente onde está. Substituír unha ruta por defecto pola devasa par enviaría cada destino non relacionado a través do tránsito, o que é un cambio moito maior que o que se pide. A documentación de pfSense sobre encamiñamento estático describe o mesmo modelo de ruta máis porta de enlace para esa plataforma, e o control equivalente existe en calquera devasa que executes.

A devasa A serve 10.30.0.0/24 e a devasa B serve 10.40.0.0/24, coas dúas direccións de tránsito en 192.0.2.0/24. Cada equipo da LAN mantén a súa devasa local como porta de enlace, así que o único estado novo é unha ruta en cada lado. Nunha devasa baseada en Linux o mesmo plan vese así, e o reenvío debe estar activado ou a ruta resolverase mentres o paquete se descarta.

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

Mantén o filtrado separado da tradución

O encamiñamento e a política son controis distintos, e é no segundo onde fallan de verdade a maioría dos deseños encamiñados. Permite as fontes, destinos e servizos concretos na fronteira de entrada que os paquetes cruzan realmente, e lembra que unha etiqueta de interface como WAN é un nome, non unha afirmación sobre a confianza. Un porto de tránsito que leva tráfico privado pode seguir tendo o bloqueo de enderezos privados activado por defecto.

Despois mira a tradución de saída antes de concluír que non hai NAT. As regras automáticas de saída poden reescribir tráfico que nunca debía traducirse, o que destrúe os enderezos de orixe que o outro lado necesita para a súa propia política e os seus rexistros. Confirma que os fluxos seleccionados conservan os enderezos orixinais e deixa tranquilas as regras de tradución de internet para o tráfico que aínda as necesita.

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

Cando o NAT é a resposta honesta

A tradución gaña o seu sitio cando os rangos de enderezos realmente se solapan e a renumeración non está dispoñible, ou cando unha política esixe que un lado vexa un único enderezo en lugar dunha subrede. Neses casos, unha asignación deliberada un a un ou restrinxida por portos é unha decisión de deseño con consecuencias coñecidas, non unha solución improvisada.

A consecuencia que hai que dicir en voz alta é que o outro lado xa non pode ver nin filtrar fontes individuais. Os rexistros colápsanse no enderezo que traduce, a política por equipo deixa de funcionar e a resolución de problemas convértese nunha caza de que equipo interno tiña un fluxo nun momento dado. Se nada diso importa para o tráfico en cuestión, o NAT está ben.

Cando o propio tránsito é a suposición equivocada

Se o segmento compartido cruza un provedor, unha matriz de conmutación compartida ou calquera camiño onde outra parte puidese ler o tráfico, o encamiñamento por si só non é unha resposta completa. Un túnel entre as dúas devasas dálle confidencialidade e autenticación do par, e a táboa de rutas dentro del é a mesma táboa que escribirías no tránsito.

Decídeo a partir da pregunta de confianza da primeira sección, non dun costume de que as VPN son máis seguras. Un túnel sobre un segmento que xa é privado engade custo operativo e outro modo de fallo sen ganancia, mentres que encamiñar sobre un segmento non fiable cambia confidencialidade por unha sinxeleza que non podes permitirte. Anota cal das tres condicións impulsou a elección e o seguinte enxeñeiro non terá que volver discutirlo.