Plány adres, které říkají „tento notebook dostane 10.90.0.10“, jsou ve skutečnosti tvrzení o identitě: které ověřené zařízení smí tuto adresu držet. Aktuální veřejná IP toho zařízení s tím téměř nesouvisí, protože NAT a roaming ji mění, aniž by měnily to, kdo je uživatel. Stavba plánu na zdrojové adrese vytváří pravidla, která se rozbijí na první hotelové síti. Stavba na ověřené identitě vytváří plán, který přežije cestování.

Začněte tím, co server umí ověřit, a potom rozhodněte, k čemu adresa je.

Vyberte klíč identity dřív než adresu

Samostatný klientský certifikát pro každé zařízení dává serveru stabilní, ověřitelný klíč pro každého člena, což je nejčistší základ pro statické přiřazení. Nasazení s ověřováním po uživateli se místo toho může opřít o uživatelské jméno, pokud výběr konfigurace sleduje stejné pole. Míchání obou modelů vytváří přiřazení, která odpovídají certifikátu u jednoho klienta a uživatelskému jménu u jiného, a nikdo nedokáže předpovědět, které vyhraje. Rozhodněte, který klíč plán používá, dřív než napíšete jedinou rezervaci.

S duplicate-cn může několik současných relací předložit stejné společné jméno, takže jedna připnutá adresa je nemůže identifikovat jednotlivě. To je vlastnost modelu identity, nikoli něco, co lepší plán adres napraví.

Rezervujte adresy mimo dynamický rozsah

V síti s topologií podsítě, jako je 10.90.0.0/24, ponechte nízké adresy pro pojmenované členy a dynamický fond umístěte do odděleného rozsahu. Přiřazení pro připnutého člena vypadá takto: ifconfig-push 10.90.0.10 255.255.255.0 v souboru, který server pro danou identitu vybere. Druhý argument znamená pod net30 něco jiného, takže příklad není vůči topologii neutrální. Přečtěte si topologii, než ho zkopírujete.

Perzistence fondu zaznamenává nedávné pronájmy a má tendenci vracet stejnou adresu, což je pohodlí, nikoli rezervace. Nenechte soubor perzistence, aby se stal záznamem vlastnictví, protože se mění s historií připojení, ne s politikou.

Priorita přiřazení rozhoduje, kdo vyhraje

Manuál dokumentuje pořadí: explicitní přiřazení vytvořené během client-connect může nabýt účinnosti před položkou client-config-dir, která sama předchází běžnému přidělení z fondu. Toto pořadí vysvětluje většinu hlášení „připnutá adresa se neprojevila“. Znamená také, že dynamický alokátor, který zapisuje konfiguraci pro každou relaci, může tiše přebít statický soubor, který jste považovali za závazný.

Vyberte jednu vrstvu, která vlastní přiřazení, a ostatní udělejte jen pro čtení. Dvě vrstvy, které obě tvrdí, že rozhodují, vytvářejí přiřazení závislá na časování.

Dynamický alokátor potřebuje stejný model

Integrace client-connect, která rozděluje adresy pro každou relaci, je malý alokátor s obvyklými problémy alokátoru. Musí ověřit žádající identitu, atomicky rezervovat adresu, vydávat pouze podporovaný výstup pro připojení a uvolnit rezervaci při odpojení nebo selhání. Souběžné požadavky potřebují zámek nebo omezení databáze, ne sled čtení a potom zápisu. Bez úklidu fond uniká adresy až do restartu.

Držte stav alokátoru tam, kde si ho další operátor může přečíst, a logujte rozhodnutí identita-adresa, ne jen adresu.

Rozhodněte, zda je adresa politika, nebo pohodlí

Pokud pravidlo firewallu nebo trasa povoluje provoz z jedné adresy tunelu, pak se adresa účastní přístupové politiky a opětovné přiřazení toto oprávnění dědí. Koordinujte životní cyklus identity, adresy a firewallu, nebo pravidlo zavažte na něco, co nelze znovu přiřadit. Stabilní adresování činí konfiguraci čitelnou; nenahrazuje ověřování.

Napište plán jako inventář s vlastníkem u každé položky, a potom ho zkontrolujte, když je zařízení vyřazeno. Nepoužitá rezervace je ta, která se omylem znovu použije.

Související články