Стабилен адрес на VPN клиент чрез Framed-IP-Address в RADIUS
Стабилният VPN адрес изисква RADIUS и шлюз, който зачита атрибута. Проверете приоритета и сравнете отговора с адреса на тунела.
RADIUS може да отговори с адрес за даден потребител; дали тунелът действително ще го получи, зависи от шлюза. Точно в тази разлика между върнат и приложен се провалят повечето планове за стабилни адреси. Атрибут в тестов отговор доказва, че сървърът може да го изпрати, а не че услугата за отдалечен достъп го прилага. Последователността по-долу проверява и двете половини, преди адресът да попадне в правилата на защитната стена.
Определете кой слой притежава адреса
Шлюзовете за отдалечен достъп обикновено имат локален пул и мнозина могат да приемат адрес и от отговора за удостоверяване. Кой ще надделее зависи от платформата, протокола и конфигурацията на услугата, затова прочетете правилото за приоритет за точната версия в употреба. Когато локалният пул има предимство, атрибутът е украшение и клиентът все пак получава случаен адрес. Запишете решението, включително дали върнатата стойност трябва да е в обхвата на пула или може да е извън него.
RFC 2865 дефинира Framed-IP-Address като адреса, който да бъде конфигуриран за потребителя, и не казва нищо за готовността на който и да е шлюз да го зачита. Документацията на доставчика е авторитетът за приоритета, а не дефиницията на атрибута.
Изпратете тестова заявка и прочетете отговора
Тествайте сървъра първо изолирано, за да не бъде липсващ атрибут сбъркан с проблем на шлюза. radtest изпраща един Access-Request и отпечатва атрибутите, които се връщат.
radtest alice 'S3cret' 127.0.0.1 0 testing123Търсете Framed-IP-Address в Access-Accept и потвърдете, че стойността е желаната, а не адрес от пула по резервно правило. Когато атрибутът липсва, записът на потребителя или политиката за оторизация не съвпадат и настройката на шлюза не може да даде това, което сървърът никога не е изпратил. Повторете заявката, докато сървърът работи в режим на отстраняване на грешки, ако отговорът трудно се проследява до конкретно правило. Дръжте споделената тайна извън историята на обвивката и билетите, защото заместителят по-горе не е удостоверение.
Потвърдете, че шлюзът е зачел стойността
Правилният отговор е само половината от договора. Адресът, който се появява на интерфейса на тунела, е наблюдението, което има значение, и се чете на клиента, а не се извежда от конфигурацията на шлюза.
ip -4 addr show tun0Сравнете този адрес с атрибута от Access-Accept. Несъответствието означава, че шлюзът е игнорирал или преписал стойността, което отново повдига въпроса за приоритета от първия раздел. Свържете се още веднъж, защото резервация, която работи само при първия опит, обикновено сочи към остаряла сесия или наем, който предишната връзка още държи. Запишете версията на шлюза и протокола до резултата, за да може следващият човек да прецени дали поведението е специфично за версията.
Планирайте паралелност и отнемане
Едно потребителско име на две устройства не може да се съпостави с един адрес, освен ако шлюзът не различава сесиите по нещо извън влизането. Решете дали съпоставянето принадлежи на човек, на регистрирано устройство или на идентичност на сертификат, и направете този избор явен в хранилището на политики. Тествайте втори едновременен клиент и сравнете двата зададени адреса, защото сблъсък тук по-късно се връща като грешка в маршрутизацията. Същата грижа е нужна и в плана за отнемане, защото адрес, преразпределен, докато стари правила на защитната стена още го сочат, се превръща в грешка в оторизацията.
Стабилната адресация опростява правилата и журналите, но никога не доказва кой е генерирал пакета. Удостоверяването и оторизацията на дестинацията все още имат значение, когато този адрес по-късно премине към друга сесия.