VPN tarp vietovių: kuri kryptis iš tikrųjų reikalauja taisyklės?

Abu galai praneša apie nustatytą tunelį, tolimas filialas atsako iš šliuzo, o programa vis tiek viršija laiką vienos pusės naudotojams. Įprastas patarimas – pridėti ugniasienės taisyklę abiem kryptimis. Kartais tai teisinga, kartais dubliuoja jau egzistuojančią taisyklę, o kartais būtent antroji taisyklė sugadina būseną. Kuris atvejis galioja, priklauso nuo to, kur ugniasienė mato paketą.

Būsenos grįžtamasis srautas keičia skaičių

Būsenos ugniasienė įrašo užklausą ir praleidžia atsakymą be antros taisyklės, todėl dizainas, kuriam reikia tik vienos taisyklės, yra normalus. Būsenos neturintis prieigos sąrašas neturi tokios atminties, ir atsakymui turi būti aiškiai leista. Abu variantai teisingi savo platformoje, todėl patarimai prieštarauja vienas kitam.

Perskaitykite priešais esančios platformos perdavimo dokumentaciją ir patikrinkite, ar redaguojama politika yra būsenos ten, kur ji mato paketą. Aiškus draudimas nustatytam srautui arba taisyklių tvarka, kuri vertina atsakymą prieš būsenos lentelę, paverčia veikiantį dizainą mįslingu. Taisyklių skaičius yra įgyvendinimo detalė, o reikalavimas – kad abi leistos konversacijos kryptys galėtų būti užbaigtos.

Kur ugniasienė mato iššifruotus paketus

Politika pagrįstame tunele ugniasienė gali vertinti užšifruotą paketą prieš iššifravimą ir iššifruotą paketą po jo, skirtinguose sąsajuose. Taisyklė, parašyta netinkamai sąsajai, egzistuoja, yra teisinga ir niekada nesutampa. Taip iš veikiančios diegties nukopijuotas taisyklių rinkinys gali sugesti identiškoje techninėje įrangoje.

Maršrutu pagrįstas IPsec ir dauguma šiuolaikinių diegimų pateikia tunelio sąsają, todėl iššifruotas paketas patenka ten ir galioja įprastos sąsajos taisyklės. Patvirtinkite, kurį modelį naudoja diegtis, prieš kopijuodami taisyklių rinkinį iš vadovo, parašyto kitam. Tunelio sąsaja taip pat yra vieta, į kurią žiūrima, kai reikia sužinoti, ar paketas apskritai buvo iššifruotas.

Asimetrinis maršrutizavimas sugriauna prielaidą

Būsenos ugniasienė daro prielaidą, kad mato abi pokalbio puses. Jei atsakymas grįžta per kitą šliuzą, tas įrenginys neturi užklausos būsenos ir numeta ją pagal savo politiką. Simptomas – vienpusis gedimas, kurio jokia taisyklė siuntėjo pusėje negali ištaisyti. Atsekite atsakymo kelią prieš ką nors redaguodami.

Patikrinkite atsakymo maršrutą prieš pridėdami plačią leidimo taisyklę abiejose pusėse. Visko toleravimas kiekvienoje sąsajoje paslepia maršrutizavimo klaidą ir tuo pačiu išplečia prieigą, o tai yra blogiausias įmanomas derinys.

Patikrinkite abi kryptis su tikrais šaltinio adresais

Bandykite su adresu, kurį tolimoji pusė iš tikrųjų mato, nes vertimas gali padaryti taip, kad šaltinio taisyklė nieko neatitiks. Vykdykite fiksavimą abiejuose šliuzuose vienu metu.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Užklausa, kuri tolimajame šliuze pasirodo su netikėtu šaltinio adresu, paaiškina taisyklę, kuri niekada nesutampa, o atsakymas, atkeliaujantis į netinkamą sąsają, paaiškina būsenos neatitikimą. Tada išbandykite vieną paskirties vietą patvirtintoje apimtyje ir vieną už jos ribų, kad riba būtų parodyta, o ne numanoma.

Užsirašykite šaltinio adresą po vertimo, sąsają, kurią naudojo iššifruotas paketas, ir taisyklę, kuri sutapo. Šie trys faktai atsako į kitą bilietą nekartojant viso tyrimo.