Šifruotas tranzitas nesuteikia prieigos prie operatoriaus

Du patvirtinti šliuzai perduoda mažesnio pasitikėjimo tinklo srautą per ribotą transporto tinklą. Naudingosios apkrovos šifravimas palieka ją neįskaitomą įprastiems tranzito stebėtojams, ir tai yra ta dalis, kurią žmonės projektuoja pirmiausia, o paskui nustoja apie ją galvoti. Ko šifravimas nedaro, tai neapibrėžia, kuriuos išteklius mažesnio pasitikėjimo pusė gali pasiekti. Projektui reikia dviejų ribų: vienos aplink perduodamą pokalbį ir kitos aplink prieigą prie paties operatoriaus.

Atlikite toliau pateiktus veiksmus iš eilės ir bet kurio veiksmo nesėkmę traktuokite kaip projekto pakeitimą, o ne konfigūracijos koregavimą.

Apibrėžkite abi ribas prieš liesdami konfigūraciją

Pirmoji riba yra pokalbis: kurios šliuzų poros gali sukurti tunelį ir koks vidinis srautas gali juo eiti. Antroji yra operatorius: kuriuos adresus ir paslaugas mažesnio pasitikėjimo hostai gali pasiekti už tunelio. Komandos paprastai stato pirmąją, o antrąją paveldi iš bet kokio jau egzistavusio maršrutizavimo, ir taip ribotas projektas tyliai tampa platus. Tas paveldėjimas yra įprasta pagrindinė priežastis, kai peržiūra randa mažesnio pasitikėjimo hostą kalbant su kažkuo, ko niekas nepatvirtino.

Abi surašykite kaip adresų, prievadų ir krypčių sąrašus. Jei sąrašo negalima surašyti, riba dar neapibrėžta.

1 veiksmas: apribokite išorinį tunelį

Sąsajoje, nukreiptoje į operatorių, leiskite tik tai, ko reikia tuneliui: IKE per UDP 500 ir 4500 tarp dviejų šliuzo adresų ir ESP ten, kur nenaudojamas NAT perėjimas. Atmeskite visa kita, kas patenka į šią sąsają, įskaitant valdymo protokolus. ESP specifikacija apima apsaugos paslaugas; ji nieko nesako apie tai, kurias operatoriaus pačio paslaugas šliuzai gali naudoti. Išreikškite tai kaip aiškų leidimų sąrašą, kad naujai paskelbta operatoriaus paslauga netaptų pasiekiama pagal nutylėjimą.

Tai taisyklių rinkinys, kuris projektą daro tranzito projektu, o ne peering susitarimu.

Patikrinkite tai iš mažesnio pasitikėjimo pusės, o ne iš šliuzo konsolės. Ten esantis hostas turėtų nepasiekti operatoriaus DNS serverio dar prieš pakeliant tunelį.

2 veiksmas: nuspręskite, ką pristato tolimas šliuzas

Tolimame gale atkurtas srautas turi eiti į konkrečią vietą. Apibrėžkite, kurios vidinės paslaugos leidžiamos, iš kurių šaltinio diapazonų ir ar tikimasi simetriškų atsakymų. Atskirai peržiūrėkite administravimo prieigą, nes tas pats šliuzas dažnai atveria administracinę sąsają, kuri niekada nebuvo tranzito plano dalis.

Diagrama, kuri sustoja ties sėkmingu iššifravimu, praleido svarbiausią sprendimą.

3 veiksmas: išlaikykite nuosavybę pagal sluoksnį

Tranzito įranga vis dar priima ir persiunčia išorinius paketus, todėl jai reikia pataisų ir pajėgumų planavimo. Tunelio galiniai taškai apdoroja apsaugotą protokolą ir atveria vidinį srautą savo persiuntimo keliui, todėl jiems reikia savo taisyklių ir savo stebėsenos. Galutinės programos apdoroja naudingąją apkrovą, ir nepermatoma apkrova nėra įrodymas, kad iššifruotas atsisiuntimas nekenksmingas.

Priskirkite kiekvienam sluoksniui savininką. Sluoksniai be savininko yra tie, kurie nukrypsta.

4 veiksmas: patikrinkite, tada perduokite institucijai

Patikrinkite išorinį kelią, kai tunelis pakeltas ir operatoriaus taisyklės galioja. Tada išbandykite kiekvieną išteklių, kurio mažesnio pasitikėjimo pusė neturėtų pasiekti, ir patvirtinkite, kad nesėkmė yra atmetimas, o ne maršrutą slepiantis laiko limitas. Patikrinkite ir prieinamumą bei išteklių ribas, nes net šifruota jungtis gali būti prisotinta.

Reguliuojamose ar slaptose aplinkose nuneškite projektą atsakingai saugumo institucijai ir naudokite jos patvirtintą atskyrimo architektūrą. VPN konfigūracija ir koncepcinis paaiškinimas nesukuria akreditacijos. Šis veiksmas nėra popierizmas; jis nusprendžia, ar projektas apskritai gali egzistuoti.