VPN, kuris prisijungia, bet nieko nepasiekia, paprastai apibūdinamas kaip ugniasienės problema, o sprendimas, kurio imasi žmonės, yra tunelio sąsają įdėti į patikimą zoną. Tai veikia ta prasme, kad srautas pradeda tekėti, bet taip pat praleidžia kur kas daugiau nei numatyta paslauga. Dvi susijusios politikos skiriasi: viena įleidžia išorinį transportą į klausančią lizdą, kita įgalioja iššifruotą srautą pasiekti konkretų išteklių. Būtent traktavimas jų kaip vieno nustatymo paverčia siaurą leidimą plačiu. Abi sprendžiamos skirtingose vietose, todėl šią klaidą taip lengva padaryti.

Dvi politikos, vienas tunelis

Išorinė politika atsako į paprastą klausimą: ar paketas iš šio šaltinio gali pasiekti UDP 1194 šiame pagrindiniame kompiuteryje? Vidinė politika atsako į kitą: ar autentifikuotas klientas už to tunelio gali pasiekti šią paskirties vietą, šiuo protokolu, šiuo portu? Pirmoji apie lizdą, antroji apie kelią, ir firewalld modeliuoja jas skirtingais objektais, nes jos sprendžiamos skirtinguose taškuose. Viena yra lizdo šiame kompiuteryje savybė, kita – per jį einančio kelio.

Praktinė pasekmė ta, kad veikiantis tunelis nieko nesako apie antrąją politiką, o teisinga antroji politika nepadaro pirmosios nereikalingos.

Įleiskite tikrąjį išorinį klausytoją

Pradėkite nuo to, kas jau priskirta, o ne nuo prielaidų. Perskaitykite aktyvias zonas, išvardykite zoną, kuri iš tikrųjų neša įeinantį srautą, ir patikrinkite įdiegtą paslaugos apibrėžimą, nes paslaugos pavadinimas apibūdina portų rinkinį ir nieko nesako apie tai, ar šio serverio klausytojas jį atitinka.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

Jei klausytojas tikrai yra UDP 1194 toje zonoje, atidarykite būtent tą portą ir transportą, tada, išbandę, padarykite tą pačią konkrečią taisyklę nuolatinę. Patikrinkite ir priskyrimus pagal šaltinį, nes zona, susieta su šaltinio diapazonu, gali sugauti srautą anksčiau, nei sąsajos zona jį pamatys.

Įgaliokite iššifruotą paskirties vietą atskirai

Ryšys su paslauga, veikiančia pačiame VPN serveryje, yra vietinio įvesties politika. Ryšiui, persiunčiamam į kitą LAN kompiuterį, reikia persiuntimo politikos, branduolyje įgalinto persiuntimo ir grįžimo maršruto — trys atskiri reikalavimai, kuriuos žmonės dažnai sujungia į vieną. Šiuolaikiniai firewalld politikos objektai aprašo nukreiptą srautą tarp įėjimo ir išėjimo zonų, ir būtent ten yra tinkama vieta išreikšti, kurie VPN šaltiniai gali pasiekti kurias privačias paslaugas.

Aiškiai apibrėžkite leidžiamus šaltinius, o visa kita teks atmetimui. Leidimas išorinei paslaugai nėra ta politika, kad ir kaip atrodytų zonų išdėstymas.

Kodėl pasitikėjimas sąsaja yra neteisingas trumpiausias kelias

Tunelio sąsajos įdėjimas į zoną, kurios tikslas priima viską, praleidžia visą iššifruotą srautą į kiekvieną paslaugą, kurią kompiuteris teikia, įskaitant tas, kurių neperžiūrėjote. Patikimos zonos pertvarkymas į ribojančią veikiančioje mašinoje yra dar blogiau, nes kitos sąsajos ir šaltinio diapazonai jau gali priklausyti nuo jos reikšmės ir pakeis elgseną, kai ją redaguosite. Jei jums reikia siauros politikos, sukurkite ją; nepernaudokite bendros zonos.

Taip pat išlaikykite tunelio zonos priskyrimą stabilų per bet kurį komponentą, kuris valdo tą konfigūraciją. Priskyrimo praradimas paleidžiant iš naujo sukelia gedimą, kuris atrodo kaip ugniasienės taisyklės problema, o iš tikrųjų yra patvarumo problema.

Patikrinkite tris dalykus, įskaitant vieną atmetimą

Išbandykite išorinį ryšį iš išorės, išbandykite vieną įgaliotą vidinę paslaugą iš prisijungusio kliento ir išbandykite vieną paslaugą, kuri turėtų likti nepasiekiama. Trečiasis testas yra tas, kuris atskiria politiką nuo šalutinio poveikio, ir būtent jį žmonės praleidžia, nes atrodo, kad viskas veikia. Jei atmesta paslauga atsako, jūs praleidote zoną, o ne paslaugą.

Užrašykite zoną, portą, transportą ir politikos objektą serverio užrašuose. Priešingu atveju kitas šio kompiuterio pakeitimas prasidės nuo tos pačios prielaidos.

Susiję straipsniai