Pevná IP adresa VPN: Framed-IP-Address v RADIUS, nebo rezervace v poolu

Dejte klientovi VPN pevnou vnitřní adresu: Framed-IP-Address v RADIUS versus mapování v poolu na bráně a jak otestovat, která z nich rezervaci skutečně vlastní.

Pevnou vnitřní adresu pro klienta VPN mohou držet tři místa a jen jedno z nich by ji mělo vlastnit. RADIUS může adresu vrátit v Access-Accept, brána může pro účet držet statické mapování a adaptér klienta lze nastavit ručně. První dvě jsou politika a třetí je místní odhad, který brána může ignorovat nebo přepsat. Volba mezi prvními dvěma je skutečné rozhodnutí a závisí na tom, co server pro přístup k síti opravdu implementuje.

Tři místa, kde může pevná adresa žít

RADIUS adresu vlastní, když odpověď nese Framed-IP-Address a brána tuto hodnotu použije na relaci. Brána ji vlastní, když správce namapuje účet na statickou adresu uvnitř poolu. Klient nevlastní nic, i když jeho adaptér zobrazuje ruční adresu, protože server přiděluje vnitřní adresu během vyjednávání a místní nastavení má význam jen tehdy, když server nic nepošle. Všechna tři vypadají na funkčním připojení stejně, a proto se konflikty objevují pozdě. Rozdíl se ukáže při opětovném připojení, na druhém zařízení a po změně politiky.

Dva vlastníci jsou konfigurace, která se rozbije. Odpověď RADIUS přiděluje 172.28.4.77, zatímco brána drží statické mapování pro 172.28.4.90, a výsledkem je hodnota, kterou kód výrobce zkontroluje první; poražený se zahodí bez řádku v logu. Stejný účet na druhém zařízení pak dostane duplicitní adresu a symptom se čte jako porucha směrování, nikoli jako konflikt při přidělování. Rozhodněte o vlastníkovi, než přidáte druhý mechanismus.

Klientskou možnost stojí za to pojmenovat jen proto, aby ji bylo možné vyloučit. Ruční adresa adaptéru je preference, kterou operační systém může zobrazit, ne rezervace, a nemůže zabránit jiné relaci získat stejnou adresu.

Co odpověď RADIUS může a co nemůže slíbit

RFC 2865definuje Framed-IP-Address jako adresu IPv4, kterou je třeba pro uživatele nakonfigurovat, a patří do Access-Accept. Stejný atribut v Access-Request je jen nápověda, kterou server může ignorovat, což je důležité, když klient nebo brána nabídne preferovanou adresu. Nic v protokolu nenutí bránu odpověď respektovat, protože server pro přístup k síti je komponenta, která ji na relaci aplikuje.

Podpora je otázka produktu, nikoli protokolu. Některé brány aplikují rámované adresy ve výchozím nastavení, jiné potřebují zapnutý přepínač na úrovni skupiny, a další atribut přijmou a nikdy ho pro relace vzdáleného přístupu nepoužijí. Poslední případ je nebezpečný, protože účetní záznam může ukazovat odpověď, zatímco klient dostává adresu z poolu. Ověřte chování na přesném modelu brány a firmwaru, který používáte, ne v dokumentaci sesterského produktu.

Odpověď, kterou brána ignoruje, vypadá přesně jako odpověď, která nebyla nikdy odeslána. Čtení Access-Accept a adresy relace vedle sebe je jediný způsob, jak oba případy oddělit.

Rezervujte adresu uvnitř poolu, který už směrujete

Vyberte pevnou adresu z podsítě poolu, kterou brána už směruje a které firewall už důvěřuje. Adresa mimo tento rozsah promění změnu politiky v projekt směrování a VPN naskočí, zatímco nic za ní nebude moci odpovědět. Pokud existují pravidla přístupu podle adres, přidejte pevnou adresu do nich ve stejné změně.

Rozhodněte, co má dělat druhá souběžná relace. Přidělení jedné adresy dvakrát není správa zařízení a vzniklá kolize se projeví jako přerušované připojení u obou relací. Buď vydávejte odlišné identity pro každé zařízení, nebo odlišná přidělení, nebo vynuťte souběžnost podporovanou kontrolou, například Simultaneous-Use, místo abyste doufali, že se klient nikdy nepřipojí znovu před vypršením staré relace.

Zpětné trasy si zaslouží stejnou pozornost jako přidělení. Brána potřebuje trasu do poolu, vnitřní směrovače potřebují trasu zpět k bráně a pevná adresa dědí obě. Jeden klient, který funguje, zatímco všichni ostatní selhávají, obvykle znamená, že trasa do poolu existuje, ale trasa k hostiteli pro rezervovanou adresu ne.

Otestujte odpověď, než rezervaci uvěříte

Testujte stranu AAA a stranu relace odděleně, protože selhávají z různých důvodů. Místní radtest ukazuje, co server pro účet vrací, aniž by zapojil bránu, a záznam v souboru uživatelů ukazuje, s čím má server souhlasit. Potom klienta znovu připojte a porovnejte adresu, kterou dostal, s atributem v odpovědi.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77
survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

Access-Accept bez atributu znamená, že server záznam nespároval nebo atribut nebyl na tohoto uživatele aplikován. Access-Accept s atributem a klient, který stále dostává adresu z poolu, znamená, že ho brána ignorovala. Access-Reject vás vrátí k přihlašovacím údajům nebo skupinové politice a žádný z těchto výsledků by se neměl ladit úpravou adaptéru klienta.

Kontrolu zopakujte po opětovném připojení a po druhém přihlášení z jiného zařízení. Rezervace, která vydrží jen první relaci, je konflikt v poolu, který čeká na příležitost, a je levnější najít ho teď než během auditu.

Vyberte jednoho vlastníka a zapište ho

Pokud brána rámované adresy aplikuje spolehlivě, nechte přidělení vlastnit RADIUS a odstraňte jakékoli statické mapování pro stejný účet. Pokud ne, nechte ho vlastnit bránu a odstraňte atribut z odpovědi, aby se oba zdroje nemohly rozejít. Ponechání obou, protože každý skoro funguje, zaručuje budoucí relaci se špatnou adresou a bez zjevné příčiny.

Zapište zvoleného vlastníka, rezervovanou adresu a pool, ze kterého pochází, do záznamu účtu. Další člověk, který přidá zařízení, pak uvidí, zda je adresa politikou AAA, nebo mapováním na bráně, než změní kteroukoli z nich.

Související články