Port 80 və 443 qaydaları brauzeri VPN-dən keçirmir

Kimsə brauzerin tuneldən istifadə etməsini xahiş edir və cavab təyinat portları 80 və 443-ə uyğun gələn firewall qaydası kimi qayıdır. Dəqiq görünür və dəqiq deyil. Port uyğunluğu paketləri yüklərinə görə deyil, nəqliyyat başlığına görə seçir, hansı proqramın soket açdığına görə deyil, və müasir gəzinti TCP-də bu iki portla məhdudlaşmır. Qayda daxil etmək istədiyiniz bəzi trafiki qaçıracaq və toxunmaq istəmədiyiniz trafiki tutacaq. Onu yazmazdan əvvəl üç fərqli sərhəddən hansını həqiqətən istədiyinizə qərar verin.

Qayda tətbiqi deyil, nəqliyyat sinfini təsvir edir

Linux-da təyinat portu uyğunluğu TCP başlığını yoxlayır və ondan yuxarı heç nəyi. Həmin paketləri işarələmək və siyasət marşrutu ilə yönləndirmək sənədləşdirildiyi kimi işləyir və bu mexanizmin heç biri yükün nə demək olduğunu və ya hansı prosesin göndərdiyini bilmir. İşarə paketə əlavə olunan rəqəmdir, tətbiqə əlavə olunan kimlik deyil.

nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100

Dərhal iki nəticə çıxır. TCP 443-ə qoşulan proqram yeniləyicisi brauzerlə eyni rəftarı alır, bu ya yaxşı ola bilər, ya da növbəti yeniləmə dövrünü gözləyən fasilə. Və qəsdən başqa portda, məsələn 8443-də yayımlanan veb xidməti tamamilə qaydanın xaricində qalır, halbuki istifadəçinin vecinə olan veb trafiki hələ də odur.

Rəqəmlər tələb həqiqətən həmin portlar barədə olduqda qanuni seçicilərdir. Onlar uydurmaya çevrilir ki, biletə «brauzer» yazılır və qaydalar toplusunda port aralığı tətbiq olunur. Boşluq sənədləşdirmə incəliyi deyil. Bu, baxışda müdafiə edə biləcəyiniz qayda ilə heç kimin sınaqdan keçirə bilmədiyi qayda arasındakı fərqdir.

HTTP/3 sizin TCP qaydanızı səssizcə tərk edir

HTTP/3 QUIC üzərində işləyir və QUIC UDP-də daşınır. Yalnız TCP-yə uyğun gələn qayda onu görə bilmir, ona görə test səhifənizi keçən həmin brauzer sonrakı sorğunu UDP ilə göndərib tuneli yan keçə bilər, heç kim heç bir parametri dəyişmədən. RFC 9114 HTTP/3-ü QUIC əsaslı protokol kimi təsvir edir və QUIC ümumi yerləşdirmədə standart portu 443 olan UDP-dən istifadə edir.

Müəyyən brauzerin HTTP/3-ü sınaması onun konfiqurasiyasından, saytdan və əvvəlki cəhdin uğurlu olub-olmadığından asılıdır. Bu onu yaddaşdan əsaslandırmaq üçün pis şey edir. Əvəzində alətdən soruşun:

curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'

curl sətri razılaşdırılmış versiyanı çap edir, ona görə 3 rəqəmi UDP yolunun istifadə olunduğunu təsdiqləyir. Sonra soket siyahısı həmin bağlantının tunel interfeysinə, yoxsa fiziki interfeysə bağlı olduğunu göstərir. Əgər curl quruluşunuzda HTTP/3 yoxdursa, bayraq səssizcə geri çəkilmək əvəzinə ucadan uğursuz olur və bu öz kiçik mərhəmətidir.

DNS ayrıca verməli olduğunuz qərardır

Veb trafiki üçün port qaydası ad həll etmə barədə heç nə demir. Brauzer sistem həlledicisini, brauzerin içində konfiqurasiya edilmiş həlledici və ya son qoşulanın itələdiyi həlledici istifadə edə bilər. Bunların hər biri sorğuları sizin qaydanızın seçdiyindən fərqli yolla göndərə bilər və bu klassik parçalanmanı yaradır: səhifə yüklənir, ad gözləmədiyiniz yerdə həll olunur və daxili sayt ictimai ünvana həll olunur, ya da heç həll olunmur.

Buna açıq şəkildə qərar verin. Daxili adlar tuneldən keçməli olsa, həlledici onun içində olmalıdır və qayda toplusu həmin həllediciyə DNS-ə icazə verməli, digər sorğuları isə kənarda saxlamalıdır. Brauzer ictimai təchizatçıya DNS over HTTPS istifadə edərsə, sorğu həlledicinizi tamamilə yan keçir və port qaydası kömək edə bilməz. Seçimi marşrut qaydası ilə eyni dəyişiklik qeydinə yazın, çünki növbəti nasazlığı araşdıran hər kəs ikisini birlikdə oxuyur.

Sonra səhifə ilə deyil, həlledici ilə yoxlayın:

resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'

Çatışmayan cavab, brauzerin xəta mesajı şəbəkəni günahlandırsa da, həll etmə problemidir. Bu iki nasazlıq istifadəçi üçün eyni görünür və tamamilə fərqli biletlərdir.

Üç sərhəd, üç fərqli mexanizm

İstədiyiniz sərhədi adlandırdıqdan sonra qarışıqlığın çoxu yox olur. Onlar bir-birini əvəz etmir və hər birinin tunel kəsildikdə öz uğursuzluq rejimi var.

Ayrı brauzer profili orta sətirdəki tələdir. O, kukiləri və tarixçəni ayırır və hostun marşrut cədvəli barədə heç nəyi dəyişmir, ona görə hər iki profil eyni yolu tutur. İzolyasiya nüvənin tətbiq etdiyi bir şey tələb edir, yəni ad fəzası, konteyner ya da öz tunel interfeysinə sahib tətbiq.

Hansı sətirə aid olsa da, tunel düşəndə nə baş verməli olduğunu yazın. İnterfeyslə birlikdə yox olan işarə əsaslı marşrut adətən fiziki standart marşruta geri düşür, bu da fail-open davranışdır. Bu gəzinti üçün məqbul, başqa hər şey üçün qeyri-məqbul ola bilər və bu qərar, tətbiq detalı deyil.

Örtdüyünüzü iddia etdiyiniz axınları sınaqdan keçirin

Qəbul testi yazdığınız sərhədə uymalıdır, rahat olan port nömrələrinə deyil. Tuneldən keçməli olan bir axın, keçməməli olan bir axın və düşünmədiyiniz nəqliyyatdan istifadə edən bir axın seçin:

ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'

Marşrut axtarışı təyinatın həqiqətən hansı interfeysdən istifadə etdiyini deyir və bu, hesabatların çoxunun səhv saldığı faktdır. curl sətri razılaşdırılmış versiyanı və ünvan ailəsini təsdiqləyir. Qaydalar toplusunun çıxarışı sınaq zamanı əlavə etdiyiniz və əhatəsini təyin etməyi unutduğunuz qaydayı tutur, müvəqqəti işarə beləcə daimi fail-open marşrutlaşdırmaya çevrilir.

Üç nəticənin hamısını vaxt damğası ilə qeyd edin və dəyişikliklə birlikdə saxlayın. Sonra kimsə «VPN daxili şəbəkəni sındırdı» deyə bildirdikdə, nəzərdə tutulan sərhəd ilə tətbiq olunan arasındakı fərq həmin qeyddə görünəcək və düzəliş mübahisə deyil, qayda dəyişikliyi olacaq.