Wanneer NAT binnen een site-naar-site-VPN zijn plek verdient
Vertaling kan een overlappend prefix of een eenzijdig retourpad redden, maar het verandert de adressen die elk beleid ziet. Ontwerp de mapping expliciet.
Twee locaties gebruiken allebei hetzelfde privébereik, en de tunnel komt op terwijl er niets nuttigs doorheen gaat. Vertaling is het gebruikelijke antwoord, en het is een echt antwoord: een ander bereik aan de verre kant presenteren kan een overlap of een retourpad oplossen dat het andere netwerk niet kan routeren. Het deel dat wordt overgeslagen is dat vertaling de adressen verandert die elke latere beslissing ziet. Behandel het als een gedocumenteerde ontwerpbeslissing met een schriftelijke mapping, niet als een regel die wordt toegevoegd tot een ping slaagt.
Bepaal welk adres wordt herschreven
Bronvertaling verandert wat de externe dienst en zijn logs als client zien, zodat een filiaalhost bij aankomst een gateway-adres wordt. Bestemmings- of prefixvertaling presenteert in plaats daarvan een alternatief adres voor een externe bron. Sommige implementaties hebben gecoördineerde vertaling aan beide kanten nodig om twee verder identieke netwerken te scheiden, en in de combinatie begint de meeste verwarring.
Schrijf de bron vóór vertaling op, de bestemming zoals de applicatie die noemt, en het adrespaar waarop elke gateway matcht. Drie kolommen zijn genoeg, en de derde kolom is degene die mensen weglaten.
De volgorde van de selectors is ook belangrijk. Selectie en vertaling van IPsec-beleid gebeuren in gedefinieerde fasen, dus een selector geschreven voor adressen vóór vertaling matcht mogelijk nooit het pakket in de fase die u aannam. Controleer het beleid dat is geïnstalleerd in plaats van het beleid dat u van plan was te installeren, want de twee divergeren precies wanneer een regel door het ene onderdeel wordt geaccepteerd en door het andere genegeerd:
ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat
Volg de payload en het retourpad
Een server die de vertaalde bron logt in plaats van de afzonderlijke filiaalhost, breekt elke regel of rapport dat aan het oorspronkelijke adres is gekoppeld. Voordat u de mapping wijzigt, moet u nagaan of iets stroomafwaarts een beslissing neemt op basis van dat veld: toegangslijsten, auditrapporten, snelheidslimieten, licentiecontroles. Elk daarvan is een plek waar de vertaling later als een onverklaarde fout opduikt.
Protocollen die adressen in hun payload dragen, vereisen aparte planning, omdat het herschrijven van de buitenste header de interne verwijzing niet raakt. Actief FTP, SIP en sommige producten voor externe toegang zijn de klassieke gevallen, en een ontwerp dat ze negeert, werkt voor webverkeer en faalt voor de applicatie die ertoe deed.
Retourverkeer is afhankelijk van stateful mappings. Gateway-failover kan die status verliezen, asymmetrische routering kan hem omzeilen, en een herstart kan hem wissen terwijl sessies aan de verre kant open blijven. Daarom zijn een verzoek dat de bestemming bereikt en een sessie die voltooid wordt twee verschillende acceptatieresultaten.
Weeg het af tegen het hernummeren van een locatie
Het hernummeren van één conflicterende locatie verwijdert de mapping volledig en laat een adresplan achter dat zonder vertalingstabellen leesbaar is. Het is operationeel duur: DNS-records, statische toewijzingen, firewallregels en elk gedocumenteerd adres moeten samen veranderen. De kosten komen één keer, in een gepland venster, met een duidelijke eindtoestand. Wat u koopt is het vermogen om jaren later een packet capture te lezen zonder opzoektabel.
Vertaling vermijdt de meeste lokale wijzigingen en creëert een mapping die voor altijd moet worden onderhouden in DNS, documentatie en probleemoplossing. De kosten komen continu, in de vorm van elke toekomstige engineer die moet leren dat één prefix binnen de tunnel iets anders betekent.
Voor een tijdelijke verbinding of een partnernetwerk dat u niet beheert, zijn de doorlopende kosten meestal de moeite waard. Voor twee locaties die u bezit en jaren zult bezitten, is hernummeren vaak de goedkopere beslissing zodra de migratie eerlijk wordt geteld.
Bewijs beide richtingen met een echte sessie
Test een applicatiesessie in plaats van één probe. Een geslaagd echo-verzoek bewijst dat één richting van één protocol werkt, en het is volledig verenigbaar met een retourpad dat faalt voor alles wat stateful is. Gebruik de dienst die het ontwerp motiveerde, en lees het log aan de verre kant om te zien welk bronadres het heeft vastgelegd.
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
Bevestig dan dat alleen de bedoelde diensten bereikbaar zijn via de mapping. Vertaling verandert de adressering en doet niets voor autorisatie, dus firewallbeleid bepaalt nog steeds wat is toegestaan. Een ontwerp dat vertrouwt op een onduidelijk vertaald prefix als toegangscontrole heeft helemaal geen toegangscontrole.
Leg de mapping, de geteste sessie en de adressen die elke kant heeft waargenomen vast. De volgende persoon die deze tunnel debugt, heeft die drie feiten meer nodig dan het configuratiebestand.