Чаму кліенты Access Server недасяжныя з LAN

Ноўтбук падключаецца, тунель узняты, а запыты да ўнутранай службы завісаюць на этапе злучэння. На самім сэрвісе запыт прыходзіць з адраса накшталт 10.90.0.25, адказ ідзе да стандартнага шлюза, і нічога не вяртаецца, бо гэты шлюз не ведае, дзе знаходзіцца 10.90.0.25. З іншага боку тая ж няспраўнасць выглядае як унутраны хост, які не можа пінгаваць падключанага кліента. І тое, і другое — адзін адсутны аб’ект: зваротны маршрут да пула кліентаў VPN, які можа дадаць толькі прыватная сетка.

Прачытайце адрас крыніцы, які бачыць сэрвіс

Гэтае адзінае поле вызначае ўсё астатняе. Калі ўнутраная служба бачыць адрас пула, Access Server маршрутызуе, а не хавае кліенцкі трафік, і кожны адказ трэба маршрутызаваць назад у пул. Калі ж яна бачыць уласны прыватны адрас сервера, сервер займаецца маскараваннем, і шлях адказу ўжо працуе — коштам страты любой ідэнтычнасці асобнага кліента ў журналах і правілах доступу службы.

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

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

Не мяркуйце, што пул адзін. Сервер можа мець дынамічны дыяпазон плюс статычныя прывязкі для кожнага карыстальніка, і статычны адрас можа цалкам ляжаць па-за дынамічным прэфіксам. Калі вы маршрутызуеце толькі той дыяпазон, які памятаеце, карыстальнікі з фіксаванымі адрасамі застаюцца са збоем, а ўсе астатнія паведамляюць, што праблема вырашана.

Дадайце маршрут там, дзе вырашаецца лёс адказу

Маршрут належыць шлюзу, які ўнутраная служба ўжо выкарыстоўвае, а не самой службе, калі толькі яна не маршрутызуе свой трафік. Накіруйце яго на дасяжны прыватны адрас Access Server — гэта іншае значэнне, чым тунельны адрас, які мае кліент.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

У хмарнай сетцы тое ж сцверджанне ператвараецца ў запіс табліцы маршрутызацыі, мэтай якога з’яўляецца інстанс або сеткавы інтэрфейс, дзе працуе сервер, з адключанай праверкай крыніцы і прызначэння на гэтым інтэрфейсе. Звярніце ўвагу, чаго гэты запіс не робіць: маршрут — не грант доступу, таму групы бяспекі, сеткавыя ACL і хост-файрвол усё яшчэ павінны дазволіць трафік.

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

Перасыланне і фільтры павінны ўзгадняцца з маршрутам

Маршрутызацыя — гэта толькі палова шляху. Сервер павінен мець дазвол перасылаць паміж тунелем і прыватным інтэрфейсам, што на Linux азначае net.ipv4.ip_forward плюс ланцуг перасылання, які дазваляе пару інтэрфейсаў, а на ўзмоцненым хосце звычайна яўнае правіла для кожнага напрамку.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Фільтраванне са станам тлумачыць сімптом, які вядзе людзей не туды. Адказу ўнутры ўсталяванага патоку не патрэбна новае правіла для ўваходу, таму злучэнне, якое завісае пасля SYN-ACK, не блакуецца адсутным правілам accept; яно адкідаецца або маршрутызуецца няправільна. Захоўвайце гэтае размежаванне, бо яно аддзяляе змену маршрутызацыі ад змены файрвола.

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

Маршрутызавана або з маскараваннем: выбірайце свядома

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

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

Падсетка за кліентам — асобная задача

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

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

Праверце адным патокам і адным перахопам

Давядзіце шлях адным злучэннем замест агульнага тэсту дасяжнасці. Назірайце той жа паток на абодвух канцах: запыт, што прыходзіць на службу, і адказ, што яе пакідае.

tcpdump -ni any host 10.90.0.25 and port 443

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

Скончыце чатырма праверкамі, якія зачыняюць пытанне: адрас крыніцы на службе адпавядае рэжыму, які вы мелі на ўвазе, шлюз мае маршрут да кожнага пула ў выкарыстанні, перасыланне і фільтры дазваляюць абодва напрамкі, і адзін рэальны паток праходзіць ад пачатку да канца. FAQ па маршрутызацыі Access Server выкладае той жа прынцып для ўсталяванага выпуску, чый падтрымліваемы інтэрфейс наладкі можа адрознівацца ад старых кіраўніцтваў.