Encamina el trànsit entre LAN privades abans d’afegir una altra NAT
Un espai d’adreces solapat, una ruta de tornada que falta o un trànsit no fiable decideixen entre encaminament, NAT i túnel. Comprova aquests tres punts abans d’editar el tallafoc.
Dos tallafocs interns, un segment de trànsit privat i una petició perquè uns quants equips de cada LAN puguin parlar amb els de l’altra. El reflex és aixecar una VPN o afegir una segona capa de NAT, i tots dos reflexes costen més del que el problema mereix. L’encaminament ordinari n’hi ha prou quan es compleixen tres condicions: els rangs d’adreces no se solapen, les dues bandes poden retornar trànsit a l’altra LAN i el segment de trànsit ja és prou fiable per a les dades. Comprova aquestes tres coses abans de dissenyar res, perquè cadascuna canvia la resposta.
Tres condicions que decideixen el disseny
La primera condició és l’espai d’adreces. Si les dues LAN fan servir el mateix bloc RFC 1918, l’encaminament no les pot distingir i la traducció es torna inevitable en lloc d’opcional. La segona és un camí de tornada: una ruta d’A a B és inútil si B tampoc no sap com arribar a la LAN d’A, i el coneixement asimètric és el motiu més habitual que un disseny encaminat descarti respostes en silenci.
La tercera és la confiança. L’encaminament mou paquets; no els protegeix. Un segment de trànsit privat dins d’un edifici és una cosa diferent d’un lliurament a un proveïdor o d’un enllaç que travessa una columna vertebral compartida de campus. Si el segment no és fiable, la resposta és un túnel entre els dos tallafocs, i el pla d’encaminament de sota encara s’hi aplica a dins.
Només quan les tres apunten en la mateixa direcció guanya el disseny simple. Quan una falla, corregeix aquella condició explícitament en lloc de tapar-la amb traducció, perquè la NAT amaga la fallada en lloc de resoldre-la.
Construeix el pla de rutes sobre la xarxa de trànsit
Dona a cada tallafoc una adreça al segment compartit i afegeix una ruta específica per cada LAN remota. Res més de la configuració existent no s’ha de moure, i en particular la ruta per defecte d’internet ha de quedar exactament on és. Substituir una ruta per defecte pel tallafoc de l’altra banda enviaria cada destinació no relacionada a través del trànsit, que és un canvi molt més gran que el que es demana. La documentació de pfSense sobre encaminament estàtic descriu el mateix model de ruta més porta d’enllaç per a aquesta plataforma, i el control equivalent existeix a qualsevol tallafoc que facis servir.
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
El tallafoc A serveix 10.30.0.0/24 i el tallafoc B serveix 10.40.0.0/24, amb les dues adreces de trànsit a 192.0.2.0/24. Cada equip de la LAN manté el seu tallafoc local com a porta d’enllaç, així que l’únic estat nou és una ruta a cada costat. En un tallafoc basat en Linux el mateix pla es veu així, i cal activar el reenviament o la ruta es resoldrà mentre el paquet es 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 el filtratge separat de la traducció
L’encaminament i la política són controls diferents, i és en el segon on fallen de veritat la majoria de dissenys encaminats. Permet les fonts, destinacions i serveis concrets a la frontera d’entrada que els paquets travessen realment, i recorda que una etiqueta d’interfície com WAN és un nom, no una declaració sobre la confiança. Un port de trànsit que porta trànsit privat pot tenir encara el bloqueig d’adreces privades activat per defecte.
Després mira la traducció de sortida abans de concloure que no hi ha cap NAT. Les regles automàtiques de sortida poden reescriure trànsit que mai no s’havia de traduir, cosa que destrueix les adreces d’origen que l’altra banda necessita per a la seva pròpia política i els seus registres. Confirma que els fluxos seleccionats conserven les adreces originals i deixa tranquil·les les regles de traducció d’internet per al trànsit que encara les necessita.
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
Quan la NAT és la resposta honesta
La traducció guanya el seu lloc quan els rangs d’adreces realment se solapen i la renumeració no està disponible, o quan una política exigeix que una banda vegi una sola adreça en lloc d’una subxarxa. En aquests casos, un mapatge deliberat u a u o restringit per ports és una decisió de disseny amb conseqüències conegudes, no una solució improvisada.
La conseqüència que cal dir en veu alta és que l’altra banda ja no pot veure ni filtrar fonts individuals. Els registres es col·lapsen a l’adreça que tradueix, la política per equip deixa de funcionar i la resolució de problemes es converteix en una cacera de quin equip intern tenia un flux en un moment donat. Si res d’això no importa per al trànsit en qüestió, la NAT està bé.
Quan el trànsit mateix és la suposició equivocada
Si el segment compartit travessa un proveïdor, una matriu de commutació compartida o qualsevol camí on una altra part podria llegir el trànsit, l’encaminament sol no és una resposta completa. Un túnel entre els dos tallafocs et dona confidencialitat i autenticació de l’altra banda, i la taula de rutes a dins és la mateixa taula que hauries escrit al trànsit.
Decideix-ho a partir de la pregunta de confiança de la primera secció, no d’un costum que les VPN són més segures. Un túnel sobre un segment que ja és privat afegeix cost operatiu i un altre mode de fallada sense cap guany, mentre que encaminar sobre un segment no fiable canvia confidencialitat per una simplicitat que no et pots permetre. Anota quina de les tres condicions va impulsar l’elecció i el proper enginyer no l’haurà de tornar a discutir.