Фіксаваны VPN IP: 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, ці мапінг на шлюзе, перш чым змяняць любое з іх.