MPLS VPN eller IPsec-overlegg: tre kontrakter som må avklares
En leverandør-VPN videresender pakker og skiller rutingen. Kryptering er en tredje kontrakt som ingen kjøper ved et uhell, så gi hvert løfte en eier.
Tre løfter ligger i ett enkelt WAN-tilbud, og å kjøpe det ene kjøper ikke de andre. Noen videresender pakkene dine, noen holder rutingen din atskilt fra enhver annen kunde, og noen avgjør om nyttelasten er lesbar underveis. De løftene kan tilhøre forskjellige parter og likevel beskrive ett brukbart design. Å skille dem er beslutningen; å velge et teknologinavn er det ikke.
Tre løfter i ett enkelt WAN-tilbud
Det første løftet er transport: hvilke lokasjoner som kobles sammen, over hvilke aksesskretser, og hvem som videresender pakker mellom dem. Det andre er ruting: hvilke prefikser som kan nå hverandre, hvem som godkjenner en endring, og hvordan trafikken din holdes atskilt fra en annen leietaker. Det tredje er beskyttelse: hva som krypteres, mellom hvilke endepunkter, og hvem som har nøklene. Be om hvert av dem skriftlig, fordi hvert svar bor i et forskjellig dokument.
Et leverandørtilbud har en tendens til å prise det første, forutsette det andre og overlate det tredje til deg. Det er ikke uærlighet; de tre selges av forskjellige team. Det blir et problem når en designgjennomgang oppdager at sikkerhetsteamet forutsatte kryptering, og nettverksteamet forutsatte at operatøren håndterte det. Å dele setningen i tre koster en time og forhindrer det møtet.
En etikett beskriver videresending, ikke tjenesten ved overleveringspunktet
Multiprotokoll-etikettbytting forteller hvordan en pakke reiser inne i et leverandørnett. Det sier ikke hva kunden kobler til, eller hva kunden utveksler med leverandørens kant. En leverandør kan bygge en rutet IP VPN på MPLS, eller en lag 2-tjeneste med en helt annen tilkoblingsmodell, og begge kan nå deg som en «MPLS-tilkobling».
Terminologien for leverandørleverte VPN-er fra IETF definerer ordforrådet for nettopp dette: kundekanten, leverandørkanten og tjenestemodellene bygget mellom dem. Bruk den når et tilbud tåkelegger lagene, og spør hva overleveringen fysisk er.
En rutet tjeneste gir deg et rutingforhold til leverandørens kant, så å legge til et prefiks blir en endringsanmodning i to organisasjoner. En lag 2-overlevering bærer din egen ruting og flytter den driftsmessige byrden til din side. Ingen av dem er bedre i abstrakt forstand; svaret følger av hvor ofte topologien din endrer seg og hvem du vil skal svare klokken tre om morgenen.
Kryptering er et løfte du ikke kan delegere ved et uhell
Privat transport gjør ikke en nyttelast uleselig. Leverandøratskillelse holder leietakere atskilt driftsmessig; det er ikke en uttalelse om hvem som kan inspisere byte på veien. Hvis kravet er at operatøren ikke kan lese trafikken, trenger det kravet en mekanisme du kontrollerer, og IPsec er den vanlige.
IPsec går over privat transport like lett som over internettilgang, så «MPLS eller IPsec» er et falskt valg når du trenger administrert rekkevidde og din egen tillitsgrense samtidig. Bestem hvor tunnelen ender, fordi en tunnel som ender på en ruter, etterlater segmentet bak den ruteren i klartekst. Bestem deretter hvem som administrerer hver peer, siden en nøkkel som en tredjepart har, ikke er en grense du eier.
Gi hvert løfte et navn og en målbar grense
Skriv én linje per løfte med en eier og en grense som kan måles. Tilgjengeligheten til en aksesskrets tilhører leverandøren, backbone-forsinkelsen tilhører leverandøren, og tunnelens levetid tilhører den som driver endepunktene. Et enkelt ende-til-ende-tall som ingen måler, er et tall ingen skylder deg.
En tjenestenivåavtale kommer fra kontrakten og dens omfang, ikke fra bokstavene i et teknologinavn. IPsec krever ikke best-effort internett-transport, og MPLS bærer ikke i seg selv en forsinkelsesgaranti; begge avhenger av underlaget og endepunktene du velger.
Test veien du tegnet, inkludert feilen
En privat transport med et romslig grensesnitt kan fortsatt feile når et overlegg legger til headere, og symptomet er en sesjon som etableres og deretter stopper på store svar. Test den brukbare størrelsen i stedet for å resonnere om den, og skriv ned den største pakken som passerer ende-til-ende. Gjør det før du krangler om båndbredde, fordi en vei som dropper store pakker ser ut som et applikasjonsproblem. Tallet hører hjemme i designdokumentet ved siden av MTU-en til hver aksesskrets.
ping -M do -s 1400 -c 3 <vpn-gateway>
traceroute -n <vpn-gateway>
Kommandoene kommer fra en Linux-vert på ett sted; andre plattformer skriver den samme testen annerledes. Hvis et sted trenger en mindre verdi, er det en designbegrensning som skal noteres, ikke en feil som skal rapporteres. Den samme disiplinen gjelder for gjennomstrømning, fordi kryptering koster prosessering, og endepunktet blir en del av kapasitetsberegningen.
Tegn to diagrammer før du signerer: den normale veien med hver eier merket, og feilveien med de samme merkene. Det andre avslører design som ser overflødige ut på papiret og avhenger av én enhet i praksis. Når et avbrudd kommer, er det den tegningen som gjør en forvirrende morgen til en kort triage.