DNS канцавой кропкі AWS Client VPN: чаму замацаванне развязанага IP не працуе

На мінулым тыдні dig +short даў вам адзін адрас для назвы канцавой кропкі ў вашым профілі AWS Client VPN, і тунель падключыўся. На гэтым тыдні той жа профіль стаіць на 'Connecting' на вашым ноўтбуку, пакуль некранутая копія калегі ўсё яшчэ працуе. Нічога не было заблакавана, і сертыфікат не скончыўся. Хтосьці замяніў імя хоста канцавой кропкі на гэты развязаны адрас, і сэрвіс больш там не адказвае. Экспартаваная назва — гэта частка, пабудаваная так, каб перажыць гэтую змену.

Назва ў вашым профілі можа не быць назвай, па якой ідзе запыт

Профілі, экспартаваныя з Client VPN, звычайна маюць remote-random-hostname. Калі гэтая опцыя ўключана, кліент стварае аднаразовую метку, далучае яе да назвы канцавой кропкі праз кропку і развязвае аб'яднаную назву. Запіс з шаблонам у зоне канцавой кропкі адказвае на любую метку, таму выдуманы прэфікс таксама развязваецца і таму гэты трук застаецца нябачным, калі вы спрабуеце паўтарыць запыт уручную.

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

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

Чаму захаваны адказ не можа заставацца правільным

Адрасы канцавой кропкі Client VPN кіруюцца AWS і змяняюцца з часам, пра што дакументацыя па найлепшых практыках кажа проста. Злоўлены адказ — гэта здымак аднаго развязання. Профіль, які жорстка замацоўвае яго, становіцца профілем, нацэленым на выведзены з эксплуатацыі хост, як толькі сэрвіс пераедзе, і збой рэдка выглядае як DNS: вы атрымліваеце тайм-аўт падключэння або затрыманы handshake, таму людзі ганяюцца за маршрутызацыяй і сертыфікатамі.

Той жа адказ у /etc/hosts атрымлівае той жа тэрмін прыдатнасці з дадатковай праблемай. Запіс hosts перажывае перазагрузкі, паўторныя экспарты і выпраўленні 'пераўсталяваць кліент', таму збой вяртаецца кожны раз, калі адрас пераязджае. Я бачыў, як адзін такі запіс тыднямі сядзеў бясшкодна, а потым вывеў з ладу кожную машыну, якая яго несла, тады як свежыя ўсталёўкі падключаліся нармальна. Гэтае раздзяленне, адна група са збоямі, другая ў парадку на тым жа акаўнце, — самая таннае падказка, якую вы атрымаеце.

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

Што правярае сэрвіс, калі тунель падымаецца

Client VPN патрабуе, каб адрас, да якога вы падключаныя, супадаў з адрасам, развязаным для DNS-назвы канцавой кропкі. Гэта адно патрабаванне тлумачыць некалькі збояў, якія выглядаюць незвязанымі: уласны DNS-запіс, які паказвае ў іншае месца, уласны frontend, які перанакіроўвае на сапраўдны адрас канцавой кропкі, і профіль, перапісаны на сыры адрас. AWS апісвае схему 'уласны запіс плюс перанакіраванне' як збой з сучаснымі кліентамі ад AWS. Праверка вузкая; гэта не рашэнне, што кожны псеўданім забаронены.

Гэта таксама не агульнае правіла пра пратаколы VPN. Лікавы remote цалкам дапушчальны ў звычайным разгортванні OpenVPN, і шмат іх так працуе. Абмежаванне ідзе ад кіраванай схемы, а не ад пратаколу пад ёй.

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

Спісы дазволеных, выхад і прыватны DNS — тры асобныя праблемы

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

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

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

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

Праверце злучэнне, нічога не замацоўваючы

Пачніце з профілю так, як ён экспартаваны, і прачытайце, што ён насамрэч запытвае:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

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

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

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

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