EAP праз VPN-шлюз: хто завяршае метад

Заяўкі ў падтрымку апісваюць няўдалы ўваход у VPN і палітыку RADIUS, якая патрабуе больш моцнага метаду, быццам гэта адна і тая ж праблема, але гэта не так. Шлюз або прымае ўліковыя даныя і перадае іх, або вядзе размову EAP паміж кліентам і серверам аўтэнтыфікацыі. Тое, што з гэтага адбываецца, вызначае, ці зможа змена на баку сервера наогул нешта выправіць. Прачытайце абмен перад тым, як змяняць групу сервера.

Два шляхі аўтэнтыфікацыі, якія выглядаюць аднолькава ў журнале

У першым шляху VPN-шлюз збірае імя карыстальніка і пароль і адпраўляе RADIUS Access-Request з атрыбутам пароля. Сервер аўтэнтыфікацыі параўноўвае яго са сваім сховішчам уліковых даных і адказвае прыняццем або адмовай. Кліент ніколі не выконвае метад EAP, бо нішто яго не папрасіла.

У другім шляху кліент і сервер аўтэнтыфікацыі выконваюць метад EAP ад пачатку да канца, а шлюз перадае паміж імі атрыбуты EAP-Message. Шлюз па-ранейшаму завяршае знешнюю размову RADIUS, але логіка метаду жыве на двух канцах.

Абодва шляхі даюць у журнале радок пра няўдалую аўтэнтыфікацыю. Толькі другі можа залежаць ад таго, які метад EAP аддае перавагу сервер, і толькі першы — ад таго, як шлюз чытае пароль. Калі лічыць іх узаемазаменнымі, каманды марнуюць дзень на змену груп сервера для кліента, які ніколі не збіраўся гаварыць PEAP.

Дзе насамрэч выконваецца метад

RFC 3579 вызначае схему празрыстай перадачы: NAS нясе пакеты EAP у атрыбутах RADIUS і не патрабуе коду, спецыфічнага для кожнага тыпу EAP. Таму шлюз можа падтрымліваць PEAP і EAP-TLS, не рэалізуючы ніводнага з іх.

Шлюз, які падае пароль, не нясе PEAP, нават калі б бэкенд прыняў бы PEAP ад іншага кліента. Уключэнне PEAP у палітыцы сервера не дадае метад кліенту, які ніколі яго не прапаноўваў.

Налады аўтэнтыфікацыі PPP належаць службе PPP. Яны не пераналаджваюць маўкліва кожны шлях IPsec або састарэлага XAuth, які выкарыстоўвае той жа сервер AAA, таму змена, якая працуе для аднаго тыпу доступу, можа пакінуць іншы некранутым.

Што павінен падтрымліваць NAS

Празрыстая перадача пераносіць патрабаванне з коду метаду на падтрымку носьбіта. Шлюз павінен умець несці EAP праз свой пратакол VPN, а кліент RADIUS на ім — адпраўляць і прымаць атрыбуты EAP-Message адпаведных памераў.

Для IKEv2 EAP з'яўляецца часткай вызначанага патоку аўтэнтыфікацыі, і праверкі ідэнтычнасці сервера і даверу паходзяць з гэтага патоку. Этыкетка PEAP, запазычаная з разгортвання 802.1X, не пераносіцца аўтаматычна, бо перамовы вакол яе іншыя.

Бок кліента таксама мае патрабаванні. Ён павінен быць наладжаны на метад, давяраць сертыфікату сервера, які прад'яўляе метад, і мець уліковыя даныя, якія метад можа выкарыстаць. Метад на аснове сертыфікатаў без кліенцкага сертыфіката падае раней, чым RADIUS нешта ўбачыць, а гэта праблема забеспячэння, а не палітыкі сервера.

Прачытайце адну спробу перад зменай палітыкі

Захапіце адну ўхваленую спробу на шлюзе і на серверы аўтэнтыфікацыі. Шукайце атрыбуты EAP-Message у запыце RADIUS. Іх наяўнасць кажа, што выкарыстоўваецца шлях празрыстай перадачы; адсутнасць паказвае на абмен уліковымі данымі.

На шлюзе Linux захоп на порце RADIUS паказвае, якія атрыбуты ідуць па сетцы:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Затым параўнайце пункт адмовы. Збой на шлюзе да любога пакета RADIUS азначае, што кліент і шлюз не дамовіліся пра метад. Адмова RADIUS з атрыбутамі EAP азначае, што канцы выканалі метад і адзін з іх адхіліў вынік.

Плануйце міграцыю як адну змену ад пачатку да канца

Змяніць метад значыць змяніць разам канфігурацыю кліента, падтрымку носьбіта на шлюзе, палітыку метаду на серверы і сховішча ўліковых даных. Рабіце гэта ў такім парадку і трымайце працоўны шлях, пакуль новы не будзе даказаны. Змена толькі на баку сервера — гэта здагадка, і яна звычайна ламае кліентаў, якія працавалі. Падгатуйце змену на адной тэставай ідэнтычнасці, перш чым чапаць групу.

Запішыце спалучэнне, якое працуе: пратакол VPN, носьбіт EAP, метад партнёра, метад сервера, тып уліковых даных і праверка ідэнтычнасці сервера.

Трымайце адміністрацыйны ўваход AAA асобна ад аўтэнтыфікацыі VPN, калі задача відавочна не ўключае абодва. Змена, прызначаная для аддаленага доступу, не павінна пазбаўляць вас магчымасці кіраваць прыладай, якая яе завяршае.