Pevná IP adresa VPN: Framed-IP-Address v RADIUS alebo rezervácia v poole

Pevnú vnútornú adresu pre klienta VPN môžu držať tri miesta a iba jedno z nich by ju malo vlastniť. RADIUS môže adresu vrátiť v Access-Accept, brána môže pre účet držať statické mapovanie a adaptér klienta možno nastaviť ručne. Prvé dve sú politika a tretie je miestny odhad, ktorý brána môže ignorovať alebo prepísať. Voľba medzi prvými dvoma je skutočné rozhodnutie a závisí od toho, čo server pre prístup k sieti naozaj implementuje.

Tri miesta, kde môže pevná adresa žiť

RADIUS adresu vlastní, keď odpoveď nesie Framed-IP-Address a brána túto hodnotu použije na reláciu. Brána ju vlastní, keď správca namapuje účet na statickú adresu v poole. Klient nevlastní nič, aj keď jeho adaptér zobrazuje ručnú adresu, pretože server pridelí vnútornú adresu počas vyjednávania a miestne nastavenie má význam len vtedy, keď server nič nepošle. Všetky tri vyzerajú na funkčnom pripojení rovnako, a preto sa konflikty objavujú neskoro. Rozdiel sa ukáže pri opätovnom pripojení, na druhom zariadení a po zmene politiky.

Dvaja vlastníci sú konfigurácia, ktorá sa rozbije. Odpoveď RADIUS prideľuje 172.28.4.77, kým brána drží statické mapovanie pre 172.28.4.90, a výsledkom je hodnota, ktorú kód výrobcu skontroluje prvú; porazený sa zahodí bez riadku v logu. Ten istý účet na druhom zariadení potom dostane duplicitnú adresu a symptóm sa číta ako porucha smerovania, nie ako konflikt pri prideľovaní. Rozhodnite o vlastníkovi, kým pridáte druhý mechanizmus.

Klientsku možnosť stojí za to pomenovať len preto, aby sa dala vylúčiť. Ručná adresa adaptéra je preferencia, ktorú môže operačný systém zobraziť, nie rezervácia, a nemôže zabrániť inej relácii získať rovnakú adresu.

Čo odpoveď RADIUS môže a čo nemôže sľúbiť

RFC 2865definuje Framed-IP-Address ako adresu IPv4, ktorú treba nakonfigurovať pre používateľa, a patrí do Access-Accept. Rovnaký atribút v Access-Request je len nápoveda, ktorú server môže ignorovať, čo je dôležité, keď klient alebo brána ponúka preferovanú adresu. Nič v protokole nenúti bránu odpoveď rešpektovať, pretože server pre prístup k sieti je komponent, ktorý ju aplikuje na reláciu.

Podpora je otázka produktu, nie protokolu. Niektoré brány aplikujú rámované adresy predvolene, iné potrebujú zapnutý prepínač na úrovni skupiny, a ďalšie atribút prijmú a nikdy ho nepoužijú na relácie vzdialeného prístupu. Posledný prípad je nebezpečný, pretože účtovný záznam môže ukazovať odpoveď, kým klient dostáva adresu z poolu. Overte správanie na presnom modeli brány a firmware, ktorý používate, nie v dokumentácii sesterského produktu.

Odpoveď, ktorú brána ignoruje, vyzerá presne ako odpoveď, ktorá nikdy nebola odoslaná. Čítanie Access-Accept a adresy relácie vedľa seba je jediný spôsob, ako oba prípady oddeliť.

Rezervujte adresu v poole, ktorý už smerujete

Vyberte pevnú adresu z podsiete poolu, ktorú brána už smeruje a ktorej firewall už dôveruje. Adresa mimo tohto rozsahu premení zmenu politiky na projekt smerovania a VPN naskočí, kým nič za ňou nebude môcť odpovedať. Ak existujú pravidlá prístupu podľa adresy, pridajte pevnú adresu do nich v tej istej zmene.

Rozhodnite, čo má robiť druhá súbežná relácia. Prideľovanie jednej adresy dvakrát nie je správa zariadení a výsledná kolízia sa prejaví ako prerušované pripojenie pre obe relácie. Buď vydávajte odlišné identity pre každé zariadenie, alebo odlišné pridelenia, alebo vynúťte súbežnosť podporovanou kontrolou, napríklad Simultaneous-Use, namiesto toho, aby ste dúfali, že sa klient nikdy nepripojí znova pred vypršaním starej relácie.

Spätné trasy si zaslúžia rovnakú pozornosť ako pridelenie. Brána potrebuje trasu do poolu, vnútorné smerovače potrebujú trasu späť k bráne a pevná adresa dedí obe. Jeden klient, ktorý funguje, kým všetci ostatní zlyhávajú, zvyčajne znamená, že trasa do poolu existuje, ale trasa k hostiteľovi pre rezervovanú adresu nie.

Otestujte odpoveď, kým rezervácii uveríte

Testujte stranu AAA a stranu relácie oddelene, pretože zlyhávajú z rôznych dôvodov. Miestny radtest ukazuje, čo server pre účet vracia bez zapojenia brány, a záznam v súbore používateľov ukazuje, s čím má server súhlasiť. Potom klienta znova pripojte a porovnajte adresu, ktorú dostal, s atribútom v odpovedi.

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 atribútu znamená, že server záznam nezhodol alebo atribút nebol na tohto používateľa aplikovaný. Access-Accept s atribútom a klient, ktorý stále dostáva adresu z poolu, znamenajú, že ho brána ignorovala. Access-Reject vás vráti k prihlasovacím údajom alebo skupinovej politike a žiadny z týchto výsledkov by sa nemal ladiť úpravou adaptéra klienta.

Kontrolu zopakujte po opätovnom pripojení a po druhom prihlásení z iného zariadenia. Rezervácia, ktorá vydrží len prvú reláciu, je konflikt v poole, ktorý čaká na príležitosť, a je lacnejšie nájsť ho teraz než počas auditu.

Vyberte jedného vlastníka a zapíšte ho

Ak brána rámované adresy aplikuje spoľahlivo, nechajte pridelenie vlastniť RADIUS a odstráňte akékoľvek statické mapovanie pre rovnaký účet. Ak nie, nechajte ho vlastniť bránu a odstráňte atribút z odpovede, aby sa oba zdroje nemohli rozísť. Ponechanie oboch, pretože každý takmer funguje, zaručuje budúcu reláciu s nesprávnou adresou a bez zjavnej príčiny.

Zapíšte zvoleného vlastníka, rezervovanú adresu a pool, z ktorého pochádza, do záznamu účtu. Ďalší človek, ktorý pridá zariadenie, potom uvidí, či je adresa politikou AAA alebo mapovaním na bráne, kým ktorúkoľvek z nich zmení.