Uzzīmējiet atšifrēto ceļu: kur VPN ierīce piemēro politiku

Piegādātāju diagrammas parasti apstājas pie šifrētā klausītāja, jo tā ir daļa ar publisku adresi. Drošības stāvokli nosaka jautājums, kas notiek pēc atšifrēšanas, kad pakete kļūst par parastu IP un var sasniegt visu, ko atļauj maršrutēšanas tabula. Ja neviens to posmu nav uzzīmējis, tam nav arī īpašnieka. Zemāk esošā rokasgrāmata vispirms to uzzīmē un pēc tam salīdzina izvietojumus pēc tā, ko atšifrētais pieprasījums faktiski šķērso.

Zīmējiet paketi pēc atšifrēšanas, nevis pirms

Ārējais ceļš ir daļa, ko dokumentē piegādātāji: publisks galapunkts, transporta politika, kas pieņem savienojumu, un pakalpojums, kas to pabeidz. Iekšējais ceļš sākas mirklī, kad pakete zaudē tuneļa galveni, un no turienes to pārvalda maršrutēšanas un filtrēšanas noteikumi, kuriem ar tuneli nav nekāda sakara. Liekiet abus vienā lapā, jo diagramma tikai ar pirmo liek domāt, ka uzņemšana un autorizācija ir viens lēmums. Tā nav, un tieši plaisa starp tiem ir vieta, kur vairums izvietojumu kļūdās.

Iekšējo posmu rakstiet kā numurētu secību ar nosauktiem ierīču tipiem, nevis kā bultu. Bulta slēpj, vai pieprasījums šķērso filtru, un šķērsot vai nešķērsot ir viss jautājums. Katrs solis zemāk nosauc ierīci un tur darbojošos noteikumu kopu, tāpēc trūkstošais filtrs parādās kā robs, nevis kā ar līniju netieši norādīts.

1. Attālinātais klients: lietotāja ierīce, kas izveido tuneli.
2. Malas politika: noteikumu kopa, kas pieņem ārējo transportu publiskajā klausītājā.
3. Pabeidzošā ierīce: VPN galapunkts, kas dekapsulē un nodod paketi parastajai IP.
4. Iekšējais filtrs: pāradresācijas vai drošības grupas noteikumu kopa, kas ierobežo datplūsmu no klienta uz pakalpojumu.
5. Lietotnes resursdators: pakalpojums, kas saņem atšifrēto pieprasījumu.

Divas politikas, divi īpašnieki

Ārējā politika atbild, kas drīkst izveidot tuneli, un tā izpaužas noteikumos, kas pieņem transportu uz pabeidzošo pakalpojumu. Iekšējā politika atbild, kuram pakalpojumam autentificēts lietotājs drīkst piekļūt, un tā mīt pāradresācijas noteikumos, drošības grupās vai pašā lietotnē. Viena ierīce var mitināt abas, un projektam ar vairākām ierīcēm joprojām ir abas. Tieši to atsevišķa nosaukšana ļauj pateikt, kura neizdevās, kad lietotājs nenokļūst lietotnē.

Uzņemšanas kontroles, piemēram, sertifikāti un daudzfaktoru autentifikācija, atbild par identitāti un neko citu. Tās nenosaka izvietojumu un nepiešķir atļauju katram resursam pēc tam, kad lietotājs jau ir iekšā.

Izvietojums nosaka, kuru robežu pieprasījums šķērso

Trīs izvietojumi ir izplatīti, un katrs maina, kuru robežu šķērso atšifrētais pieprasījums. Salīdziniet tos pēc tā, kas tur beidzas, kas var redzēt atklātu tekstu, kura kontrole vēl var noraidīt pieprasījumu un kas sabrūk kopā ar ierīci. Zemāk esošā tabula izmanto šīs četras kolonnas vispārīga jautājuma vietā, jo katra atbilde ir atsevišķs projektēšanas lēmums.

Trešais izvietojums ir tas, kas klusi noņem izpildi, jo posms aizsargātajā segmentā dod ierīcei tiešu ceļu, ko diagramma var arī neuzrādīt. Pārbaudiet saskarnes un maršrutus, nevis attēlu: ip route get 10.20.5.10 ziņo, pa kuru saskarni pakete izietu, un atbilde bieži nav tā, ko projekts pieņēma. Ugunsmūra klasiskā loma kontrolēt datplūsmu starp pozām, kā aprakstītsNIST SP 800-41, šeit ir noderīgs tests, jo ierīce ar neierobežotu posmu uz aizsargāto tīklu daudz ko nekontrolē. Maršruta meklēšana ir godīgāka diagramma nekā tā prezentācijā.

Administrēšana pieder savam skaidri atļautajam ceļam. Ļaušana lietotājiem sasniegt lietotni nekad neprasa ļaut viņiem sasniegt ierīces vadības saskarni, un abas atļaujas jādod no atšķirīgiem noteikumiem. Audīt abus ceļus atsevišķi, jo kopīgs noteikums slēpj, kurš tika atvērts.

Tulkošana maina to, ko var redzēt turpmākie noteikumi

Avota tulkošana ir ērta un tā iznīcina informāciju. Pēc masquerade katrs klients izskatās kā ierīce, tāpēc turpmākais noteikums, kas rakstīts lietotāju atšķiršanai, to vairs nevar. Tā nav tikai žurnālu problēma, tā ir politikas problēma: noteikums, kas piesaistīts klienta adresei, klusi kļūst par noteikumu, kas piesaistīts vārtejai. Ja politika katram lietotājam ir svarīga, saglabājiet avotu vai piemērojiet politiku pirms tulkošanas.

Atbildes ceļš ir pelnījis tādu pašu pārbaudi. Pierakstiet, kuru maršrutu galamērķis izvēlas atgriešanās paketei, jo asimetriska atgriešanās apiet stāvokļa pārbaudi un rada savienojumu, kas nodibinās un pēc tam iestrēgst. Abiem virzieniem jāšķērso uzzīmētā robeža, citādi robeža ir dekorācija.

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

Pieņemiet atļautu un noraidītu darbību

Testējiet no īstā attālinātā klienta, nevis no pārvaldības resursdatora, jo pārvaldības resursdators parasti atrodas tur, kur lietotājs nekad nebūs. Viena atļauta darbība pierāda, ka ceļš strādā, un viena noraidīta pierāda, ka politika vispār kaut ko dara. Palaidiet abas pēc katras izvietojuma izmaiņas un pierakstiet izmantoto avota identitāti un galamērķi. Tests, kas pierāda tikai panākumus, nespēj atšķirt pareizu noteikumu no trūkstoša.

Pēc tam testējiet gadījumus, kas maina stāvokli: atkārtotu savienojumu, sesiju, kas pārdzīvo atslēgu rotāciju, un pašas ierīces bojājumu. Salīdziniet atjauninājumus, jaudu un atjaunošanu kā tā paša izkārtojuma daļu, jo viena ierīce, kas tur vairākas loģiskās kontroles, ir viena kļūmes joma ar vairākām etiķetēm. Arī otra kaste nav neatkarīga, ja kopīgi administratīvie akreditācijas dati vai neierobežots maršruts pārspēj robežu, ko tai bija jāizveido.

Dokumentējiet galapunktu, atšifrēto ceļu un kontroli, kas to ierobežo. Šīs trīs rindas paliek nozīmīgas, lai kā arī sauktu ieviešanu.