Skift udbyder uden at omnummerere site-VPN-adresser
Et rutet site-VPN beholder private adresser, når uplinket skifter, men peer-adresse, identitet og returvej kræver stadig arbejde. Her er opdelingen.
En filial skifter internetudbyder, og fileserveren beholder sin adresse. Det resultat er normalt i et rutet site-VPN og overraskende for enhver, der antager, at tunnelens endepunktsadresse er applikationens adresse. De to lever i forskellige lag af designet, og kun den ene flyttede sig. At behandle dem som én er måden, hvorpå en udbyderflytning bliver til et omnummereringsprojekt.
To adresseplaner, der flytter sig uafhængigt
Den indre plan beskriver de private adresser, applikationerne bruger: filialserveren på 10.55.8.20, hovedkontorets præfiks, der ruter dertil, og returruten. Den ydre plan beskriver, hvordan to gateways når hinanden: peer-adresser, lytteporte og vejen over internettet.
Et udbyderskift rører den ydre plan. Det kræver ikke i sig selv, at den indre plan ændres.
At holde de to fortegnelser adskilt er den praktiske grund til at køre et overlay, selv når applikationen allerede krypterer sin egen trafik. Overlayet giver dig en stabil indre topologi, der overlever ydre uro. Applikationen beholder sin adresse, sine firewallregler og sine DNS-poster. Kun transportposterne ændres, og det er en meget mindre gennemgang.
Den ydre tunnel bærer den indre samtale
I en gateway-til-gateway-tunnel adresserer det ydre IP-hovede de to gateways. Det indre hovede navngiver stadig applikationens faktiske endepunkter. Beskrivelsen af gateway-til-gateway i RFC 7296 behandler dette som almindelig routing, der leverer trafik gennem tunnelens endepunkter.
Derfor kan filialserveren beholde 10.55.8.20, mens gatewayens offentlige adresse ændres. Den indre pakke indeholder slet ikke udbyderens adresse.
Adskillelsen er en designegenskab, ikke en automatisk garanti. Hvis det nye uplink ikke kan etablere den understøttede tunnel, eller de indre ruter ikke geninstalleres, mister applikationen sin vej, selv om dens adresse er uændret.
Udbyderflytningen har stadig en tjekliste
Den ydre tjekliste har fem punkter: peer-adressen eller det vedligeholdte navn, lytteren og eventuel filtrering længere oppe, oversættelse på vejen, den forventede peer-identitet og den anden gateways tilladte indstillinger. Hver af dem kan fejle alene. Hold en separat gendannelsesvej, mens du skifter det link, der bærer administrationen. At afskære fjernadgang under en uplink-overgang er et nedbrud, du selv har forårsaget.
Derefter kontrolleres filialpræfikset, ruten i begge retninger, beskyttelsespolitikken og et rigtigt applikationsflow. En netop godkendt tunnel retter ikke en rute, der peger på det gamle private subnet.
Adresseoverlap med et andet tilsluttet site er et separat planlægningsproblem. Udbyderflytningen skaber det ikke, men en migrering er normalt, når det dukker op.
Hvad der ikke overlever: offentlig kilde og sessioner
En stabil privat serveradresse er ikke en stabil offentlig kilde. Hvis browsing går direkte ud gennem den nye udbyder, ser websteder den nye udbyder-vendte adresse.
At holde den adresse stabil kræver et bevidst egress-design med sin egen tilgængelighed og politik. Det kommer ikke gratis med tunnelen.
Etablerede sessioner overlever heller ikke et vejskift. Tunnelen kan genoprettes inden for sekunder og alligevel bryde langvarige forbindelser, der er fastgjort til den gamle vej. Planlæg overgangen til et vindue, hvor genopkoblinger er acceptable. Påstå ikke, at en migrering bliver usynlig, medmindre de konkrete klienter og deres timeouts er testet.
Verificér flytningen med fire kontroller
Efter ændringen skal du kontrollere fire ting i rækkefølge: tunnelen er etableret med den tilsigtede peer, den indre rute til filialpræfikset findes, politikken tillader applikationsflowet, og applikationen svarer. Hver har sin egen kommando.
På en Linux-gateway dækker disse tre midten af den liste:
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
Hold transportadresser i én fortegnelse og applikationsadresser i en anden. Opdater kun de poster, der faktisk flyttede sig. At omnummerere interne afhængigheder, fordi tunnelens ydre adresse er ændret, er undgåeligt arbejde.