När NAT inuti en site-till-site-VPN förtjänar sin plats
Översättning kan rädda ett överlappande prefix eller en ensidig returväg, men den ändrar adresserna som varje policy ser. Designa mappningen explicit.
Två platser använder båda samma privata intervall, och tunneln kommer upp medan inget användbart korsar den. Översättning är det vanliga svaret, och det är ett riktigt svar: att presentera ett annat intervall för fjärrsidan kan lösa en överlappning eller en returväg som det andra nätet inte kan routa. Delen som hoppas över är att översättning ändrar adresserna som varje senare beslut ser. Behandla det som ett dokumenterat designbeslut med en skriftlig mappning, inte som en regel som läggs till tills en ping lyckas.
Bestäm vilken adress som skrivs om
Källöversättning ändrar vad fjärrtjänsten och dess loggar ser som klient, så en filialvärd blir en gateway-adress vid ankomst. Destinations- eller prefixöversättning presenterar i stället en alternativ adress för en fjärrresurs. Vissa utrullningar behöver koordinerad översättning på båda sidor för att separera två annars identiska nät, och i kombinationen börjar det mesta av förvirringen.
Skriv ner källan före översättning, destinationen som applikationen kallar den, och adressparet som varje gateway matchar mot. Tre kolumner räcker, och den tredje kolumnen är den folk utelämnar.
Ordningen på selektorerna spelar också roll. Val och översättning av IPsec-policy sker i definierade steg, så en selektor skriven för adresser före översättning matchar kanske aldrig paketet i det steg du antog. Kontrollera policyn som är installerad i stället för policyn du tänkte installera, eftersom de två divergerar exakt när en regel accepteras av en komponent och ignoreras av en annan:
ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat
Följ nyttolasten och returvägen
En server som loggar den översatta källan i stället för den enskilda filialvärden kommer att bryta varje regel eller rapport som är knuten till den ursprungliga adressen. Innan du ändrar mappningen, ta reda på om något nedströms fattar beslut från det fältet: åtkomstlistor, revisionsrapporter, hastighetsgränser, licenskontroller. Var och en av dem är en plats där översättningen senare dyker upp som ett oförklarligt fel.
Protokoll som bär adresser inuti sin nyttolast behöver separat planering, eftersom omskrivning av det yttre huvudet inte rör den inre referensen. Aktiv FTP, SIP och vissa fjärråtkomstprodukter är de klassiska fallen, och en design som ignorerar dem fungerar för webbtrafik och misslyckas för applikationen som betydde något.
Returtrafik beror på stateful mappningar. Gateway-failover kan förlora det tillståndet, asymmetrisk routning kan kringgå det, och en omstart kan rensa det medan sessioner ligger kvar öppna på fjärrsidan. Därför är en begäran som når destinationen och en session som slutförs två olika acceptansresultat.
Väg det mot att numrera om en plats
Omnumrering av en motstridig plats tar bort mappningen helt och lämnar en adressplan som kan läsas utan översättningstabeller. Det är operativt dyrt: DNS-poster, statiska tilldelningar, brandväggsregler och varje dokumenterad adress måste ändras tillsammans. Kostnaden kommer en gång, i ett planerat fönster, med ett tydligt sluttillstånd. Det du köper är förmågan att läsa en paketfångst år senare utan en uppslagstabell.
Översättning undviker de flesta lokala ändringar och skapar en mappning som måste underhållas i DNS, dokumentation och felsökning för alltid. Kostnaden kommer kontinuerligt, i form av varje framtida ingenjör som måste lära sig att ett prefix inuti tunneln betyder något annat.
För en tillfällig anslutning eller ett partnernät du inte kontrollerar är den löpande kostnaden oftast värd det. För två platser du äger och kommer att äga i åratal är omnumrering ofta det billigare beslutet när migreringen räknas ärligt.
Bevisa båda riktningarna med en riktig session
Testa en applikationssession i stället för en enda sond. En lyckad ekoanfrågan bevisar att en riktning av ett protokoll fungerar, och den är helt förenlig med en returväg som misslyckas för allt stateful. Använd tjänsten som motiverade designen, och läs dess logg i fjärränden för att se vilken källadress den registrerade.
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
Bekräfta sedan att bara de avsedda tjänsterna är nåbara via mappningen. Översättning ändrar adressering och gör ingenting för auktorisering, så brandväggspolicyn avgör fortfarande vad som tillåts. En design som förlitar sig på ett otydligt översatt prefix som sin åtkomstkontroll har ingen åtkomstkontroll alls.
Registrera mappningen, den testade sessionen och adresserna som varje sida observerade. Nästa person som felsöker den här tunneln behöver de tre fakta mer än konfigurationsfilen.