Krypteret transit giver ikke adgang til operatøren

To godkendte gateways bærer trafikken fra et netværk med lavere tillid over et begrænset transportnetværk. Kryptering af nyttelasten holder den ulæselig for almindelige transitobservatører, og det er den del, folk designer først og derefter holder op med at tænke på. Det, kryptering ikke gør, er at definere, hvilke ressourcer siden med lavere tillid må nå. Designet har brug for to grænser: én omkring den transporterede samtale og én omkring adgangen til operatøren selv.

Udfør trinnene nedenfor i rækkefølge, og behandl en fejl på et hvilket som helst trin som en designændring snarere end en konfigurationsjustering.

Definér begge grænser, før du rører en konfiguration

Den første grænse er samtalen: hvilke par af gateways der må oprette en tunnel, og hvilken indre trafik der må passere igennem den. Den anden er operatøren: hvilke adresser og tjenester værterne med lavere tillid må nå uden for tunnelen. Teams bygger normalt den første og arver den anden fra hvilken som helst routing, der allerede fandtes, og det er sådan et begrænset design stille bliver et bredt. Den arv er den sædvanlige grundårsag, når en gennemgang finder en vært med lavere tillid, der taler med noget, ingen har godkendt.

Skriv begge ned som lister over adresser, porte og retninger. Hvis en liste ikke kan skrives, er grænsen ikke defineret endnu.

Trin 1: begræns den ydre tunnel

På det operatørvendte interface må du kun tillade det, tunnelen har brug for: IKE på UDP 500 og 4500 mellem de to gateway-adresser og ESP, hvor NAT-gennemløb ikke bruges. Afvis alt andet, der ankommer på det interface, inklusive styringsprotokoller. ESP-specifikationen dækker beskyttelsestjenesterne; den siger intet om, hvilke af operatørens egne tjenester gateways må bruge. Udtryk det som en eksplicit tilladelsesliste, så en nyligt udgivet operatørtjeneste ikke bliver tilgængelig som standard.

Det er det regelsæt, der gør designet til et transitdesign i stedet for en peeringaftale.

Kontrollér det fra siden med lavere tillid, ikke fra gateway-konsollen. En vært der bør ikke kunne nå en DNS-server hos operatøren, selv før tunnelen er oppe.

Trin 2: beslut, hvad den fjerne gateway leverer

I den fjerne ende skal gendannet trafik gå et bestemt sted hen. Definer, hvilke indre tjenester der er tilladte, fra hvilke kildeområder, og om svarene forventes at være symmetriske. Gennemgå administrationsadgang separat, fordi den samme gateway ofte eksponerer en administrativ grænseflade, der aldrig var en del af transitplanen.

Et diagram, der stopper ved vellykket dekryptering, har sprunget den beslutning over, der betyder mest.

Trin 3: behold ejerskab per lag

Transitudstyr modtager og videresender stadig ydre pakker, så det har brug for patches og kapacitetsplanlægning. Tunnelendepunkter behandler den beskyttede protokol og eksponerer indre trafik for deres videresendelsessti, så de har brug for deres egne regler og deres egen overvågning. Endelige applikationer behandler nyttelasten, og en uigennemsigtig nyttelast er ikke bevis for, at en dekrypteret download er uskadelig.

Tildel en ejer til hvert lag. Lagene uden en ejer er dem, der driver.

Trin 4: verificér, og overdrag det derefter til myndigheden

Verificér den ydre sti med tunnelen oppe og operatørreglerne på plads. Prøv derefter hver ressource, som siden med lavere tillid ikke bør nå, og bekræft, at fejlen er en afvisning og ikke en timeout, der skjuler en rute. Kontrollér også tilgængelighed og ressourcegrænser, fordi et krypteret link stadig kan mættes.

For regulerede eller klassificerede miljøer skal du tage designet til den ansvarlige sikkerhedsmyndighed og bruge dens godkendte adskillelsesarkitektur. En VPN-konfiguration og en begrebsmæssig forklaring etablerer ikke akkreditering. Det trin er ikke papirarbejde; det afgør, om designet overhovedet må eksistere.