Зашто хотспот преусмерава 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-ју описује симптом са најмање три различита узрока.