Quan el NAT dins d’una VPN de lloc a lloc es guanya el seu lloc
La traducció pot rescatar un prefix superposat o un camí de retorn unilateral, però canvia les adreces que veu cada política. Dissenyeu el mapatge explícitament.
Dos llocs fan servir el mateix rang privat, i el túnel s’aixeca mentre res d’útil el travessa. La traducció és la resposta habitual, i és una resposta real: presentar un rang diferent al costat remot pot resoldre una superposició o un camí de retorn que l’altra xarxa no pot encaminar. La part que s’omet és que la traducció canvia les adreces que veu cada decisió posterior. Tracteu-ho com una decisió de disseny documentada amb un mapatge escrit, no com una regla afegida fins que un ping té èxit.
Decidiu quina adreça es reescriu
La traducció d’origen canvia el que el servei remot i els seus registres veuen com a client, de manera que un amfitrió de branca es converteix en una adreça de passarel·la en arribar. La traducció de destinació o de prefix presenta en canvi una adreça alternativa per a un recurs remot. Alguns desplegaments necessiten traducció coordinada als dos costats per separar dues xarxes idèntiques, i la combinació és on comença la major part de la confusió.
Anoteu l’origen abans de la traducció, la destinació tal com l’anomena l’aplicació i el parell d’adreces amb què coincideix cada passarel·la. Tres columnes són suficients, i la tercera columna és la que la gent omet.
L’ordre dels selectors també importa. La selecció i la traducció de polítiques IPsec es fan en etapes definides, així que un selector escrit per a adreces prèvies a la traducció pot no coincidir mai amb el paquet a l’etapa que heu suposat. Comproveu la política que està instal·lada en lloc de la que pensàveu instal·lar, perquè les dues divergeixen exactament quan un component accepta una regla i un altre l’ignora:
ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat
Seguiu la càrrega útil i el camí de retorn
Un servidor que registra l’origen traduït en lloc de l’amfitrió de branca individual trencarà qualsevol regla o informe lligat a l’adreça original. Abans de canviar el mapatge, esbrineu si alguna cosa més avall pren una decisió a partir d’aquest camp: llistes d’accés, informes d’auditoria, límits de velocitat, comprovacions de llicència. Cadascun d’aquests és un lloc on la traducció apareix més tard com una fallada inexplicada.
Els protocols que porten adreces dins de la seva càrrega útil necessiten una planificació separada, perquè reescriure la capçalera externa no toca la referència interna. FTP actiu, SIP i alguns productes d’accés remot són els casos clàssics, i un disseny que els ignori funcionarà per al tràfic web i fallarà per a l’aplicació que importava.
El tràfic de retorn depèn de mapatges amb estat. La commutació per error de la passarel·la pot perdre aquest estat, l’encaminament asimètric pot evitar-lo, i un reinici el pot esborrar mentre les sessions continuen obertes al costat remot. Per això una sol·licitud que arriba a la destinació i una sessió que es completa són dos resultats d’acceptació diferents.
Peseu-ho contra la renumeració d’un lloc
Renumerar un lloc en conflicte elimina el mapatge del tot i deixa un pla d’adreces que es pot llegir sense taules de traducció. És car operativament: els registres DNS, les assignacions estàtiques, les regles del tallafoc i cada adreça documentada han de canviar alhora. El cost arriba una vegada, en una finestra planificada, amb un estat final clar. El que compreu és la capacitat de llegir una captura de paquets anys després sense una taula de consulta.
La traducció evita la majoria de canvis locals i crea un mapatge que s’ha de mantenir en DNS, documentació i resolució de problemes per sempre. El cost arriba contínuament, en forma de cada futur enginyer que ha d’aprendre que un prefix significa una altra cosa dins del túnel.
Per a una connexió temporal o una xarxa de soci que no controleu, el cost continu sovint val la pena. Per a dos llocs que poseïu i posseireu durant anys, la renumeració sovint és la decisió més barata un cop la migració es compta honestament.
Demostreu tots dos sentits amb una sessió real
Proveu una sessió d’aplicació en lloc d’una sonda única. Una sol·licitud d’eco correcta demostra que un sentit d’un protocol funciona, i és del tot compatible amb un camí de retorn que falla per a qualsevol cosa amb estat. Feu servir el servei que va motivar el disseny i llegiu-ne el registre a l’extrem remot per veure quina adreça d’origen va registrar.
tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20
Després confirmeu que només els serveis previstos són accessibles a través del mapatge. La traducció canvia l’adreçament i no fa res per a l’autorització, així que la política del tallafoc continua decidint què es permet. Un disseny que es basa en un prefix traduït obscur com a control d’accés no té cap control d’accés.
Registreu el mapatge, la sessió provada i les adreces que va observar cada costat. La propera persona que depuri aquest túnel necessita aquests tres fets més que no pas el fitxer de configuració.