Van provider wisselen zonder de site-VPN-adressen te hernummeren

Een filiaal wisselt van internetprovider en de fileserver houdt zijn adres. Dat resultaat is normaal in een gerouteerde site-VPN en verrassend voor wie aanneemt dat het eindpuntadres van de tunnel het adres van de applicatie is. De twee leven in verschillende lagen van het ontwerp, en slechts één verschoof. Ze als één behandelen is hoe een providerwissel een hernummeringsproject wordt.

Twee adresplannen die onafhankelijk bewegen

Het binnenplan beschrijft de privéadressen die applicaties gebruiken: de filiaalserver op 10.55.8.20, het prefix van het hoofdkantoor dat daarheen routeert, en de terugroute. Het buitenplan beschrijft hoe twee gateways elkaar bereiken: peeradressen, luisterpoorten en de weg over het internet.

Een providerwissel raakt het buitenplan. Die vraagt op zichzelf niet dat het binnenplan verandert.

De twee inventarissen gescheiden houden is de praktische reden om een overlay te draaien, ook wanneer de applicatie haar eigen verkeer al versleutelt. De overlay geeft een stabiele binnen-topologie die bestand is tegen veranderingen buiten. De applicatie houdt haar adres, haar firewallregels en haar DNS-records. Alleen de transportregels veranderen, en dat is een veel kleinere beoordeling.

De buitenste tunnel draagt het binnenste gesprek

In een gateway-naar-gateway-tunnel adresseert de buitenste IP-header de twee gateways. De binnenste header noemt nog steeds de werkelijke eindpunten van de applicatie. De gateway-naar-gateway-beschrijving in RFC 7296 behandelt dit als gewone routering die verkeer via de tunnel-eindpunten aflevert.

Daarom kan de filiaalserver 10.55.8.20 houden terwijl het openbare adres van de gateway verandert. Het binnenste pakket bevat het adres van de provider helemaal niet.

De scheiding is een ontwerpeigenschap, geen automatische garantie. Als de vervangende uplink de ondersteunde tunnel niet kan opzetten, of de binnenste routes niet opnieuw worden geïnstalleerd, verliest de applicatie haar pad ook al is haar adres onveranderd.

De providerwissel heeft nog steeds een checklist

De buitenste checklist heeft vijf punten: het peeradres of de onderhouden naam, de luisteraar en eventuele filtering verderop, de vertaling op het pad, de verwachte peer-identiteit en de toegestane instellingen van de andere gateway. Elk kan op zichzelf falen. Houd een apart herstelpad aan terwijl u de link wijzigt die het beheer draagt. Externe toegang afsnijden tijdens een uplink-overgang is een storing die u zelf veroorzaakt.

Controleer daarna het filiaalprefix, de route in beide richtingen, het beschermingsbeleid en één echte applicatiestroom. Een vers geauthenticeerde tunnel repareert geen route die naar het oude privé-subnet wijst.

Adresoverlap met een andere aangesloten locatie is een apart planningsprobleem. De providerwissel maakt het niet, maar een migratie is meestal het moment waarop het opduikt.

Wat niet overleeft: openbare bron en sessies

Een stabiel privé-serveradres is geen stabiele openbare bron. Als browsen rechtstreeks via de nieuwe provider naar buiten gaat, zien websites het nieuwe, naar de provider gerichte adres.

Dat adres stabiel houden vraagt een bewust egress-ontwerp met eigen beschikbaarheid en beleid. Het komt niet gratis met de tunnel.

Bestaande sessies overleven een padwijziging ook niet. De tunnel kan binnen seconden opnieuw worden opgezet en toch langdurige verbindingen breken die aan het oude pad vastzitten. Plan de overgang voor een venster waarin herverbindingen acceptabel zijn. Beweer niet dat een migratie onzichtbaar zal zijn tenzij de specifieke clients en hun time-outs zijn getest.

Verifieer de wissel met vier controles

Controleer na de wijziging vier dingen op volgorde: de tunnel is opgezet met de bedoelde peer, de binnenste route naar het filiaalprefix bestaat, het beleid staat de applicatiestroom toe en de applicatie antwoordt. Elk heeft zijn eigen commando.

Op een Linux-gateway dekken deze drie het midden van die lijst:

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

Houd transportadressen in één inventaris en applicatieadressen in een andere. Werk alleen de regels bij die echt zijn verschoven. Interne afhankelijkheden hernummeren omdat het buitenadres van de tunnel is veranderd, is te vermijden werk.