Чаму хот-спот перанакіроўвае DNS да падключэння VPN?

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

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

Што хот-спот можа і чаго не можа крануць

Сетка доступу выдае адрас рэзалвера праз DHCP і можа перахапіць порт 53 у кірунку гэтага адраса. Гэтага дастаткова, каб адказаць на кожны незашчышчаны запыт адрасам партала або старонкай блакіроўкі. Гэтага таксама дастаткова, каб зламаць VPN-кліент, канчатковы пункт якога запісаны як імя хоста.

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

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

Пачатковы запыт адбываецца да з'яўлення тунеля

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

Аперацыйныя сістэмы таксама праводзяць уласныя праверкі злучнасці і выяўленне партала, апісаныя ў RFC 8910 і RFC 8952, і гэтыя запыты сыходзяць да запуску любога VPN. Бачыць іх у журнале проксі — чаканыя паводзіны, а не доказ уцечкі.

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

Вызначце, які рэзалвер адказаў

Спытайце сістэму, а не браўзер, і выканайце запыт двойчы: адзін раз праз той рэзалвер, які прылада выкарыстоўвае цяпер, другі — да фіксаванага адраса.

resolvectl query vpn.example.com
dig +short vpn.example.com
dig +short vpn.example.com @1.1.1.1

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

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

Трымайце наступныя запыты на той сцежцы, якую вы мелі на ўвазе

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

Split-DNS патрабуе спісу даменаў, напісанага з намерам: карпаратыўныя суфіксы праз тунель, усё астатняе лакальна, і без перакрыцця паміж імі.

Бяспечны DNS браўзера стаіць па-за гэтай палітыкай, таму калі яго трэба выключыць, каб профіль паводзіў сябе прадказальна, выключыце яго для гэтага профілю, а не для машыны. Рабіце гэта ў наладах браўзера, а не рэдагуючы сістэмны рэзалвер, каб змена была бачная наступным разам. Запісвайце адказ, рэзалвер і этап злучэння ў адзін радок на кожны тэст. Справаздача, у якой сказана, што DNS не спрацаваў у гатэльным Wi-Fi, апісвае сімптом з як мінімум трыма рознымі прычынамі.