Hvor internett-utgangen til den administrerte VPN-en din faktisk går ut

Du kan ikke si hvem som filtrerer den offentlige trafikken til en filial før tilbudet viser hvor den trafikken forlater nettverket til leverandøren. Internettilgang som er buntet inn i en administrert VPN, er en andre tjeneste, som går på en rute med egne gatewayer, egen adresseoversettelse og egen eskaleringskø. De fleste kontrakter beskriver den private siden i detalj og overlater den offentlige siden til én setning. Kontrollene nedenfor gjør den setningen om til et diagram du kan forsvare.

Følg én offentlig destinasjon per sted

Velg en vert i en filial og følg én offentlig destinasjon, og noter den siste adressen som tilhører leverandøren og den første som tilhører internettet. Hoppet mellom de to adressene er utgangen, og det ligger ofte langt fra stedet som sendte pakken. Merk enheten som utfører overgangen, fordi nettopp den enheten har filteret som avgjør hva som går ut. Gjenta sporingen fra et annet sted og sammenlign utgangsadressene, fordi to filialer som ser like ut på fakturaen, kan gå ut gjennom forskjellige gatewayer i forskjellige byer.

Noter også kildeadressen som destinasjonen faktisk ser, fordi oversettelsen kan skje på et hopp du aldri tegnet. Skriv de observerte svarene ved siden av de tegnede, og gapet mellom dem er der den første hendelsen vil komme fra. En ingeniør hos leverandøren som ikke kan oppgi utgangsadressen for et gitt sted, har allerede fortalt deg noe nyttig om designet.

Tre utgangsarrangementer og hva hvert av dem konsentrerer

En sentral utgang som du driver selv, trekker den offentlige trafikken til en gateway du eier, noe som gir deg filtreringspolicyen og loggene, men konsentrerer belastningen fra alle steder på én linje. En leverandørdrevet utgang flytter policy og logger over kontraktgrensen, noe som forenkler driften og fjerner synligheten din i samme bevegelse. En utgang på hvert sted holder den offentlige trafikken lokal og mangedobler antallet policyflater som må forbli identiske.

Spør hvilken av de tre leverandøren faktisk tilbyr, før du behandler listen som en meny, og spør om et sted kan flytte mellom dem uten en ny linje. Svaret om migrering skiller det kontraktsmessige fra det rent tekniske. Noter også hvem som eier kildeoversettelsen, fordi det avgjør hva en partner må sette på tillatelseslisten. Delte gatewayer betyr også delt kapasitet og av og til delt omdømme, noe som endrer hvordan partnere behandler adressene dine. Kapasitet fortjener også sitt eget spørsmål, fordi en delt gateway betjener andre kunder i samme øyeblikk.

Filtrering, oversettelse og kryptering har hver sine eiere

En rute etablerer nåbarhet og sier ingenting om inspeksjon, så behandle de to som forskjellige spørsmål med forskjellige eiere. For hver annonserte standardrute, navngi enheten som filtrerer, enheten som autentiserer, enheten som oversetter og enheten som inspiserer, og navngi deretter hvem som administrerer hver av dem. Leverandørens ruteseparering sier ikke hvor krypteringen slutter, og en privat tjeneste kan avslutte tunnelen sin ved én grense mens den offentlige utgangen slutter ved en annen. Spør om oversettelsen skjer ved leverandørens kant, ved en delt gateway eller ved din egen utgang, og om det finnes sesjonslogger og hvor lenge de lagres. Tell eierne i svarene, fordi en kontrakt som navngir én part for fire oppgaver, vanligvis lar tre av dem stå udokumentert.

En bred standardrute importert til den private rutekonteksten fortjener samme gransking, fordi en import er en bevisst avtale og ikke en uskyldig bekvemmelighet. Seksjon 11 i RFC 4364 går gjennom flere internettilgangsarrangementer for BGP/MPLS-VPN-er og behandler ruteutveksling mellom VPN-konteksten og leverandørens standard videresendingskontekst som nettopp den typen avtale. Spør hva som hindrer offentlig trafikk i å ta en privat rute ved et uhell, og få svaret ved siden av rutepolicyen i stedet for i en presentasjon.

To feiltilfeller som må avtales før signering

Skriv to tester inn i kontrakten: miste internettutgangen og miste én privat tilkobling. For hver av dem, list opp de interne ressursene, de lokale internettjenestene og administrasjonsveiene som må fortsette å virke. List deretter opp reserveveien som må forbli blokkert, fordi en vei rundt de sentrale kontrollene er verre enn et rent avbrudd. Gi begge testene til leverandøren og be om deres forventede resultat skriftlig, inkludert deteksjon og varsling.

Kjør de samme testene fra et pilotsted og sammenlign dem med det skriftlige svaret. Der de to er uenige, beskriver kontrakten et annet nettverk enn det du kjøpte. To kommandoer dekker de vanlige tilfellene: den ene viser veien en offentlig destinasjon tar, den andre viser adressen den ser.

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

Knytt tilgjengelighetsforpliktelsene til segmentet du målte, ikke til tjenestens navn. En lokal linje, en leverandørryggrad og en delt gateway bærer separate forpliktelser og separate eskalerte team. Bokstavene L2VPN, L3VPN og MPLS beskriver en videresendingsmekanisme, ikke en garanti fra ende til ende.

Dokumentasjon slår adjektivene i tilbudet

Ord som redundant, sikker og robust beskriver en intensjon og ikke et design. Be i stedet om enhetslisten, utgangsplasseringene, oversettelsesskjemaet og varslingsveien. En leverandør som kan produsere de fire elementene, har et design; en som ikke kan, har en presentasjon. Hold svarene i tjenestedokumentasjonen i stedet for i en e-posttråd, og gå gjennom dem ved hver kontraktsendring.

Utgangsarrangementer endrer seg stille mens leverandører konsoliderer gatewayer, så et diagram fra for tre år siden er en byrde. Når en partner rapporterer en ukjent kildeadresse, bør du kunne si innen få minutter om den kom fra designet ditt eller fra en endring ingen kunngjorde. Nettopp den evnen, og ikke adjektivene, overlever det første avbruddet.