Hvor din administrerede VPNs internettrafik egentlig forlader netværket

Du kan ikke sige, hvem der filtrerer en afdelings offentlige trafik, før tilbuddet viser, hvor den trafik forlader udbyderens netværk. Internettadgang, der er inkluderet i et administreret VPN, er en anden tjeneste, som kører på en rute med sine egne gateways, sin egen adresseoversættelse og sin egen eskaleringskø. De fleste kontrakter beskriver den private side i detaljer og overlader den offentlige side til én sætning. Kontrollerne nedenfor gør den sætning til et diagram, du kan forsvare.

Følg én offentlig destination per lokation

Vælg en vært i en afdeling, og følg én offentlig destination, idet du noterer den sidste adresse, der tilhører udbyderen, og den første, der tilhører internettet. Springet mellem de to adresser er udgangen, og det ligger ofte langt fra den lokation, der sendte pakken. Markér den enhed, der udfører overgangen, fordi netop den enhed har det filter, der afgør, hvad der kommer ud. Gentag sporingen fra en anden lokation, og sammenlign udgangsadresserne, fordi to afdelinger, der ser ens ud på fakturaen, kan forlade netværket gennem forskellige gateways i forskellige byer.

Notér også den kildeadresse, som destinationen faktisk ser, fordi oversættelse kan ske på et spring, du aldrig har tegnet. Skriv de observerede svar ved siden af de tegnede, og afstanden mellem dem er, hvor den første hændelse vil komme fra. En udbyderingeniør, der ikke kan oplyse udgangsadressen for en given lokation, har allerede fortalt dig noget nyttigt om designet.

Tre udgangsarrangementer og hvad hver af dem samler

En central udgang, som du selv driver, trækker den offentlige trafik til en gateway, du ejer, hvilket giver dig filtreringspolitikken og logfilerne, men samler alle lokationers belastning på ét kredsløb. En udbyderdrevet udgang flytter politik og logfiler over kontraktgrænsen, hvilket forenkler driften og fjerner din synlighed i samme bevægelse. En udgang på hver lokation holder den offentlige trafik lokal og mangedobler antallet af politikflader, der skal forblive identiske.

Spørg, hvilken af de tre udbyderen faktisk tilbyder, før du behandler listen som en menu, og spørg, om en lokation kan flytte mellem dem uden et nyt kredsløb. Svaret om migrering adskiller det kontraktuelle fra det rent tekniske. Notér også, hvem der ejer kildeoversættelsen, fordi det afgør, hvad en partner skal sætte på tilladelseslisten. Delte gateways betyder også delt kapacitet og indimellem delt omdømme, hvilket ændrer, hvordan partnere behandler dine adresser. Kapacitet fortjener også sit eget spørgsmål, fordi en delt gateway betjener andre kunder i samme øjeblik.

Filtrering, oversættelse og kryptering har hver deres ejer

En rute etablerer nåbarhed og siger intet om inspektion, så behandl de to som forskellige spørgsmål med forskellige ejere. For hver annonceret standardrute skal du navngive den enhed, der filtrerer, den enhed, der autentificerer, den enhed, der oversætter, og den enhed, der inspicerer, og derefter navngive, hvem der administrerer hver af dem. Udbyderens ruteseparering siger ikke, hvor krypteringen slutter, og en privat tjeneste kan afslutte sin tunnel ved én grænse, mens den offentlige udgang slutter ved en anden. Spørg, om oversættelsen sker ved udbyderens kant, ved en delt gateway eller ved din egen udgang, og om der findes sessionslogfiler, og hvor længe de gemmes. Tæl ejerne i svarene, fordi en kontrakt, der udpeger én part til fire opgaver, normalt efterlader tre af dem udokumenterede.

En bred standardrute importeret til den private routingkontekst fortjener samme granskning, fordi en import er en bevidst aftale og ikke en uskyldig bekvemmelighed. Afsnit 11 i RFC 4364 gennemgår flere internetadgangsarrangementer til BGP/MPLS-VPN'er og behandler udveksling af ruter mellem VPN-konteksten og udbyderens standardvideresendelseskontekst som netop den slags aftale. Spørg, hvad der forhindrer offentlig trafik i ved et uheld at tage en privat rute, og få svaret ved siden af rutepolitikken i stedet for i en præsentation.

To fejltilfælde, der skal aftales før underskrift

Skriv to test i kontrakten: mist internetudgangen, og mist én privat tilslutning. For hver af dem skal du liste de interne ressourcer, de lokale internettjenester og de administrationsveje, der skal blive ved med at virke. List derefter den reservevej, der skal forblive blokeret, fordi en vej uden om de centrale kontroller er værre end et rent afbrud. Giv begge test til udbyderen, og bed om deres forventede resultat på skrift, inklusive detektion og varsling.

Kør de samme test fra en pilotlokation, og sammenlign dem med det skriftlige svar. Hvor de to er uenige, beskriver kontrakten et andet netværk end det, du har købt. To kommandoer dækker de almindelige tilfælde: den ene viser den vej, en offentlig destination tager, den anden viser den adresse, den ser.

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

Knyt tilgængelighedsløfter til det segment, du målte, i stedet for til tjenestens navn. Et lokalt kredsløb, en udbyderrygrad og en delt gateway bærer hver deres forpligtelser og hver deres eskaleringshold. Bogstaverne L2VPN, L3VPN og MPLS beskriver en videresendelsesmekanisme, ikke en garanti fra ende til ende.

Dokumentation slår tillægsordene i tilbuddet

Ord som redundant, sikker og modstandsdygtig beskriver en hensigt og ikke et design. Bed i stedet om enhedslisten, udgangslokationerne, oversættelsesplanen og varslingsvejen. En udbyder, der kan levere de fire ting, har et design; en udbyder, der ikke kan, har en præsentation. Hold svarene i servicedokumentationen i stedet for i en mailtråd, og tag dem op igen ved hver kontraktændring.

Udgangsarrangementer ændrer sig stille, efterhånden som udbydere konsoliderer gateways, så et diagram fra for tre år siden er en byrde. Når en partner rapporterer en ukendt kildeadresse, bør du inden for få minutter kunne sige, om den kom fra dit design eller fra en ændring, ingen annoncerede. Netop den evne, og ikke tillægsordene, overlever det første nedbrud.