Wanneer NAT binne ’n werf-tot-werf-VPN sy plek verdien

Twee terreine gebruik albei dieselfde private reeks, en die tonnel kom op terwyl niks nuttigs dit kruis nie. Vertaling is die gewone antwoord, en dit is ’n werklike een: om ’n ander reeks aan die verre kant voor te hou, kan ’n oorvleueling of ’n terugpad oplos wat die ander netwerk nie kan roeteer nie. Die deel wat oorgeslaan word, is dat vertaling die adresse verander wat elke latere besluit sien. Hanteer dit as ’n gedokumenteerde ontwerpbesluit met ’n geskrewe kartering, nie as ’n reël wat bygevoeg word totdat ’n ping slaag nie.

Bepaal watter adres herskryf word

Bronvertaling verander wat die afgeleë diens en sy logs as die kliënt sien, so ’n tak-gasheer word by aankoms ’n gateway-adres. Bestemming- of voorvoegselvertaling bied eerder ’n alternatiewe adres vir ’n afgeleë hulpbron aan. Sommige ontplooiings benodig gekoördineerde vertaling aan beide kante om twee andersins identiese netwerke te skei, en die kombinasie is waar die meeste verwarring begin.

Skryf die bron voor vertaling neer, die bestemming soos die toepassing dit noem, en die adrespaar waarop elke gateway pas. Drie kolomme is genoeg, en die derde kolom is die een wat mense uitlaat.

Volgorde van keurders maak ook saak. IPsec-beleidskeuring en -vertaling vind op bepaalde stadiums plaas, so ’n keurder wat vir voor-vertaling-adresse geskryf is pas dalk nooit by die pakket op die stadium wat jy aanvaar het nie. Kyk na die beleid wat geïnstalleer is eerder as die beleid wat jy bedoel het om te installeer, want die twee wyk presies af wanneer ’n reël deur een komponent aanvaar en deur ’n ander geïgnoreer is:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

Volg die vrag en die terugpad

’n Bediener wat die vertaalde bron in plaas van die individuele tak-gasheer aanteken, sal enige reël of verslag breek wat op die oorspronklike adres geskoei is. Voordat jy die kartering verander, moet jy uitvind of enigiets stroomaf ’n besluit uit daardie veld maak: toegangslyste, ouditverslae, tempo-beperkings, lisensiekontroles. Elkeen daarvan is ’n plek waar die vertaling later as ’n onverklaarde fout opduik.

Protokolle wat adresse in hul vrag dra, het afsonderlike beplanning nodig, want die herskryf van die buitenste kop raak nie die innerlike verwysing nie. Aktiewe FTP, SIP en sommige afgeleë-toegang-produkte is die klassieke gevalle, en ’n ontwerp wat hulle ignoreer, sal vir webverkeer werk en faal vir die toepassing wat saak gemaak het.

Terugverkeer hang van staatvolle karterings af. Gateway-oorskakeling kan daardie staat verloor, asimmetriese roetering kan dit omseil, en ’n herbegin kan dit skoonmaak terwyl sessies aan die verre kant oop bly. Daarom is ’n versoek wat die bestemming bereik en ’n sessie wat voltooi, twee verskillende aanvaardingsuitslae.

Weeg dit op teen die hernommering van ’n terrein

Hernommering van een botsende terrein verwyder die kartering heeltemal en laat ’n adresplan wat sonder vertalingstabelle gelees kan word. Dit is operasioneel duur: DNS-rekords, statiese toewysings, firewall-reëls en elke gedokumenteerde adres moet saam verander. Die koste kom een keer, in ’n beplande venster, met ’n duidelike eindtoestand. Wat jy koop, is die vermoë om jare later ’n pakketopname sonder ’n naslaantabel te lees.

Vertaling vermy die meeste plaaslike veranderinge en skep ’n kartering wat vir ewig in DNS, dokumentasie en foutsporing onderhou moet word. Die koste kom voortdurend, in die vorm van elke toekomstige ingenieur wat moet leer dat een voorvoegsel iets anders binne die tonnel beteken.

Vir ’n tydelike verbinding of ’n vennootnetwerk wat jy nie beheer nie, is die deurlopende koste gewoonlik die moeite werd. Vir twee terreine wat jy besit en jare lank sal besit, is hernommering dikwels die goedkoper besluit sodra die migrasie eerlik getel word.

Bewys beide rigtings met ’n werklike sessie

Toets ’n toepassingsessie eerder as ’n enkele peiling. ’n Suksesvolle eggo-versoek bewys dat een rigting van een protokol werk, en dit is heeltemal versoenbaar met ’n terugpad wat vir enigiets staatvol faal. Gebruik die diens wat die ontwerp gemotiveer het, en lees sy log aan die verre kant om te sien watter bronadres dit aangeteken het.

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 slegs die beoogde dienste oor die kartering bereikbaar is. Vertaling verander adressering en doen niks aan magtiging nie, so firewall-beleid besluit steeds wat toegelaat word. ’n Ontwerp wat op ’n obskure vertaalde voorvoegsel as sy toegangsbeheer staatmaak, het glad geen toegangsbeheer nie.

Teken die kartering, die getoetsde sessie en die adresse wat elke kant waargeneem het, aan. Die volgende persoon wat hierdie tonnel ontfout, het daardie drie feite meer nodig as die konfigurasielêer.