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

Du kan ikkje seie kven som filtrerer den offentlege trafikken til ei filial før tilbodet viser kvar den trafikken forlèt nettverket til leverandøren. Internettilgang som er bunta inn i ein administrert VPN, er ei andre teneste, som går på ei rute med eigne gatewayar, eigen adresseomsetjing og eigen eskaleringskø. Dei fleste kontraktar skildrar den private sida i detalj og overlèt den offentlege sida til éin setning. Kontrollane nedanfor gjer den setninga om til eit diagram du kan forsvare.

Følg éin offentleg destinasjon per stad

Vel ein vert i ei filial og følg éin offentleg destinasjon, og noter den siste adressa som høyrer til leverandøren og den første som høyrer til internettet. Hoppet mellom dei to adressene er utgangen, og det ligg ofte langt frå staden som sende pakken. Merk eininga som utfører overgangen, fordi nettopp den eininga har filteret som avgjer kva som går ut. Gjenta sporinga frå ein annan stad og samanlikn utgangsadressene, fordi to filialar som ser like ut på fakturaen, kan gå ut gjennom ulike gatewayar i ulike byar.

Noter også kjeldadressa som destinasjonen faktisk ser, fordi omsetjinga kan skje på eit hopp du aldri teikna. Skriv dei observerte svara ved sida av dei teikna, og gapet mellom dei er der den første hendinga vil kome frå. Ein ingeniør hos leverandøren som ikkje kan oppgi utgangsadressa for ein gitt stad, har allereie fortalt deg noko nyttig om designet.

Tre utgangsarrangement og kva kvart av dei konsentrerer

Ein sentral utgang som du driv sjølv, trekkjer den offentlege trafikken til ein gateway du eig, noko som gir deg filtreringspolicyen og loggane, men konsentrerer belastninga frå alle stader på éi linje. Ein leverandørdriven utgang flyttar policy og loggar over kontraktgrensa, noko som forenklar drifta og fjernar synlegheita di i same rørsle. Ein utgang på kvar stad held den offentlege trafikken lokal og mangeleggjer talet på policyflater som må halde fram med å vere identiske.

Spør kva av dei tre leverandøren faktisk tilbyr, før du handsamar lista som ei meny, og spør om ein stad kan flytte mellom dei utan ei ny linje. Svaret om migrering skil det kontraktsmessige frå det reint tekniske. Noter også kven som eig kjeldeomsetjinga, fordi det avgjer kva ein partnar må setje på tillatingslista. Delte gatewayar tyder også delt kapasitet og av og til delt omdøme, noko som endrar korleis partnarar handsamar adressene dine. Kapasitet fortener også sitt eige spørsmål, fordi ein delt gateway betener andre kundar i same augneblink.

Filtrering, omsetjing og kryptering har kvar sine eigarar

Ei rute etablerer nåbarheit og seier ingenting om inspeksjon, så handsam dei to som ulike spørsmål med ulike eigarar. For kvar annonsert standardrute, nemn eininga som filtrerer, eininga som autentiserer, eininga som omset og eininga som inspiserer, og nemn deretter kven som administrerer kvar av dei. Rutesepareringa til leverandøren seier ikkje kvar krypteringa sluttar, og ei privat teneste kan avslutte tunnelen sin ved éi grense medan den offentlege utgangen sluttar ved ei anna. Spør om omsetjinga skjer ved kanten av leverandøren, ved ein delt gateway eller ved din eigen utgang, og om det finst sesjonsloggar og kor lenge dei blir gøymde. Tel eigarane i svara, fordi ein kontrakt som nemner éin part for fire oppgåver, vanlegvis lèt tre av dei stå udokumenterte.

Ei brei standardrute importert til den private rutekonteksten fortener same gransking, fordi ein import er ei medviten avtale og ikkje ei uskuldig lettvintheit. Seksjon 11 i RFC 4364 går gjennom fleire internettilgangsarrangement for BGP/MPLS-VPN-ar og handsamar ruteutveksling mellom VPN-konteksten og standard vidaresendingskonteksten til leverandøren som nettopp den typen avtale. Spør kva som hindrar offentleg trafikk i å ta ei privat rute ved eit uhell, og få svaret ved sida av rutepolicyen i staden for i ein presentasjon.

To feiltilfelle som må avtalast før signering

Skriv to testar inn i kontrakten: miste internettutgangen og miste éi privat tilkopling. For kvar av dei, list opp dei interne ressursane, dei lokale internetttenestene og administrasjonsvegane som må halde fram med å verke. List deretter opp reservevegen som må halde fram med å vere blokkert, fordi ein veg rundt dei sentrale kontrollane er verre enn eit reint avbrot. Gi begge testane til leverandøren og be om det forventa resultatet deira skriftleg, inkludert deteksjon og varsling.

Køyr dei same testane frå ein pilotstad og samanlikn dei med det skriftlege svaret. Der dei to er usamde, skildrar kontrakten eit anna nettverk enn det du kjøpte. To kommandoar dekkjer dei vanlege tilfella: den eine viser vegen ein offentleg destinasjon tek, den andre viser adressa han ser.

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

Knytt tilgjengeforpliktingane til segmentet du målte, ikkje til namnet på tenesta. Ei lokal linje, ei leverandørryggrad og ein delt gateway ber separate forpliktingar og separate eskalerte team. Bokstavane L2VPN, L3VPN og MPLS skildrar ein vidaresendingsmekanisme, ikkje ei garanti frå ende til ende.

Dokumentasjon slår adjektiva i tilbodet

Ord som redundant, trygg og robust skildrar ein intensjon og ikkje eit design. Be i staden om eininglista, utgangsplasseringane, omsetjingsskjemaet og varslingsvegen. Ein leverandør som kan produsere dei fire elementa, har eit design; ein som ikkje kan, har ein presentasjon. Hald svara i tenestedokumentasjonen i staden for i ein e-posttråd, og gå gjennom dei ved kvar kontraktsendring.

Utgangsarrangement endrar seg stille medan leverandørar konsoliderer gatewayar, så eit diagram frå for tre år sidan er ei byrde. Når ein partnar rapporterer ei ukjend kjeldadresse, bør du kunne seie innan få minutt om ho kom frå designet ditt eller frå ei endring ingen kunngjorde. Nettopp den evna, og ikkje adjektiva, overlever det første avbrotet.