Promijenite ISP bez prenumerisanja adresa VPN-a na lokaciji

Ogranak mijenja internet provajdera, a datotečni server zadržava svoju adresu. Takav ishod je normalan kod rutiranog VPN-a lokacije i iznenađenje za svakoga ko pretpostavi da je adresa krajnje točke tunela adresa aplikacije. Njih dvoje žive u različitim slojevima dizajna, a pomjerio se samo jedan. Tretirati ih kao jedno jeste način na koji migracija provajdera postaje projekt prenumerisanja.

Dva plana adresa koji se kreću nezavisno

Unutrašnji plan opisuje privatne adrese koje aplikacije koriste: server ogranka na 10.55.8.20, prefiks sjedišta koji rutira prema njemu i povratnu rutu. Vanjski plan opisuje kako dva gatewaya dolaze jedan do drugog: adrese partnera, portove za slušanje i put kroz internet.

Promjena provajdera dotiče vanjski plan. Ona sama po sebi ne zahtijeva promjenu unutrašnjeg plana.

Držati dva inventara odvojeno praktičan je razlog za pokretanje overlaya čak i kada aplikacija već šifrira vlastiti promet. Overlay vam daje stabilnu unutrašnju topologiju koja preživljava vanjske promjene. Aplikacija zadržava svoju adresu, pravila firewall-a i DNS zapise. Mijenjaju se samo transportni unosi, a to je mnogo manji pregled.

Vanjski tunel nosi unutrašnji razgovor

U tunelu od gatewaya do gatewaya vanjsko IP zaglavlje adresira dva gatewaya. Unutrašnje zaglavlje i dalje imenuje stvarne krajnje točke aplikacije. Opis gateway-prema-gatewayu u RFC 7296 tretira to kao obično rutiranje koje dostavlja promet kroz krajnje točke tunela.

Zato server ogranka može zadržati 10.55.8.20 dok se javna adresa gatewaya mijenja. Unutrašnji paket uopće ne sadrži adresu provajdera.

Razdvajanje je osobina dizajna, a ne automatska garancija. Ako zamjenska veza ne može uspostaviti podržani tunel ili se unutrašnje rute ne instaliraju ponovo, aplikacija gubi svoju putanju iako joj adresa nije promijenjena.

Preseljenje provajdera i dalje ima kontrolnu listu

Vanjski kontrolni spisak ima pet stavki: adresa partnera ili održavano ime, slušalac i bilo koje filtriranje uzvodno, prevođenje na putu, očekivani identitet partnera i dozvoljene postavke drugog gatewaya. Svaka može pasti sama za sebe. Držite odvojenu putanju oporavka dok mijenjate vezu koja nosi administraciju. Prekid udaljenog pristupa tijekom prelaska na novu vezu je ispad koji ste sami prouzročili.

Nakon toga provjerite prefiks ogranka, rutu u oba smjera, zaštitnu politiku i jedan stvarni tok aplikacije. Svježe autentificiran tunel ne ispravlja rutu koja pokazuje na staru privatnu podmrežu.

Preklapanje adresa s drugom povezanom lokacijom odvojen je planski problem. Promjena provajdera ga ne stvara, ali migracija je obično trenutak kada se pojavi.

Šta ne preživljava: javni izvor i sesije

Stabilna privatna adresa servera nije stabilan javni izvor. Ako pregledanje izlazi izravno kroz novog provajdera, web-stranice vide novu adresu okrenutu provajderu.

Zadržati tu adresu stabilnom traži promišljen dizajn izlaza s vlastitom dostupnošću i politikom. On ne dolazi besplatno uz tunel.

Uspostavljene sesije također ne preživljavaju promjenu putanje. Tunel se može ponovo uspostaviti u sekundama i ipak prekinuti dugotrajne veze vezane za staru putanju. Planirajte prelazak za prozor u kojem su ponovna povezivanja prihvatljiva. Ne tvrdite da će migracija biti nevidljiva osim ako konkretni klijenti i njihovi timeouti nisu testirani.

Provjerite preseljenje s četiri provjere

Nakon promjene provjerite četiri stvari po redu: tunel je uspostavljen s predviđenim partnerom, unutrašnja ruta do prefiksa ogranka postoji, politika dopušta tok aplikacije i aplikacija odgovara. Svaka ima svoju naredbu.

Na Linux gatewayu ove tri pokrivaju sredinu tog spiska:

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žite transportne adrese u jednom inventaru, a adrese aplikacija u drugom. Ažurirajte samo unose koji su se stvarno pomjerili. Prenumerisanje unutrašnjih zavisnosti zato što se vanjska adresa tunela promijenila je posao koji se može izbjeći.