Dos llocs, una subxarxa: creeu una vista d’àlies per a cadascun
Quan dos llocs utilitzen la mateixa LAN, doneu a cadascun un prefix d’àlies i traduïu en les dues direccions. Comproveu les col·lisions, la política de superposició, els noms DNS i el registre.
Dos llocs de client executen tots dos 192.168.50.0/24, i un enginyer remot ha d’arribar a una impressora a la mateixa adreça en cadascun. Cap truc d’encaminament resol aquesta ambigüitat per si sol. Cada lloc necessita una vista d’adreces diferent, i la passarel·la ha de triar el lloc a partir d’aquesta vista abans de reenviar res.
El pla té quatre parts: prefixos d’àlies, les dues direccions de traducció, política de superposició i noms. Cadascuna ha de conciliar amb les altres.
Trieu un prefix d’àlies per lloc
Assigneu a cada lloc un prefix d’àlies sencer que no pertanyi a ningú més de l’entorn. Un pla de dos llocs podria mapar 192.168.50.0/24 del lloc A a 172.21.10.0/24 i la LAN idèntica del lloc B a 172.21.20.0/24. Comproveu els candidats contra totes les xarxes participants, incloent-hi VPC al núvol i altres pools de VPN. L’espai d’adreces privades el comparteix tota organització, així que que un rang sigui RFC 1918 no diu res sobre si és lliure aquí.
Publiqueu l’àlies, no la subxarxa nativa, als usuaris remots. El rang natiu continua sent un fet local.
Traduïu en les dues direccions
Traduïu en les dues direccions. La mapació de destinació reescriu una adreça d’àlies a l’adreça nativa al lloc propietari. La mapació d’origen reescriu el cridador remot en un àlies que altres llocs poden distingir.
Una mapació estàtica un-a-un és determinista, i això no fa que la implementació no tingui estat. La traducció inversa pot dependre de l’estat de la connexió, i el failover o els camins assimètrics poden trencar un pla que ho ignori. La documentació de la plataforma decideix quins d’aquests casos s’apliquen.
L’etapa exacta on s’apliquen la política, els selectors i les rutes difereix entre IPsec basat en política, túnels basats en rutes i altres productes. Dissenyeu per al que executeu.
Porteu el pla a través de la superposició
En un concentrador, assigneu cada prefix d’àlies al camí del lloc que el posseeix i permeteu només el trànsit que la tasca necessita. En una malla, cada parell rellevant necessita el mateix prefix i coneixement de política. Afegir túnels no arregla l’adreçament ambigu per si sol.
La publicació de tota la subxarxa és més àmplia que publicar un sol servei. Si només calen unes quantes màquines o ports, manteniu les regles d’accés més estretes que la mapació.
La traducció de capçalera no reescriu les càrregues útils de l’aplicació. Les redireccions, les adreces incrustades als fitxers de configuració i els permisos basats en origen poden continuar portant l’adreça nativa. Proveu el camí de l’aplicació, no només el ping. Una resposta ICMP que funciona demostra que la mapació existeix i no diu res sobre si l’aplicació accepta l’àlies.
Arregleu els noms que veu cada cridador
Doneu als noms de manteniment respostes que coincideixin amb la vista del cridador. Si l’enginyer remot resol un nom d’amfitrió, hauria de tornar l’adreça d’àlies d’aquell lloc, no el rang natiu compartit.
Comproveu les vistes DNS per lloc abans de la primera finestra de manteniment. Un nom que resol a la subxarxa nativa torna el cridador a l’ambigüitat que el pla havia de treure.
Registreu i verifiqueu per lloc
Accepteu cada lloc per separat des d’un cridador real i confirmeu quina màquina va respondre. Registreu l’adreça nativa, l’àlies, la passarel·la propietària i el servei permès alhora.
Aquest inventari és el que preserva la distinció quan arriba un tercer lloc amb la mateixa LAN per defecte. La guia d’IPsec NAT basada en política documenta un model de traducció concret; no és un contracte per a totes les plataformes.