Szolgáltatóváltás a telephelyi VPN-címek újraszámozása nélkül
A route-olt telephelyi VPN megtartja a privát címeket, amikor a feltöltő kapcsolat változik, de a partner címe, az azonosság és a visszaút még munkát igényel. Itt a szétválasztás.
Egy fióktelep internetszolgáltatót vált, a fájlkiszolgáló pedig megtartja a címét. Ez az eredmény normális egy route-olt telephelyi VPN-ben, és meglepő annak, aki azt feltételezi, hogy az alagút végpontjának címe az alkalmazás címe. A kettő a tervezés különböző rétegeiben él, és csak az egyik mozdult el. Egyként kezelni őket az az út, amelyen a szolgáltatóváltás újraszámozási projektté válik.
Két címtábla, amely egymástól függetlenül mozog
A belső terv a privát címeket írja le, amelyeket az alkalmazások használnak: a fióktelep kiszolgálója a 10.55.8.20 címen, a központ előtagja, amely oda routol, és a visszaút. A külső terv azt írja le, hogyan érik el egymást az átjárók: partner-címek, figyelő portok és az interneten át vezető út.
A szolgáltatóváltás a külső tervet érinti. Önmagában nem követeli meg a belső terv megváltoztatását.
A két leltár szétválasztása a gyakorlati oka annak, hogy overlay-t futtassunk akkor is, amikor az alkalmazás már maga titkosítja a forgalmát. Az overlay stabil belső topológiát ad, amely túléli a külső változásokat. Az alkalmazás megtartja a címét, a tűzfal-szabályait és a DNS-rekordjait. Csak a szállítási bejegyzések változnak, és ez sokkal kisebb átvizsgálás.
A külső alagút hordozza a belső beszélgetést
Átjáró-átjáró alagútban a külső IP-fejléc címezi a két átjárót. A belső fejléc továbbra is az alkalmazás tényleges végpontjait nevezi meg. Az RFC 7296 átjáró-átjáró leírása ezt közönséges routingként kezeli, amely az alagút végpontjain keresztül juttatja el a forgalmat.
Ezért tarthatja meg a fióktelep kiszolgálója a 10.55.8.20 címet, miközben az átjáró nyilvános címe változik. A belső csomag egyáltalán nem tartalmazza a szolgáltató címét.
A szétválasztás tervezési tulajdonság, nem automatikus garancia. Ha a csere-feltöltő kapcsolat nem tudja felépíteni a támogatott alagutat, vagy a belső útvonalak nem települnek újra, az alkalmazás elveszíti az útvonalát, pedig a címe változatlan.
A szolgáltató áthelyezésének még mindig van ellenőrzőlistája
A külső ellenőrzőlistán öt tétel van: a partner címe vagy a karbantartott név, a figyelő és minden felsőbb szűrés, az útvonalon történő fordítás, a várt partnerazonosság és a másik átjáró engedélyezett beállításai. Mindegyik önállóan meghiúsulhat. Tartsunk külön helyreállítási útvonalat, miközben a felügyeletet hordozó kapcsolatot cseréljük. A távelérés elvágása egy feltöltő kapcsolat átállása közben olyan kiesés, amelyet magunk okoztunk.
Ezután ellenőrizzük a fióktelep előtagját, az útvonalat mindkét irányban, a védelmi házirendet és egy valódi alkalmazásfolyamot. A frissen hitelesített alagút nem javítja ki azt az útvonalat, amely a régi privát alhálózatra mutat.
A címütközés egy másik csatlakoztatott telephelytel külön tervezési probléma. A szolgáltatóváltás nem hozza létre, de a migráció általában az a pillanat, amikor felszínre kerül.
Ami nem éli túl: nyilvános forrás és munkamenetek
Egy stabil privát kiszolgálócím nem stabil nyilvános forrás. Ha a böngészés közvetlenül az új szolgáltatón keresztül lép ki, a webhelyek az új, szolgáltató felé néző címet látják.
Ennek a címnek a stabil tartása szándékos kimeneti tervezést igényel, saját rendelkezésre állással és házirenddel. Ez nem jár ingyen az alagúttal.
A létrehozott munkamenetek sem élik túl az útvonalváltást. Az alagút másodpercek alatt újra felépülhet, és mégis megszakíthatja a régi útvonalhoz rögzített hosszú életű kapcsolatokat. Az átállást olyan ablakra tervezzük, amelyben az újracsatlakozás elfogadható. Ne állítsuk, hogy a migráció láthatatlan lesz, hacsak a konkrét klienseket és azok időkorlátait nem tesztelték.
Négy ellenőrzéssel igazoljuk az áthelyezést
A változtatás után sorrendben négy dolgot ellenőrizzünk: az alagút a szándékolt partnerrel épült fel, létezik a belső útvonal a fióktelep előtagjához, a házirend engedélyezi az alkalmazásfolyamot, és az alkalmazás válaszol. Mindegyiknek saját parancsa van.
Linux-átjárón ez a három lefedi a lista közepét:
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/healthA szállítási címeket tartsuk az egyik leltárban, az alkalmazáscímeket a másikban. Csak azokat a bejegyzéseket frissítsük, amelyek valóban elmozdultak. A belső függőségek újraszámozása amiatt, hogy az alagút külső címe megváltozott, elkerülhető munka.