En filial byter internetleverantör och filservern behåller sin adress. Det resultatet är normalt i ett routat site-VPN och överraskande för den som antar att tunnelns ändpunktsadress är applikationens adress. De två lever i olika lager av designen, och bara en flyttade sig. Att behandla dem som en är hur en leverantörsflytt blir ett omnumreringsprojekt.

Två adressplaner som rör sig oberoende

Den inre planen beskriver de privata adresser applikationerna använder: filialservern på 10.55.8.20, huvudkontorets prefix som routar dit och returvägen. Den yttre planen beskriver hur två gateways når varandra: peer-adresser, lyssnarportar och vägen över internet.

Ett leverantörsbyte berör den yttre planen. Det kräver inte i sig att den inre planen ändras.

Att hålla de två inventarierna åtskilda är det praktiska skälet att köra ett overlay även när applikationen redan krypterar sin egen trafik. Overlayet ger en stabil inre topologi som överlever yttre förändringar. Applikationen behåller sin adress, sina brandväggsregler och sina DNS-poster. Bara transportposterna ändras, och det är en mycket mindre granskning.

Den yttre tunneln bär det inre samtalet

I en gateway-till-gateway-tunnel adresserar det yttre IP-huvudet de två gatewayerna. Det inre huvudet namnger fortfarande applikationens faktiska ändpunkter. Beskrivningen av gateway-till-gateway i RFC 7296 behandlar detta som vanlig routing som levererar trafik via tunnelns ändpunkter.

Därför kan filialservern behålla 10.55.8.20 medan gatewayens offentliga adress ändras. Det inre paketet innehåller inte alls leverantörens adress.

Uppdelningen är en designegenskap, inte en automatisk garanti. Om den nya upplänken inte kan upprätta den stödda tunneln, eller de inre rutterna inte installeras om, förlorar applikationen sin väg trots att adressen är oförändrad.

Leverantörsflytten har fortfarande en checklista

Den yttre checklistan har fem punkter: peer-adressen eller det underhållna namnet, lyssnaren och eventuell filtrering längre upp, översättningen på vägen, den förväntade peer-identiteten och den andra gatewayens tillåtna inställningar. Var och en kan fallera själv. Håll en separat återställningsväg medan du byter länken som bär administrationen. Att kapa fjärråtkomst under en upplänksväxling är ett avbrott du själv orsakat.

Kontrollera sedan filialprefixet, rutten i båda riktningarna, skyddspolicyn och ett verkligt applikationsflöde. En nyautentiserad tunnel lagar inte en rutt som pekar mot det gamla privata subnätet.

Adressöverlapp med en annan ansluten plats är ett separat planeringsproblem. Leverantörsbytet skapar det inte, men en migrering är oftast då det dyker upp.

Det som inte överlever: offentlig källa och sessioner

En stabil privat serveradress är inte en stabil offentlig källa. Om surfandet går ut direkt via den nya leverantören ser webbplatserna den nya leverantörsvända adressen.

Att hålla den adressen stabil kräver en medveten egress-design med egen tillgänglighet och policy. Det kommer inte gratis med tunneln.

Etablerade sessioner överlever inte heller ett vägbyte. Tunneln kan återupprättas inom sekunder och ändå bryta långlivade anslutningar som är fästa vid den gamla vägen. Planera växlingen till ett fönster där återanslutningar är acceptabla. Påstå inte att en migrering blir osynlig om inte de specifika klienterna och deras tidsgränser testats.

Verifiera flytten med fyra kontroller

Efter ändringen, verifiera fyra saker i ordning: tunneln är upprättad med den avsedda peeren, den inre rutten till filialprefixet finns, policyn tillåter applikationsflödet och applikationen svarar. Var och en har sitt eget kommando.

På en Linux-gateway täcker dessa tre mitten av listan:

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

Håll transportadresser i ett inventarium och applikationsadresser i ett annat. Uppdatera bara de poster som faktiskt flyttade sig. Att numrera om interna beroenden för att tunnelns yttre adress ändrats är onödigt arbete.

Relaterade artiklar