Šifrēts tranzīts nedod piekļuvi operatoram
Šifrēšana slēpj kravu no tranzīta novērotājiem. Tā nedod zemākas uzticības resursdatoram maršrutus uz operatora tīklu, DNS vai privātiem pakalpojumiem.
Divi apstiprināti vārteji pārvieto zemākas uzticības tīkla datplūsmu pāri ierobežotam transporta tīklam. Kravas šifrēšana padara to nelasāmu parastiem tranzīta novērotājiem, un tā ir tā daļa, ko cilvēki izstrādā vispirms un pēc tam pārstāj par to domāt. Ko šifrēšana nedara, ir nenosaka, kurus resursus zemākas uzticības puse drīkst sasniegt. Projektam vajadzīgas divas robežas: viena ap pārvietoto sarunu un otra ap piekļuvi pašam operatoram.
Veiciet tālāk norādītās darbības secīgi un uzskatiet jebkuras darbības neveiksmi par projekta izmaiņām, nevis konfigurācijas pielāgošanu.
Definējiet abas robežas pirms konfigurācijas aizskaršanas
Pirmā robeža ir saruna: kuri vārteju pāri drīkst izveidot tuneli un kura iekšējā datplūsma drīkst tam iet cauri. Otrā ir operators: kurus adreses un pakalpojumus zemākas uzticības resursdatori var sasniegt ārpus tuneļa. Komandas parasti būvē pirmo un manto otro no jebkuras jau pastāvošas maršrutēšanas, un tā ierobežots projekts klusi kļūst plašs. Šī mantošana ir ierastais pamatcēlonis, kad pārskatā tiek atklāts, ka zemākas uzticības resursdators runā ar kaut ko, ko neviens nav apstiprinājis.
Pierakstiet abas kā adrešu, portu un virzienu sarakstus. Ja sarakstu nevar pierakstīt, robeža vēl nav definēta.
1. solis: ierobežojiet ārējo tuneli
Saskarnē, kas vērsta pret operatoru, atļaujiet tikai to, kas tunelim nepieciešams: IKE uz UDP 500 un 4500 starp divām vārtejas adresēm un ESP tur, kur netiek izmantota NAT pāreja. Noraidiet visu pārējo, kas nonāk šajā saskarnē, tostarp pārvaldības protokolus. ESP specifikācija aptver aizsardzības pakalpojumus; tā neko nepasaka par to, kurus operatora paša pakalpojumus vārteji drīkst izmantot. Izsakiet to kā skaidru atļauju sarakstu, lai nesen publicēts operatora pakalpojums nekļūtu pieejams pēc noklusējuma.
Šis ir noteikumu kopums, kas projektu padara par tranzīta projektu, nevis peering vienošanos.
Pārbaudiet to no zemākas uzticības puses, nevis no vārtejas konsoles. Tur esošajam resursdatoram vajadzētu nespēt sasniegt operatora DNS serveri jau pirms tuneļa pacelšanas.
2. solis: izlemiet, ko piegādā tālais vārtejs
Tālajā galā atjaunotajai datplūsmai jānonāk konkrētā vietā. Definējiet, kuri iekšējie pakalpojumi ir atļauti, no kuriem avota diapazoniem un vai tiek gaidītas simetriskas atbildes. Pārskatiet pārvaldības piekļuvi atsevišķi, jo tas pats vārtejs bieži atklāj administratīvu saskarni, kas nekad nav bijusi tranzīta plāna daļa.
Diagramma, kas apstājas pie veiksmīgas atšifrēšanas, ir izlaidusi svarīgāko lēmumu.
3. solis: saglabājiet īpašumtiesības pa slāņiem
Tranzīta iekārta joprojām saņem un pārsūta ārējos paketes, tāpēc tai vajag ielāpus un jaudas plānošanu. Tuneļa galapunkti apstrādā aizsargāto protokolu un atklāj iekšējo datplūsmu savam pārsūtīšanas ceļam, tāpēc tiem vajag savus noteikumus un savu uzraudzību. Gala lietojumprogrammas apstrādā kravu, un necaurspīdīga krava nav pierādījums, ka atšifrēta lejupielāde ir nekaitīga.
Piešķiriet katram slānim īpašnieku. Slāņi bez īpašnieka ir tie, kas aizpeld.
4. solis: pārbaudiet, pēc tam nododiet to iestādei
Pārbaudiet ārējo ceļu, kad tunelis ir pacelts un operatora noteikumi ir spēkā. Pēc tam izmēģiniet katru resursu, kuram zemākas uzticības pusei nevajadzētu piekļūt, un apstipriniet, ka neveiksme ir atteikums, nevis maršrutu slēpjošs taimauts. Pārbaudiet arī pieejamību un resursu ierobežojumus, jo arī šifrētu savienojumu var piesātināt.
Regulētās vai klasificētās vidēs nogādājiet projektu atbildīgajai drošības iestādei un izmantojiet tās apstiprināto atdalīšanas arhitektūru. VPN konfigurācija un konceptuāls skaidrojums neveido akreditāciju. Šis solis nav papīru darbs; tas izlemj, vai projektam vispār drīkst būt.