Teikn den dekrypterte vegen: kvar ein VPN-eining handhevar policy

Leverandiagram stoppar vanlegvis ved den krypterte lyttaren, fordi det er delen med ei offentleg adresse. Spørsmålet som avgjer tryggleiksposisjonen, er kva som skjer etter dekryptering, når pakken blir vanleg IP og kan nå alt som rutetabellen tillèt. Viss ingen har teikna den delen, eig ingen han. Runboka nedanfor teiknar han først og samanliknar deretter plasseringane etter kva den dekrypterte førespurnaden faktisk kryssar.

Teikn pakken etter dekryptering, ikkje før

Den ytre vegen er delen leverandørar dokumenterer: eit offentleg endepunkt, ein transportpolicy som slepp sambandet inn, og ei teneste som terminerer det. Den indre vegen byrjar i det augeblikket pakken mistar tunnelhovudet, og derfrå blir han styrt av rutings- og filterreglar som ikkje har noko med tunnelen å gjere. Set begge på same sida, fordi eit diagram med berre den første antydar at opptak og autorisasjon er éi avgjerd. Det er dei ikkje, og nettopp gapet mellom dei er der dei fleste plasseringane går gale.

Skriv den indre delen som ein nummerert sekvens med namngjevne einingstypar i staden for ei pil. Ei pil løyner om førespurnaden kryssar eit filter, og kryssar eller ikkje kryssar er heile spørsmålet. Kvart hopp nedanfor namngjev eininga og regelsettet som verkar der, slik at eit manglande filter blir synleg som eit hol i staden for å bli antyda av ei linje.

1. Fjernklient: eininga til brukaren som opprettar tunnelen.
2. Kantpolicy: regelsettet som slepp den ytre transporten inn til den offentlege lyttaren.
3. Terminerande eining: VPN-endepunktet som dekapsulerer og overleverer pakken til vanleg IP.
4. Indre filter: regelsettet for vidaresending eller tryggleiksgrupper som avgrensar trafikk frå klient til teneste.
5. Applikasjonsvert: tenesta som tek imot den dekrypterte førespurnaden.

To policyar, to eigarar

Den ytre policyen svarar på kven som kan etablere ein tunnel, og han blir uttrykt i reglane som slepp transporten inn til den terminerande tenesta. Den indre policyen svarar på kva teneste ein autentisert brukar kan nå, og han lever i vidaresendingsreglar, tryggleiksgrupper eller sjølve applikasjonen. Éi eining kan huse begge, og eit design med fleire einingar har framleis begge. Det er den separate namngjevinga som gjer det mogleg å seie kven som svikta når ein brukar ikkje når ein applikasjon.

Opptakskontrollar som sertifikat og multifaktorautentisering svarar på identitet og ingenting anna. Dei avgjer ikkje plasseringa og gir ikkje løyve per ressurs når brukaren først er innanfor.

Plasseringa avgjer kva grense førespurnaden kryssar

Tre plasseringar er vanlege, og kvar endrar kva grense den dekrypterte førespurnaden kryssar. Samanlikn dei etter kva som terminerer der, kva som kan sjå klartekst, kva kontroll som framleis kan avslå førespurnaden, og kva som feilar saman med eininga. Tabellen nedanfor brukar dei fire kolonnane i staden for eit generelt spørsmål, fordi kvart svar er ei eiga designavgjerd.

Den tredje plasseringa er den som stille fjernar handhevinga, fordi ein del på det verna segmentet gir eininga ein direkte veg som diagrammet kanskje ikkje viser. Undersøk grensesnitt og ruter i staden for biletet: ip route get 10.20.5.10 rapporterer kva grensesnitt pakken ville fara ut gjennom, og svaret er ofte ikkje det designet antok. Den klassiske rolla til brannmuren med å kontrollere trafikk mellom posisjonar, som skildra iNIST SP 800-41, er ein nyttig test her, fordi ei eining med ein ubegrensa del til det verna nettet ikkje kontrollerer stort. Eit ruteoppslag er eit ærlegare diagram enn det i presentasjonen.

Administrasjon høyrer heime på sin eigen uttrykkeleg tillatne veg. Å la brukarar nå ein applikasjon krev aldri å la dei nå kontrollgrensesnittet til eininga, og dei to løyva bør givast frå ulike reglar. Revider begge vegane separat, fordi ein delt regel løyner kven som vart opna.

Omsetjing endrar kva reglar lenger nede kan sjå

Kjeldeomsetjing er praktisk, og ho øydelegg informasjon. Etter masquerade ser kvar klient ut som eininga, så ein regel lenger nede som var skriven for å skilje brukarar, kan ikkje lenger gjere det. Dette er ikkje berre eit loggproblem, det er eit policyproblem: ein regel nøkla på klientadresse blir stille ein regel nøkla på gatewayen. Viss policy per brukar betyr noko, ta vare på kjelda eller handhev policyen før omsetjing.

Svarvegen fortener same gransking. Noter kva rute destinasjonen vel for returpakken, fordi ein asymmetrisk retur omgår tilstandsbasert inspeksjon og gir eit samband som blir etablert og deretter stoppar. Begge retningar må krysse grensa du teikna, elles er grensa dekorasjon.

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

Godta éin tillaten og éin avvist operasjon

Test frå den ekte fjernklienten i staden for frå ein administrasjonsvert, fordi administrasjonsverten vanlegvis sit ein stad brukaren aldri vil vere. Éin tillaten operasjon beviser at vegen verkar, og éin avvist beviser at policyen i det heile gjer noko. Køyr begge etter kvar plasseringsendring, og noter kjeldeidentiteten og destinasjonen du brukte. Ein test som berre beviser suksess, kan ikkje skilje ein riktig regel frå ein manglande.

Test deretter tilfella som endrar tilstand: ei attoppkopling, ei økt som overlever ein nøkkelrotasjon, og ein feil i sjølve eininga. Samanlikn oppdateringar, kapasitet og attoppretting som del av same oppsett, fordi éi eining som held fleire logiske kontrollar, er eitt feildomene med fleire etikettar. Ein ekstra boks er heller ikkje uavhengig når eit delt administrativt påloggingsgrunnlag eller ein ubegrensa rute sigrar over grensa han skulle skape.

Dokumenter endepunktet, den dekrypterte vegen og kontrollen som avgrensar han. Dei tre linjene blir verande meiningsfulle uansett kva implementasjonen heiter.