Změna poskytovatele bez přečíslování adres site VPN

Pobočka mění poskytovatele internetu a souborový server si ponechává svou adresu. Takový výsledek je u routované site VPN normální a překvapivý pro každého, kdo předpokládá, že adresa koncového bodu tunelu je adresou aplikace. Obě žijí v různých vrstvách návrhu a posunula se jen jedna z nich. Zacházet s nimi jako s jedním je způsob, jak se migrace poskytovatele změní v projekt přečíslování.

Dva plány adres, které se pohybují nezávisle

Vnitřní plán popisuje privátní adresy, které aplikace používají: server pobočky na 10.55.8.20, prefix ústředí, který k němu směruje, a zpáteční trasu. Vnější plán popisuje, jak se dvě brány dostanou k sobě: adresy protějšků, porty pro naslouchání a cestu přes internet.

Změna poskytovatele se dotýká vnějšího plánu. Sama o sobě nevyžaduje změnu vnitřního plánu.

Držet oba inventáře oddělené je praktický důvod, proč provozovat překryvnou síť, i když aplikace už svůj provoz šifruje sama. Překryvná síť vám dává stabilní vnitřní topologii, která přežije vnější změny. Aplikace si ponechá svou adresu, pravidla firewallu i záznamy DNS. Mění se jen transportní záznamy, a to je mnohem menší revize.

Vnější tunel nese vnitřní rozhovor

V tunelu brána-brána adresuje vnější IP hlavička obě brány. Vnitřní hlavička stále pojmenovává skutečné koncové body aplikace. Popis brána-brána v RFC 7296 to bere jako běžné směrování, které doručuje provoz přes koncové body tunelu.

Proto si server pobočky může ponechat 10.55.8.20, zatímco se veřejná adresa brány mění. Vnitřní paket adresu poskytovatele vůbec neobsahuje.

Oddělení je vlastnost návrhu, ne automatická záruka. Pokud náhradní uplink nedokáže navázat podporovaný tunel nebo se vnitřní trasy znovu nenainstalují, aplikace ztratí svou cestu, i když se její adresa nezměnila.

Stěhování poskytovatele má pořád kontrolní seznam

Vnější kontrolní seznam má pět položek: adresa protějšku nebo udržované jméno, naslouchač a případné filtrování výš proti toku, překlad na cestě, očekávaná identita protějšku a povolená nastavení druhé brány. Každá může selhat sama. Držte samostatnou cestu pro obnovu, dokud měníte spoj, který nese správu. Přerušení vzdáleného přístupu během přechodu na nový uplink je výpadek, který jste si způsobili sami.

Poté zkontrolujte prefix pobočky, trasu v obou směrech, ochrannou politiku a jeden skutečný tok aplikace. Čerstvě autentizovaný tunel neopraví trasu, která míří do staré privátní podsítě.

Překryv adres s jiným připojeným areálem je samostatný plánovací problém. Změna poskytovatele ho nevytváří, ale migrace je obvykle chvíle, kdy vyplave.

Co nepřežije: veřejný zdroj a relace

Stabilní privátní adresa serveru není stabilní veřejný zdroj. Pokud prohlížení vychází přímo přes nového poskytovatele, weby vidí novou adresu obrácenou k poskytovateli.

Udržet tuto adresu stabilní vyžaduje promyšlený návrh výstupu s vlastní dostupností a politikou. Ten s tunelem zdarma nepřichází.

Navázané relace také nepřežijí změnu cesty. Tunel se může obnovit během sekund a přesto přerušit dlouhé spoje připnuté ke staré cestě. Naplánujte přechod na okno, kdy jsou opětovná připojení přijatelná. Netvrďte, že migrace bude neviditelná, dokud nejsou otestováni konkrétní klienti a jejich časové limity.

Ověřte stěhování čtyřmi kontrolami

Po změně ověřte čtyři věci v pořadí: tunel je navázán se zamýšleným protějškem, vnitřní trasa k prefixu pobočky existuje, politika povoluje tok aplikace a aplikace odpovídá. Každá má svůj příkaz.

Na bráně s Linuxem tyto tři pokrývají střed toho seznamu:

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áři a adresy aplikací v druhém. Aktualizujte jen záznamy, které se skutečně posunuly. Přečíslování vnitřních závislostí kvůli změně vnější adresy tunelu je práce, které se lze vyhnout.