Statické adresy tunelu v pfSense: preference, nebo rezervace?

Dva návrhy vypadají na papíře podobně a chovají se velmi odlišně, jakmile na nich závisí nějaké pravidlo. Jeden zadá adresu do přepsání klienta a věří adrese jako identitě. Druhý zcela uzavře dynamické přijímání, takže koncový bod má buď jedinečné přiřazení, nebo se nepřipojí. Jen druhý mění adresu v podklad politiky, který můžete obhájit, a rozdíl stojí za pochopení dřív, než napíšete jediné pravidlo firewallu.

Co adresa přepsání skutečně slibuje

Přepsání specifické pro klienta nese možnosti pro jednotlivé klienty, včetně preferované adresy tunelu. Netgate popisuje tuto adresu jako preferenci, nikoli rezervaci, což znamená, že dynamický fond se adresy pro nikoho jiného nevzdává.

To obvykle stačí. Kolize je vzácná a klient obvykle dostane, o co požádal, což stačí pro pohodlí a nestačí pro autorizaci. Pohodlí a autorizace jsou různé požadavky a kolizi přežije jen jeden z nich.

U topologie podsítě pole přebírá adresu klienta spolu s maskou sítě serveru, takže adresa uvnitř tunelu 10.90.0.0/24 se zapisuje jako 10.90.0.10/24.

Nic z toho číslo nerezervuje. Klient, jehož přepsání neodpovídá, nebo duplicitní relace může skončit jinde ve fondu a pravidlo vázané na adresu pak popisuje někoho, kdo tam není.

Uzavřete dynamickou cestu omezenou výchozí hodnotou

Alternativou je výhradně statický server: každý přijatý koncový bod má vlastní identitu a vlastní jedinečnou adresu a nic jiného dovnitř neprojde.

Implementace znamená přepsání DEFAULT omezené na tento jediný server se zapnutým blokováním připojení. Klient bez odpovídajícího přepsání pak nemůže spadnout zpět na běžné dynamické přijímání. Právě tento jediný řádek mění preferenci v uzavřenou množinu.

Rozsah je důležitý. Výchozí přepsání použité na každou instanci VPN na zařízení uzamkne nesouvisející tunely a tato porucha vypadá jako rozbitá služba, nikoli jako rozhodnutí politiky. Přiřaďte je k jedinému serveru, jehož model přijímání měníte. Potom rozsah poznamenejte do záznamu změn, protože další člověk si nebude pamatovat, ke kterému tunelu patří.

Poté zkontrolujte celou povolenou množinu. Výchozí blokování neopraví pojmenované přepsání ponechané bez adresy a tento koncový bod se prostě nepřipojí bez zjevného náznaku proč.

Párujte identitu, kterou server skutečně používá

Přepsání na něco odpovídá. Na serveru, který páruje běžné názvy certifikátů, musí být název přepsání tímto běžným názvem, nikoli zobrazovaným jménem osoby. Zkopírujte jej z certifikátu, ne ze seznamu účtů.

Server nakonfigurovaný tak, aby používal uživatelské jméno jako běžný název, páruje zcela jiný klíč a přepsání pojmenované podle certifikátu se nikdy nespustí. Přečtěte si nastavení, místo abyste je odvozovali z toho, co ukazuje seznam účtů.

Zachovejte dodatečné autentizační faktory, které nasazení vyžaduje. Uzavřený model adres mění, kdo se smí připojit a jakou adresu dostane; nenahrazuje kontrolu certifikátu ani druhý faktor.

Napište pravidla přístupu, až bude mapa v pořádku

Jakmile je mapa identity na adresu uzavřená, pravidla mohou odkazovat na adresy, aniž by předstírala, že jde o osoby. Alias seskupující koncové body jedné osoby může dosáhnout konkrétní služby, zatímco jiný alias dosáhne něčeho jiného. Alias se stává revidovatelným objektem a adresa se uvnitř něj stává implementačním detailem.

Udržujte cíle a porty explicitní. Povolit celou místní síť z celého fondu tunelů je přesně ten návrh, který mělo toto cvičení nahradit.

Čtěte plovoucí, skupinová a rozhranová pravidla v jejich skutečném pořadí vyhodnocování, protože dřívější široký průchod přebíjí pozdější úzký. Vypnutí interního předávání mezi klienty udržuje provoz mezi peers na hranici, kde se tato pravidla revidují. Pravidlo, které existuje jen na papíře, není vymáhání.

Otestujte negativní případy

Vyzkoušejte čtyři nová připojení: pojmenovaný koncový bod, jeden zcela bez přepsání, službu, která by měla být dostupná, a jednu, která by neměla. Nezařazený koncový bod je důležitý případ, protože právě ten má návrh zastavit. Pokud se připojí, výchozí blokování nedělá svou práci.

Zkontrolujte IPv6 samostatně, protože politika adres IPv4 nic neříká o druhém zásobníku. Potom potvrďte, že aplikace stále autorizuje uživatele, protože adresa tunelu je síťový fakt, nikoli důkaz o tom, kdo sedí u klávesnice. Obě kontroly patří do poznámky k převzetí.

Nakonec naplánujte migraci. Nová přepsání a úzká pravidla nemění zpětně již navázané relace, takže stávající stavy musí vypršet nebo být záměrně vymazány.