Hotspot niyə VPN qoşulmazdan əvvəl DNS-i yönləndirir?

Otel şəbəkəsinə qoşulmaq qarşınıza müxtəlif anlarda iki DNS qərarı çıxarır: cihazın daxil olarkən etdiyi axtarışlar və tunel hazır olduqdan sonra edilən axtarışlar. Hotspot birincisini idarə etdiyi şəbəkə vasitəsilə təsir edə bilər. İkincisi müştərinin öz siyasətindən asılıdır və bu, ayrıca yoxlanmalı bir məsələdir.

Bağlantını sıra ilə izləyin, ilk DHCP icarəsindən şəxsi adı həll edən sorğuya qədər. Onda dəstək bileti içində eyni görünən iki nasazlıq aydın şəkildə ayrılır: biri tunel yaranmazdan əvvəl, digəri isə onun içində baş verib.

Hotspotun toxuna bildiyi və toxuna bilmədiyi şeylər

Giriş şəbəkəsi DHCP vasitəsilə resolver ünvanı verir və həmin ünvana doğru 53 portunu tuta bilər. Bu, qorunmayan hər axtarışı portal ünvanı və ya bloklama səhifəsi ilə cavablandırmaq üçün kifayətdir. Bu həmçinin son nöqtəsi host adı kimi yazılmış VPN müştərini sındırmaq üçün kifayətdir.

Hotspotun edə bilmədiyi şey, sorğu qurulmuş tunelin içində getdikdən sonra onu oxumaq və ya yenidən yazmaqdır, təbii ki tunel onu həqiqətən daşıyırsa. Tutma açıq mətn sualını görməkdən asılıdır.

Sorğular yenə də tuneldən hotspotla əlaqəsi olmayan səbəblərə görə çıxır: brauzerin təhlükəsiz DNS ayarı, korporativ şəkilçini lokal resolverdə saxlayan split-DNS qaydası və ya DNS-i tuneldən kənarda qoymaq üçün konfiqurasiya edilmiş müştəri. Hər biri müştəri tərəfində verilən seçimdir və hər biri kənardan baxanda hotspot müdaxiləsi kimi görünür.

İlkin axtarış tunel yaranmazdan əvvəl baş verir

Host adı verilən müştəri əvvəlcə onu həll etməlidir və o anda heç bir tunel sorğunu qorumur. Hotspot portal ünvanı ilə cavab verirsə, danışıqlar uğursuz olur və ya donur. Heç nə ilə cavab verirsə, müştəri ad xətası bildirir və tunel heç vaxt başlamır. Hər iki nəticə başqa cür günahsız görünən boş tunel jurnalını izah edir.

Əməliyyat sistemləri öz bağlantı yoxlamalarını və portal aşkarlamasını da işə salır, bunlar RFC 8910 və RFC 8952-də təsvir olunub və həmin sorğular hər hansı VPN hazır olmadan çıxır. Onları proksi jurnalında görmək sızma sübutu deyil, gözlənilən davranışdır.

Praktik həll müştəriyə axtarış tələb etməyən son nöqtə verməkdir. Bu mümkün olmadıqda, əvvəlcə daxil olmağı tamamlayın, sonra qoşulun.

Hansı resolverin cavab verdiyini öyrənin

Brauzerdən deyil, sistemdən soruşun və sorğunu iki dəfə işə salın: bir dəfə cihazın hazırda istifadə etdiyi resolver vasitəsilə, bir dəfə sabit ünvana qarşı.

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

Birinci əmrdən gələn cavabın üçüncüdən fərqlənməsi lokal resolverin başqa bir şey qaytardığını göstərir və yönləndirən hotspotun etdiyi budur. Üçüncüdən uğursuzluq, birincidən uğurla birlikdə portalı göstərir: lokal resolver daxil olma ünvanı verdi, çıxan 53 portu isə atıldı. Hər ikisində vaxt aşımı şəbəkənin autentifikasiya tamamlanana qədər DNS-i rədd etdiyini bildirir.

Qoşulduqdan sonra təkrarlayın və müqayisə edin. Keşlənmiş cavab keçidi yaşayır, ona görə ikinci müşahidə üçün keşi təmizləyin və ya yeni ad soruşun.

Sonrakı axtarışları nəzərdə tutduğunuz yolda saxlayın

DNS-i də tutan tam tunel profili ən sadə quruluşdur: hər tətbiqin hər sorğusu tunelin itələdiyi resolverə gedir və lokal şəbəkə yalnız şifrələnmiş trafik görür. Bunu qoşulduqdan sonra daxili və ictimai bir adı həll edib hər iki cavabı tunel resolverinin təkbaşına qaytardığı ilə müqayisə edərək sübut edin.

Split-DNS məqsədlə yazılmış domen siyahısı tələb edir: korporativ şəkilçilər tuneldən, qalan hər şey lokal olaraq və ikisi arasında üst-üstə düşmə olmadan.

Brauzerin təhlükəsiz DNS-i bu siyasətdən kənarda durur, ona görə profil proqnozlaşdırıla bilən davransın deyə onu söndürmək lazımdırsa, maşın üçün deyil, həmin profil üçün söndürün. Bunu sistem resolverini redaktə etməklə deyil, brauzer ayarlarında edin ki, dəyişiklik növbəti dəfə görünsün. Hər test üçün bir sətirdə cavabı, resolveri və bağlantı mərhələsini qeyd edin. Otel Wi-Fi-da DNS uğursuz oldu deyən hesabat ən azı üç fərqli səbəbi olan bir simptomu təsvir edir.