Статычны IP у Azure P2S VPN: чаму змяняецца адрас кліента

Кожны кліент Azure point-to-site атрымлівае адрас з пула пры аўтэнтыфікацыі і захоўвае яго толькі на час гэтага злучэння. Няма ні табліцы рэзервавання, ні прывязкі да карыстальніка, ні налады шлюза, якая азначае «заўсёды давай гэтаму чалавеку 172.16.0.10». Менавіта гэты адзіны механізм тлумачыць абодва сімптомы, з якімі людзі сутыкаюцца пазней: правіла NSG, якое перастае супадаць з карыстальнікам, з якім раней супадала, і спіс дазволаў, які ціха пускае машыну, якую ніхто не дадаваў наўмысна. Замена правіла больш разумным правілам IP не выпраўляе ні таго, ні іншага, бо тое, што правіла называе, перапрызначаецца паводле раскладу, які вы не кантралюеце.

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

Што шлюз насамрэч робіць, калі кліент падключаецца

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

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

Любое змяненне канфігурацыі point-to-site таксама скідвае прастору арэнды. Іншы тып аўтэнтыфікацыі, зменены памер пула, новы дыяпазон пула або шлюз, які знеслі і перабудавалі, — усё гэта вяртае кліентаў у пул, які больш не адпавядае іх старым адрасам. Нішто ў гэтым змяненні не закранае ваш NSG, таму паломка выглядае спантаннай.

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

NSG, прывязаны да IP кліента, насамрэч з'яўляецца правілам пра парадак падключэння

Правіла, якое людзі пішуць першым, — відавочнае: уваходнае правіла на NIC кіравальнай ВМ або на яе падсетцы, з унутраным адрасам кліента VPN у якасці крыніцы. Яно кароткае, праходзіць тэст у дзень напісання і перастае працаваць, як толькі ў пуле больш за адзін свабодны адрас.

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

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

Арэнда кліента і адрас шлюза — розныя аб'екты

Большасць блытаніны паходзіць ад аднаго слова. Шлюз мае публічны IP, які адносна стабільны; кліенты маюць прыватныя адрасы з пула, якія не стабільныя. Для незонава-рэзервованага шлюза VPN публічны IP выдзяляецца дынамічна, але ён перажывае змену памеру, скід і руціннае абслугоўванне — ён змяняецца, калі сам шлюз выдаляюць і ствараюць нанова. Зонава-рэзервованыя і занальныя SKU шлюза выкарыстоўваюць публічны IP Standard SKU, і гэтае выдзяленне павінна быць статычным.

Менавіта гэтая стабільнасць патрэбна лакальнаму партнёру ў яго канфігурацыі, і яна нічога не кажа пра ідэнтыфікацыю асобнага кліента. Калі партнёр пытае, які адрас ён убачыць, адказ — публічны IP шлюза ў site-to-site або агульны дыяпазон NAT, але ніколі арэнда тунэля ноўтбука.

Групавыя пулы даюць дыяпазон, супраць якога варта пісаць правілы

Virtual WAN point-to-site падтрымлівае групы карыстальнікаў, і кожнай групе можна прызначыць уласны пул адрасоў кліентаў. Членства вызначаецца ідэнтычнасцю, таму дыяпазон, у які трапляе кліент, становіцца прадказальным: аперацыі ў адным дыяпазоне, падрадчыкі ў іншым, і гэты дыяпазон можна назваць у правіле брандмаўэра або NSG без здагадак.

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

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

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

Калі разгортванне не можа перайсці на Virtual WAN

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

Ідэнтычнасць на ўзроўні рэсурсу — самы танны варыянт. Storage, SQL і Key Vault усе падтрымліваюць аўтэнтыфікацыю Entra ID з прызначэннямі роляў па карыстальніку або па групе, таму VPN трэба толькі даказаць сеткавую дасяжнасць. Хост пераходу з іменнымі ўліковымі запісамі робіць тую ж працу для адміністрацыйных задач, бо хост запісвае чалавека, а тунэль проста нясе пакеты. Рэгістрацыя кліентаў у DNS і даданне ў спіс дазволаў імя замест нумара падымае правіла на ўзровень вышэй. Ідэнтычнасць на ўзроўні прыкладання — тэма сертыфіката, заява токена, членства ў групе — працуе, калі вырашаць прасіць не сетку, а прыкладанне.

Партнёру, які настойвае на фіксаваным адрасе крыніцы, адказ — site-to-site або ExpressRoute з вызначаным прэфіксам партнёра. Яны ўносяць прэфікс партнёра ў спіс дазволаў, адрас, які з'яўляецца на іх баку, належыць шлюзу і не змяняецца, калі хтосьці перазагрузіць ноўтбук.

Праверце пул, перш чым рэдагаваць чарговы спіс дазволаў

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

Звядзіце тры рэчы на адну старонку, перш чым кранаць правіла: пул point-to-site, адрасную прастору віртуальнай сеткі і лакальныя дыяпазоны. Яны не павінны перакрывацца, і пулу патрэбна месца для кожнага адначасовага кліента плюс запас на перападключэнні.

Затым замкніце цыкл у такім парадку:

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