Zmena poskytovateľa bez prečíslovania adries site VPN

Pobočka mení poskytovateľa internetu a súborový server si ponecháva svoju adresu. Taký výsledok je pri routovanej site VPN normálny a prekvapivý pre každého, kto predpokladá, že adresa koncového bodu tunela je adresou aplikácie. Obe žijú v rôznych vrstvách návrhu a posunula sa len jedna z nich. Zaobchádzať s nimi ako s jedným je spôsob, akým sa migrácia poskytovateľa zmení na projekt prečíslovania.

Dva plány adries, ktoré sa pohybujú nezávisle

Vnútorný plán opisuje privátne adresy, ktoré aplikácie používajú: server pobočky na 10.55.8.20, prefix ústredia, ktorý k nemu smeruje, a spiatočnú trasu. Vonkajší plán opisuje, ako sa dve brány dostanú k sebe: adresy partnerov, porty na počúvanie a cesta cez internet.

Zmena poskytovateľa sa dotýka vonkajšieho plánu. Sama o sebe nevyžaduje zmenu vnútorného plánu.

Držať oba inventáre oddelene je praktický dôvod prevádzkovať prekryv, aj keď aplikácia už svoju premávku šifruje sama. Prekryv vám dáva stabilnú vnútornú topológiu, ktorá prežije vonkajšie zmeny. Aplikácia si ponechá svoju adresu, pravidlá firewallu aj záznamy DNS. Menia sa len transportné záznamy, a to je oveľa menšia revízia.

Vonkajší tunel nesie vnútorný rozhovor

V tuneli brána-brána adresuje vonkajšia IP hlavička obe brány. Vnútorná hlavička stále pomenúva skutočné koncové body aplikácie. Opis brána-brána v RFC 7296 to berie ako bežné smerovanie, ktoré doručuje premávku cez koncové body tunela.

Preto si server pobočky môže ponechať 10.55.8.20, kým sa verejná adresa brány mení. Vnútorný paket adresu poskytovateľa vôbec neobsahuje.

Oddelenie je vlastnosť návrhu, nie automatická záruka. Ak náhradný uplink nedokáže nadviazať podporovaný tunel alebo sa vnútorné trasy znova nenainštalujú, aplikácia stratí svoju cestu, aj keď sa jej adresa nezmenila.

Sťahovanie poskytovateľa má stále kontrolný zoznam

Vonkajší kontrolný zoznam má päť položiek: adresa partnera alebo udržiavané meno, počúvač a akékoľvek filtrovanie vyššie proti toku, preklad na ceste, očakávaná identita partnera a povolené nastavenia druhej brány. Každá môže zlyhať sama. Držte samostatnú cestu obnovy, kým meníte spoj, ktorý nesie správu. Prerušenie vzdialeného prístupu počas prechodu na nový uplink je výpadok, ktorý ste si spôsobili sami.

Potom skontrolujte prefix pobočky, trasu v oboch smeroch, ochrannú politiku a jeden skutočný tok aplikácie. Čerstvo autentizovaný tunel neopraví trasu, ktorá mieri do starej privátnej podsiete.

Prekryv adries s iným pripojeným areálom je samostatný plánovací problém. Zmena poskytovateľa ho nevytvára, ale migrácia je zvyčajne chvíľa, keď vyplave.

Čo neprežije: verejný zdroj a relácie

Stabilná privátna adresa servera nie je stabilný verejný zdroj. Ak prehliadanie vychádza priamo cez nového poskytovateľa, weby vidia novú adresu obrátenú k poskytovateľovi.

Udržať túto adresu stabilnú vyžaduje premyslený návrh výstupu s vlastnou dostupnosťou a politikou. Ten s tunelom zadarmo neprichádza.

Ani nadviazané relácie neprežijú zmenu cesty. Tunel sa môže obnoviť v priebehu sekúnd a napriek tomu prerušiť dlhé spojenia pripnuté k starej ceste. Naplánujte prechod na okno, v ktorom sú opätovné pripojenia prijateľné. Netvrďte, že migrácia bude neviditeľná, kým nie sú otestovaní konkrétni klienti a ich časové limity.

Overte sťahovanie štyrmi kontrolami

Po zmene overte štyri veci v poradí: tunel je nadviazaný so zamýšľaným partnerom, vnútorná trasa k prefixu pobočky existuje, politika povoľuje tok aplikácie a aplikácia odpovedá. Každá má svoj príkaz.

Na bráne s Linuxom tieto tri pokrývajú stred tohto zoznamu:

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

Držte transportné adresy v jednom inventári a adresy aplikácií v druhom. Aktualizujte len záznamy, ktoré sa skutočne posunuli. Prečíslovanie vnútorných závislostí pre zmenu vonkajšej adresy tunela je práca, ktorej sa dá vyhnúť.