Po iššifravimo: kuri politika pirmoji pamato jūsų VPN srautą

VPN srautas gali būti visiškai užšifruotas ir autentifikuotas, o vis tiek atsidurti ten, kur niekas neplanavo. Kabelis nenustato, kuri taisyklė apdoroja vidinį paketą; tai daro politikos kabliukas ir maršrutas. Todėl du vienodai atrodantys dizainai gali būti vykdomi visiškai skirtingai. Pasirinkimas prasideda įvardijant kontrolę, kuri pirmoji pamato iššifruotą srautą.

Spręskite pagal politikos kabliuką, o ne prievadą

Kiekviena VPN platforma vertina iššifruotą srautą tam tikrame taške prieš jį persiųsdama, ir tas taškas turi pavadinimą. Vienur tai grupinės politikos filtras, kitur sąsajos politika ar zonų pora, o maršrutizatoriuje – tiesiog forward grandinė. Kabliukas vykdo taisyklę, o komutatoriaus prievadas tėra vieta, kur baigiasi kabelis. Rasti kabliuką – pirmasis sprendimas, nes visa kita išdėstoma jo atžvilgiu.

Pirmiausia užrašykite srautą: šaltinis, tikslas, protokolas ir leidžiama paslauga. Tada raskite kontrolę, kuri įgyvendina kiekvieną iš šių keturių faktų.

Du keliai, dvi skirtingos vykdymo istorijos

Dvi formos įprastos, ir kiekviena gali būti teisinga skirtingam reikalavimui.

endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnet

Pirmoji forma gali įgyvendinti viską ties šliuzu, jei politika parašyta tam tikslui ir serveris neturi aplenkimo kelio. Antroji prideda ribą, bet tik jei maršrutai ir politika tikrai praleidžia srautą. Serveris tame pačiame segmente gali niekada nesekti įsivaizduoto tarpinio šuolio. Schema rodo ketinimą, maršrutų lentelė – kas vyksta.

Tikrinkite maršruto paieška, ne piešiniu. Sąsaja, pro kurią paketas išeina, ir kitas šuolis lemia, ar antroji forma veikia kaip suprojektuota.

ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20

Atskirkite topologiją nuo izoliacijos

Bendras potinklis nepadaro vietos nepatikima, o dedikuotas tranzitas – apsaugota. Lemia taikomas apribojimas, vykstantis persiuntimas ir kas administruoja kiekvieną dalį. Komutatorių skaičiavimas nieko nesako. Spręskite iš politikos ir maršruto, o topologija teseka sprendimą.

Trafiko populiacijas traktuokite atskirai. Nuotolinės prieigos baseinai, svetainės priešdėliai ir privačių linijų tinklai gali dalytis įrenginiu ir vis tiek reikalauti skirtingų taisyklių, nes tapatybė ir rizika skiriasi. Vienai populiacijai parašyta taisyklė tyliai apima kitas, kai jos dalijasi adresų planu.

Tikrinkite gedimą ir valdymą kiekvienam išdėstymui

Kiekvienas išdėstymas turi gedimo režimą, o naudingas klausimas – kas dar veikia, kai komponentas sustoja. Keli loginiai sąsajos viename negyvame įrenginyje neduoda nepriklausomo atkūrimo, o žemesnė užkarda su tuo pačiu maitinimu ar administratoriumi nėra antra riba. Klauskite, kur eina valdymo kelias, nes konsolė, pasiekiama tik per tunelį, nėra atkūrimo kelias; ssh [email protected] true už tunelio – pigiausias būdas įrodyti, kad konsolė nuo jo nepriklauso. Vienos platformos grupinės politikos dokumentacija deda filtrą ant srauto po iššifravimo ir prieš šifravimą, būtent toks įvardytas kabliukas, kurio ieškoti bet kuriame produkte.

Rašykite kiekvieno kandidato gedimo istoriją šalia vykdymo istorijos. Išdėstymas, kuris laimi patikrinime ir pralaimi atkūrime, yra mainai, ir tai turi būti užrašyta, o ne atrasta incidento metu.

Priimkite su leidžiamu ir uždraustu srautu

Su patvirtintu planu patikrinkite tris dalykus iš tikro VPN šaltinio: programą, kuri turėtų veikti, išteklių, kuris neturėtų, ir kryptį, kuria grįžta atsakymas. Atsisakymas įrodo, kad politika įjungta, o leidžiamas srautas – tik kad kelias egzistuoja.

Saugokite pasirinktą kelią ir rezultatą kartu, nes rezultatas be kelio neatkuriamas, o kelias be rezultato neapginamas. Ši pora naudingesnė renkantis prisijungimo tašką nei bet koks teiginys apie saugesnį perjungimo sluoksnį.