Var din hanterade VPN:s internetutgång faktiskt går ut

Du kan inte säga vem som filtrerar ett kontors offentliga trafik förrän förslaget visar var den trafiken lämnar leverantörens nät. Internettillgång som ingår i ett hanterat VPN är en andra tjänst, som går på en väg med egna gateways, egen adressöversättning och egen eskaleringskö. De flesta avtal beskriver den privata sidan i detalj och lämnar den offentliga sidan åt en enda mening. Kontrollerna nedan gör den meningen till ett diagram som du kan försvara.

Följ en offentlig destination per plats

Välj en värd i en filial och följ en offentlig destination, och notera den sista adressen som tillhör leverantören och den första som tillhör internet. Hoppet mellan de två adresserna är utgången, och det ligger ofta långt från platsen som skickade paketet. Markera enheten som utför övergången, eftersom just den enheten har filtret som avgör vad som går ut. Upprepa spårningen från en andra plats och jämför utgångsadresserna, eftersom två filialer som ser likadana ut på fakturan kan gå ut genom olika gateways i olika städer.

Notera också källadressen som destinationen faktiskt ser, eftersom översättningen kan ske på ett hopp som du aldrig ritade. Skriv de observerade svaren bredvid de ritade, och gapet mellan dem är där den första incidenten kommer att komma ifrån. En ingenjör hos leverantören som inte kan ange utgångsadressen för en given plats har redan sagt något användbart om designen.

Tre utgångsupplägg och vad var och en koncentrerar

En central utgång som du själv driver drar den offentliga trafiken till en egen gateway, vilket ger dig filtreringspolicyn och loggarna men koncentrerar belastningen från alla platser på en enda förbindelse. En leverantörsdriven utgång flyttar policy och loggar över avtalsgränsen, vilket förenklar driften och tar bort din synlighet i samma rörelse. En utgång på varje plats håller den offentliga trafiken lokal och mångdubblar antalet policyytor som måste förbli identiska.

Fråga vilken av de tre leverantören faktiskt erbjuder innan du behandlar listan som en meny, och fråga om en plats kan flytta mellan dem utan en ny förbindelse. Svaret om migrering skiljer det avtalsmässiga från det enbart tekniska. Notera också vem som äger källöversättningen, eftersom det avgör vad en partner måste lägga till i tillåtelselistan. Delade gateways innebär också delad kapacitet och ibland delat rykte, vilket ändrar hur partner behandlar dina adresser. Kapaciteten förtjänar också en egen fråga, eftersom en delad gateway betjänar andra kunder i samma stund.

Filtrering, översättning och kryptering har separata ägare

En väg etablerar nåbarhet och säger ingenting om inspektion, så behandla de två som olika frågor med olika ägare. För varje annonserad standardväg, namnge enheten som filtrerar, enheten som autentiserar, enheten som översätter och enheten som inspekterar, och namnge sedan vem som administrerar var och en. Leverantörens vägseparation säger inte var krypteringen slutar, och en privat tjänst kan avsluta sin tunnel vid en gräns medan den offentliga utgången slutar vid en annan. Fråga om översättningen sker vid leverantörens kant, vid en delad gateway eller vid din egen utgång, och om det finns sessionsloggar och hur länge de sparas. Räkna ägarna i svaren, eftersom ett avtal som namnger en part för fyra uppgifter vanligtvis lämnar tre av dem odokumenterade.

En bred standardväg importerad till den privata routingkontexten förtjänar samma granskning, eftersom en import är en medveten överenskommelse och inte en oskyldig bekvämlighet. Avsnitt 11 i RFC 4364 går igenom flera upplägg för internettillgång för BGP/MPLS-VPN:er och behandlar vägutbyte mellan VPN-kontexten och leverantörens standardvidarebefordringskontext som just den sortens överenskommelse. Fråga vad som hindrar offentlig trafik från att av misstag ta en privat väg, och få svaret bredvid vägpolicyn i stället för i en bild.

Två felfall att komma överens om före signering

Skriv två tester i avtalet: att förlora internetutgången och att förlora en privat anslutning. För var och en, lista de interna resurserna, de lokala internettjänsterna och de administrationsvägar som måste fortsätta fungera. Lista sedan reservvägen som måste förbli blockerad, eftersom en väg runt de centrala kontrollerna är värre än ett rent avbrott. Ge båda testerna till leverantören och begär deras förväntade resultat skriftligt, inklusive detektering och avisering.

Kör samma tester från en pilotplats och jämför dem med det skriftliga svaret. Där de två inte stämmer beskriver avtalet ett annat nät än det du köpte. Två kommandon täcker de vanliga fallen: det ena visar vägen som en offentlig destination tar, det andra adressen den ser.

traceroute -n 203.0.113.10
curl -s https://example.net/ip

Knyt tillgänglighetsåtagandena till segmentet du mätte, inte till tjänstens namn. En lokal förbindelse, en leverantörsstomme och en delad gateway bär separata åtaganden och separata eskalereringsteam. Bokstäverna L2VPN, L3VPN och MPLS beskriver en vidarebefordringsmekanism, inte en garanti från ände till ände.

Bevis slår adjektiven i förslaget

Ord som redundant, säker och motståndskraftig beskriver en avsikt och inte en design. Begär i stället enhetslistan, utgångsplatserna, översättningsschemat och aviseringsvägen. En leverantör som kan ta fram de fyra sakerna har en design; en som inte kan har en bild. Håll svaren i tjänstedokumentationen i stället för i en e-posttråd, och gå igenom dem vid varje avtalsändring.

Utgångsuppläggen förskjuts tyst när leverantörer konsoliderar gateways, så ett diagram från för tre år sedan är en belastning. När en partner rapporterar en okänd källadress bör du inom några minuter kunna säga om den kom från din design eller från en ändring som ingen annonserade. Just den förmågan, och inte adjektiven, överlever det första avbrottet.