Zamenjajte ponudnika brez preštevilčenja naslovov VPN lokacije

Podružnica zamenja internetnega ponudnika, datotečni strežnik pa obdrži svoj naslov. Ta izid je običajen pri usmerjenem VPN lokacije in presenetljiv za vsakogar, ki domneva, da je naslov končne točke tunela naslov aplikacije. Oba živita v različnih plasteh zasnove in premaknil se je le eden. Obravnavati ju kot eno je način, kako migracija ponudnika postane projekt preštevilčenja.

Dva načrta naslovov, ki se premikata neodvisno

Notranji načrt opisuje zasebne naslove, ki jih uporabljajo aplikacije: strežnik podružnice na 10.55.8.20, predpona sedeža, ki usmerja tja, in povratna pot. Zunanji načrt opisuje, kako se dva prehoda dosežeta: naslovi partnerjev, vrata za poslušanje in pot čez internet.

Zamenjava ponudnika se dotakne zunanjega načrta. Sama po sebi ne zahteva spremembe notranjega načrta.

Ločeno vodenje obeh evidenc je praktični razlog za prekrivno omrežje tudi takrat, ko aplikacija že sama šifrira svoj promet. Prekrivno omrežje vam da stabilno notranjo topologijo, ki preživi zunanje spremembe. Aplikacija obdrži svoj naslov, pravila požarnega zidu in zapise DNS. Spremenijo se le transportni vnosi, in to je veliko manjši pregled.

Zunanji tunel nosi notranji pogovor

V tunelu prehod-proti-prehodu zunanja glava IP naslavlja oba prehoda. Notranja glava še vedno imenuje dejanske končne točke aplikacije. Opis prehod-proti-prehodu v RFC 7296 to obravnava kot običajno usmerjanje, ki dostavlja promet skozi končne točke tunela.

Zato lahko strežnik podružnice obdrži 10.55.8.20, medtem ko se javni naslov prehoda spreminja. Notranji paket sploh ne vsebuje naslova ponudnika.

Ločitev je lastnost zasnove, ne samodejno jamstvo. Če nadomestna povezava ne more vzpostaviti podprtega tunela ali se notranje poti ne namestijo znova, aplikacija izgubi svojo pot, čeprav se njen naslov ni spremenil.

Premik ponudnika ima še vedno kontrolni seznam

Zunanji kontrolni seznam ima pet postavk: naslov partnerja ali vzdrževano ime, poslušalec in kakršno koli filtriranje višje, prevod na poti, pričakovana identiteta partnerja in dovoljene nastavitve drugega prehoda. Vsaka lahko odpove sama. Med spreminjanjem povezave, ki nosi upravljanje, držite ločeno pot za obnovitev. Prekinitev oddaljenega dostopa med prehodom na novo povezavo je izpad, ki ste ga povzročili sami.

Nato preverite predpono podružnice, pot v obeh smereh, zaščitno politiko in en resničen tok aplikacije. Sveže overjen tunel ne popravi poti, ki kaže na staro zasebno podomrežje.

Prekrivanje naslovov z drugo povezano lokacijo je ločen načrtovalski problem. Zamenjava ponudnika ga ne ustvari, a migracija je običajno trenutek, ko se pokaže.

Kaj ne preživi: javni vir in seje

Stabilen zasebni naslov strežnika ni stabilen javni vir. Če brskanje izhaja neposredno skozi novega ponudnika, spletna mesta vidijo novi naslov, obrnjen k ponudniku.

Ohranjanje tega naslova stabilnega zahteva premišljeno zasnovo izhoda z lastno razpoložljivostjo in politiko. Ta ne pride brezplačno s tunelom.

Tudi vzpostavljene seje ne preživijo spremembe poti. Tunel se lahko obnovi v nekaj sekundah in vseeno pretrga dolgotrajne povezave, pripete na staro pot. Načrtujte prehod za okno, v katerem so ponovne povezave sprejemljive. Ne trdite, da bo migracija nevidna, dokler niso preizkušeni konkretni odjemalci in njihovi časovni omejitvi.

Preverite premik s štirimi kontrolami

Po spremembi po vrsti preverite štiri stvari: tunel je vzpostavljen z načrtovanim partnerjem, notranja pot do predpone podružnice obstaja, politika dovoljuje tok aplikacije in aplikacija odgovori. Vsaka ima svoj ukaz.

Na prehodu Linux te tri pokrivajo sredino tega seznama:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Transportne naslove držite v eni evidenci, naslove aplikacij pa v drugi. Posodobite le vnose, ki so se zares premaknili. Preštevilčenje notranjih odvisnosti zaradi spremembe zunanjega naslova tunela je delo, ki se mu je mogoče izogniti.