VPN medzi lokalitami: ktorý smer naozaj potrebuje pravidlo?

Oba konce hlásia nadviazaný tunel, vzdialená pobočka odpovedá z brány a aplikácia napriek tomu vyprší používateľom na jednej strane. Zvyčajná rada hovorí pridať pravidlo firewallu v oboch smeroch. Niekedy je to správne, niekedy duplikuje už existujúce pravidlo a niekedy práve druhé pravidlo pokazí stav. Ktorý prípad platí, závisí od toho, kde firewall vidí paket.

Stavová návratová prevádzka mení počet

Stavový firewall zaznamená požiadavku a prepustí odpoveď bez druhého pravidla, takže návrh, ktorému stačí jedno pravidlo, je normálny. Bezstavový access list takú pamäť nemá a odpoveď musí byť povolená výslovne. Obe sú správne na svojej platforme, a preto si rady odporujú.

Prečítajte si dokumentáciu k preposielaniu pre platformu pred sebou a skontrolujte, či je politika, ktorú upravujete, stavová tam, kde vidí paket. Výslovné zamietnutie nadviazanej prevádzky alebo poradie pravidiel, ktoré vyhodnocuje odpoveď pred tabuľkou stavov, mení funkčný návrh na záhadný. Počet pravidiel je implementačný detail, kým požiadavkou je, aby sa oba smery povolenej konverzácie mohli dokončiť.

Kde firewall vidí dešifrované pakety

V tuneli založenom na politikách môže firewall vyhodnotiť šifrovaný paket pred dešifrovaním a dešifrovaný paket potom, na rôznych rozhraniach. Pravidlo napísané pre nesprávne rozhranie je prítomné, správne a nikdy sa nezhoduje. Tak môže sada pravidiel skopírovaná z funkčného nasadenia zlyhať na identickom hardvéri.

IPsec založený na smerovaní a väčšina moderných implementácií poskytujú tunelové rozhranie, takže dešifrovaný paket prichádza tam a platia bežné pravidlá rozhrania. Potvrďte, ktorý model nasadenie používa, než skopírujete sadu pravidiel z príručky napísanej pre ten druhý. Tunelové rozhranie je aj miesto, kam sa pozrieť, keď potrebujete vedieť, či bol paket vôbec dešifrovaný.

Asymetrické smerovanie búra predpoklad

Stavový firewall predpokladá, že vidí obe polovice konverzácie. Ak sa odpoveď vráti cez inú bránu, toto zariadenie nemá pre požiadavku stav a zahodí ju podľa vlastnej politiky. Príznakom je jednosmerné zlyhanie, ktoré žiadne pravidlo na strane odosielateľa nenapraví. Vystopujte cestu odpovede než čokoľvek upravíte.

Skontrolujte trasu odpovede, než na oboch stranách pridáte široké povoľovacie pravidlo. Tolerovanie všetkého na každom rozhraní skrýva chybu smerovania a zároveň rozširuje prístup, čo je najhoršia dostupná kombinácia.

Overte oba smery so skutočnými zdrojovými adresami

Testujte s adresou, ktorú vzdialená strana skutočne vidí, pretože preklad môže spôsobiť, že zdrojové pravidlo nebude zodpovedať ničomu. Spustite zachytávanie na oboch bránach súčasne.

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

Požiadavka, ktorá sa na vzdialenej bráne objaví s neočakávanou zdrojovou adresou, vysvetľuje pravidlo, ktoré sa nikdy nezhoduje, a odpoveď prichádzajúca na nesprávne rozhranie vysvetľuje nesúlad stavu. Potom otestujte jeden cieľ v schválenom rozsahu a jeden mimo neho, aby bola hranica predvedená, nie predpokladaná.

Zaznamenajte zdrojovú adresu po preklade, rozhranie, ktoré dešifrovaný paket použil, a pravidlo, ktoré sa zhodovalo. Tieto tri fakty odpovedajú na ďalší tiket bez opakovania celého vyšetrovania.