Kryptert transitt gjev ikkje tilgang til operatøren

To godkjende gatewayar ber trafikken frå eit netverk med lågare tillit over eit avgrensa transportnetverk. Kryptering av nyttelasta held henne uleseleg for vanlege transittobservatørar, og det er den delen folk designar fyrst og deretter sluttar å tenkje på. Det kryptering ikkje gjer, er å definere kva ressursar sida med lågare tillit kan nå. Designet treng to grenser: éi rundt samtalen som vert boren, og éi rundt tilgangen til operatøren sjølv.

Utfør trinna nedanfor i rekkjefølgje, og handsam ein feil på eit kva som helst trinn som ei designendring, ikkje ei konfigurasjonsjustering.

Definer begge grensene før du rører ein konfigurasjon

Den fyrste grensa er samtalen: kva par av gatewayar som kan setje opp ein tunnel, og kva indre trafikk som får passere gjennom han. Den andre er operatøren: kva adresser og tenester vertane med lågare tillit kan nå utanfor tunnelen. Team byggjer vanlegvis den fyrste og arvar den andre frå kva som helst ruting som allereie fanst, og det er slik eit avgrensa design stille vert eit breitt. Den arven er den vanlege grunnårsaka når ein gjennomgang finn ein vert med lågare tillit som snakkar med noko ingen godkjende.

Skriv begge ned som lister over adresser, portar og retningar. Viss ei liste ikkje kan skrivast, er grensa ikkje definert enno.

Trinn 1: avgrens den ytre tunnelen

På grensesnittet som vender mot operatøren, tillat berre det tunnelen treng: IKE på UDP 500 og 4500 mellom dei to gateway-adressene, og ESP der NAT-gjennomtrenging ikkje vert brukt. Avvis alt anna som kjem inn på dette grensesnittet, inkludert administrasjonsprotokollar. ESP-spesifikasjonen dekkjer vernetenestene; han seier ingenting om kva av operatøren sine eigne tenester gatewayane kan bruke. Uttrykk det som ei eksplisitt tillatingsliste, slik at ei nyleg publisert operatørteneste ikkje vert tilgjengeleg som standard.

Dette er regelverket som gjer designet til eit transittdesign og ikkje ein peering-avtale.

Kontroller det frå sida med lågare tillit, ikkje frå gateway-konsollen. Ein vert der bør ikkje kunne nå ein DNS-tenar hos operatøren sjølv før tunnelen er oppe.

Trinn 2: avgjer kva den fjerne gatewayen leverer

I den fjerne enden må gjenoppretta trafikk gå ein bestemd stad. Definer kva indre tenester som er tillatne, frå kva kjeldeområde, og om svara vert venta symmetriske. Gå gjennom administrasjonstilgang separat, fordi den same gatewayen ofte eksponerer eit administrativt grensesnitt som aldri var ein del av transittplanen.

Eit diagram som stoppar ved vellukka dekryptering, har hoppa over avgjerda som tyder mest.

Trinn 3: hald eigarskap per lag

Transittutstyr tek imot og videresender framleis ytre pakkar, så det treng oppdateringar og kapasitetsplanlegging. Tunnelendepunkt handsamar den verna protokollen og eksponerer indre trafikk for videresendingsvegen sin, så dei treng eigne reglar og eiga overvaking. Endelege applikasjonar handsamar nyttelasta, og ei ugjennomsiktig nyttelast er ikkje prov på at ei dekryptert nedlasting er ufarleg.

Tildel ein eigar til kvart lag. Laga utan eigar er dei som driv.

Trinn 4: verifiser, og overlat det deretter til styresmakta

Verifiser den ytre vegen med tunnelen oppe og operatørreglane på plass. Prøv deretter kvar ressurs som sida med lågare tillit ikkje skal nå, og stadfest at feilen er ei avvising og ikkje ein tidsavbrot som gøymer ein rute. Kontroller òg tilgjenge og ressursgrenser, fordi ei kryptert lenkje framleis kan mettast.

For regulerte eller klassifiserte miljø, ta designet til den ansvarlege tryggleiksstyresmakta og bruk den godkjende separasjonsarkitekturen hennar. Ein VPN-konfigurasjon og ei konseptuell forklaring etablerer ikkje akkreditering. Det trinnet er ikkje papirarbeid; det avgjer om designet i det heile får eksistere.