Cloudový firewall versus firewall hostitele pro VPN server

Povolte port VPN v cloudové politice a handshake přesto může na instanci selhat: host má vlastní filtr i vlastní navázání naslouchače a kterékoliv z nich může zahodit to, co cloud povolil. Stává se to i obráceně, když pravidlo hostitele port povolí a politika výš ho zahodí dřív. Dva vlastníci, dvě sady pravidel, jedna cesta paketu. Projděte ji popořadě, místo abyste hádali na nejpodezřelejší vrstvě.

Začněte na okraji a jděte dovnitř

Pořadí je pevné: veřejný koncový bod, rozhraní prostředku, připojená cloudová politika, adresa hosta, naslouchač procesu, místní vstupní pravidla. Každá fáze paket buď propustí, nebo vyšetřování ukončí, a proto začátek na hostu ztrácí nejvíc času.

Přesměrovaný klientský provoz je samostatná fáze, která se zkoumá po dekapsulaci tunelu. Cloudová vrstva vidí jen vnější tunel, takže může spojení povolit a přitom nemít nic společného s požadavkem na vnitřní službu. Tunel, který se spojí, ale nedosáhne na vnitřního hosta, obvykle ukazuje na přesměrování, ne na zavřený port.

Přečtěte si cloudovou politiku, než se dotknete hosta

Ověřte vstupní pravidlo pro port VPN, jeho protokol a rozsah zdrojů, který odpovídá vašemu testovacímu klientovi. Zkontrolujte i seznam řízení přístupu podsítě: druhý filtr s vlastními pravidly a výchozími hodnotami. Oba musí tok povolit, než paket dorazí na instanci. Povolení v jednom a zamítnutí v druhém je obvyklá podoba této chyby.

Zužujte rozsah, dokud něco neznamená. Otevřít port VPN celému internetu je snadné dokázat a těžké obhájit, kdežto pravidlo připíchnuté k jedné adrese se rozbije, když testovací klient přejde do jiné sítě. Poznamenejte si identifikátor pravidla a vlastníka politiky, aby příští změna byla dohledatelná ke konkrétnímu člověku.

Ověřte naslouchač, potom vstupní řetěz

Na instanci zkontrolujte, že proces VPN je navázán na adresu a port, které očekáváte, třeba pomocí ss -lntp 'sport = :1194'. Démon navázaný jen na 127.0.0.1 přijímá místní klienty a nic přes tunel, což zvenčí vypadá přesně jako filtrovaný port.

Pak si přečtěte místní pravidla v syntaxi, kterou byste použili k jejich změně, například iptables -S INPUT nebo nft list chain inet filter input. Pravidlo zapsané do souboru, ale nikdy nenačtené, nebo výchozí zahazování bez odpovídajícího povolení zahazuje pakety potichu. U brány, která přesměrovává, zkontrolujte i nastavení přesměrování a zpětné cesty. Ta rozhodují, co se stane s pakety směrovanými přes instanci, a ne adresovanými na ni.

Stav v jedné vrstvě, bez stavu v další

Bezpečnostní skupiny si pamatují toky, které povolily, a pouštějí odpovědi zpět. Seznamy řízení přístupu podsítí a mnohé firewally hostitele takový stav nevedou, takže pravidlo pokrývající jen odchozí směr požadavek propustí a odpověď zahodí. Nikdy nepřenášejte předpoklad o zpětném provozu mezi vrstvami, aniž byste si přečetli pravidlo druhé vrstvy (second layer's rule).

Počítadla to vyřeší rychleji než čtení každého pravidla v účtu. Počítadlo, které roste, znamená, že paket dorazil a byl tam zahozen, zatímco to zamrzlé na nule znamená, že tam nikdy nedošel; iptables -vnL INPUT a nft list ruleset ukazují tyto počty, když byla pravidla načtena s počítadly.

Testujte čerstvou relací, ne živou

Nechte zdrojovou síť i testovací profil být, když porovnáváte pohledy, a po každé změně otevřete nové spojení. Dosažení webové konzole na 443 nic neříká o tom, zda je démon VPN navázán na 1194, takže testujte port, který potřebujete. Stávající relace je tu nejhorší svědek. Funguje dál, zatímco každé nové přihlášení je odmítnuto.

Než začnete upravovat vzdálenou politiku, zajistěte si cestu zpět, která nezávisí na cestě, kterou měníte. Pak otevřete druhou administrativní relaci vedle testu VPN: dřív navázaná relace může přežít pravidlo, které blokuje nové. Zapište si vlastníky obou politik, aby žádná obnova nevrátila polovinu cesty; pokud obě vrstvy souhlasí a tunel přesto selhává, zachyťte provoz na rozhraní hosta a ověřte adresu a port, které klient skutečně používá.