Фиксиран VPN IP: Framed-IP-Address в RADIUS или резервация в пула
Дайте на VPN клиент фиксиран вътрешен адрес: Framed-IP-Address в RADIUS срещу съответствие в пула на шлюза и как да проверите кой всъщност притежава резервацията.
Три места могат да държат фиксиран вътрешен адрес за VPN клиент и само едно от тях трябва да го притежава. RADIUS може да върне адреса в Access-Accept, шлюзът може да поддържа статично съответствие за акаунта, а клиентският адаптер може да се зададе ръчно. Първите две са политика, а третото е локално предположение, което шлюзът е свободен да игнорира или презапише. Изборът между първите две е истинското решение и зависи от това какво реално реализира сървърът за мрежов достъп.
Три места, където може да живее фиксиран адрес
RADIUS притежава адреса, когато отговорът носи Framed-IP-Address и шлюзът прилага тази стойност към сесията. Шлюзът го притежава, когато администратор съпостави акаунта със статичен адрес в пула. Клиентът не притежава нищо, дори когато адаптерът му показва ръчен адрес, защото сървърът задава вътрешния адрес по време на договарянето и локална настройка има значение само когато сървърът не изпрати нищо. И трите изглеждат еднакво при работеща връзка и затова конфликтите изплуват късно. Разликата се вижда при повторно свързване, на второ устройство и след промяна в политиката.
Двама собственици е конфигурацията, която се чупи. Отговор на RADIUS, който задава 172.28.4.77, докато шлюзът държи статично съответствие за 172.28.4.90, връща стойността, която кодът на доставчика проверява първа, а губещият се изхвърля без ред в журнала. Същият акаунт на второ устройство след това получава дублиран адрес и симптомът изглежда като маршрутизиращ дефект, а не като конфликт при назначаването. Решете собственика, преди да добавите втория механизъм.
Клиентската опция заслужава да се назове само за да бъде изключена. Ръчният адрес на адаптера е предпочитание, което операционната система може да покаже, а не резервация, и не може да попречи на друга сесия да получи същия адрес.
Какво може и какво не може да обещае отговорът на RADIUS
RFC 2865дефинира Framed-IP-Address като адреса IPv4, който да се конфигурира за потребителя, и той принадлежи в Access-Accept. Същият атрибут в Access-Request е само подсказка, която сървърът може да игнорира, което има значение, когато клиент или шлюз предлага предпочитан адрес. Нищо в протокола не задължава шлюза да зачита отговора, защото сървърът за мрежов достъп е компонентът, който го прилага към сесията.
Поддръжката е въпрос на продукт, а не на протокол. Някои шлюзове прилагат рамкирани адреси по подразбиране, други се нуждаят от включен превключвател на групово ниво, а трети приемат атрибута и никога не го използват за сесии за отдалечен достъп. Последният случай е опасният, защото отчетът за отчитане може да показва отговора, докато клиентът получава адрес от пула. Потвърдете поведението на точния модел шлюз и фърмуер, които използвате, а не в документацията за сроден продукт.
Отговор, който шлюзът игнорира, изглежда точно като отговор, който никога не е бил изпратен. Четенето на Access-Accept и адреса на сесията едно до друго е единственият начин да се разделят двата случая.
Резервирайте адреса в пула, който вече маршрутизирате
Изберете фиксирания адрес от подмрежата на пула, която шлюзът вече маршрутизира и на която защитната стена вече има доверие. Адрес извън този диапазон превръща промяна в политиката в проект за маршрутизация и VPN ще се вдигне, докато нищо зад него не може да отговори. Ако има правила за достъп по адреси, добавете фиксирания адрес към тях в същата промяна.
Решете какво трябва да прави втора едновременна сесия. Задаването на един адрес два пъти не е управление на устройства и полученият сблъсък се появява като прекъсваща връзка за двете сесии. Или издавайте отделни идентичности за всяко устройство, или отделни назначения, или налагайте едновременност с поддържана проверка, например Simultaneous-Use, вместо да се надявате клиентът никога да не се свърже отново преди старата сесия да изтече.
Обратните маршрути заслужават същото внимание като назначението. Шлюзът се нуждае от маршрут до пула, вътрешните маршрутизатори се нуждаят от маршрут обратно до шлюза и фиксираният адрес наследява и двата. Един клиент, който работи, докато всички останали се провалят, обикновено означава, че маршрутът до пула съществува, но маршрутът до хоста за резервирания адрес не.
Тествайте отговора, преди да се доверите на резервацията
Тествайте страната на AAA и страната на сесията отделно, защото те се провалят по различни причини. Локален radtest показва какво връща сървърът за акаунта, без да включва шлюза, а записът във файла на потребителите показва с какво сървърът трябва да съвпадне. След това свържете клиента отново и сравнете получения адрес с атрибута в отговора.
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 без атрибута означава, че сървърът не е съпоставил записа или атрибутът не е приложен към този потребител. Access-Accept с атрибута и клиент, който все още получава адрес от пула, означава, че шлюзът го е игнорирал. Access-Reject ви връща към идентификационните данни или груповата политика и нито един от тези резултати не бива да се отстранява чрез редактиране на клиентския адаптер.
Повторете проверката след повторно свързване и след второ влизане от друго устройство. Резервация, която се задържа само за първата сесия, е конфликт в пула, който чака да се случи, и е по-евтино да се намери сега, отколкото по време на одит.
Изберете един собственик и го запишете
Ако шлюзът прилага рамкирани адреси надеждно, оставете RADIUS да притежава назначението и премахнете всяко статично съответствие за същия акаунт. Ако не, оставете шлюза да го притежава и премахнете атрибута от отговора, така че двата източника да не могат да се разминават. Задържането и на двете, защото всяко почти работи, гарантира бъдеща сесия с грешен адрес и без очевидна причина.
Запишете избрания собственик, резервирания адрес и пула, от който идва, в записа на акаунта. Следващият човек, който добавя устройство, ще може да види дали адресът е политика на AAA или съответствие в шлюза, преди да промени което и да е от двете.