Bir portu VPN-dən kənara çıxarmaq üçün siyasət əsaslı marşrutlaşdırma lazımdır

Sorğu həmişə eyni cümlənin bir variantıdır: VPN-i brauzinq üçün saxla, amma SSH və ya ehtiyat nüsxə işi adi bağlantıdan istifadə etsin. Bu barədə yayılan məsləhət, yəni portu iptables NAT qaydaları ilə yönləndirmək, bunu etmir. NAT qaydası axın içindəki ünvanları və portları yenidən yazır; paketin hansı interfeysdən çıxacağını heç vaxt seçmir. Bu qərar marşrut axtarışına aiddir və marşrut axtarışının portu görmək üçün köməyə ehtiyacı var.

Niyə adi marşrut portla uyğunlaşa bilmir

Linux marşrutu hədəf ünvanını cədvəldə axtararaq seçir, namizəd cədvəlləri əvvəlcə siyasət qaydaları ilə süzür. Həmin qaydalar firewall işarəsi, mənbə ünvanı, gələn interfeys və ya UID ilə uyğunlaşa bilər. Marşrut yazısının özündə port sahəsi yoxdur, çünki marşrut nəqliyyat başlığı vacib olmadan əvvəl seçilir.

Müasir iproute2 və nüvələr qayda seçicisini genişləndirir: ipproto, sport və dport qəbul edilir, yəni ip rule add ipproto tcp dport 22 table 100 niyyəti bir sətirdə ifadə edir. ip rule add help əmrini real hostda işə salın ki, qurğunuzun dport göstərib-göstərmədiyini görəsiniz. Göstərirsə, bir əmrlə bitirdiniz; göstərmirsə, aşağıdakı işarə yolu ekvivalentdir.

Hər halda qayda yalnız göstəricidir. Cədvəl 100 hələ də marşrut tələb edir və insanların unutduğu hissə elə budur.

Üç hissə, yoxsa bir

Müasir forma yuxarıdakı tək qayda və alternativ cədvəldə bir marşrutdur. Klassik forma ortaya netfilter əlavə edir: paketi işarələ, sonra işarəni qaydada uyğunlaşdır. İkisi də eyni axtarışda bitir; fərq portun harada oxunmasındadır.

İşarə yanaşması ona görə var ki, netfilter nəqliyyat başlığını görür, marşrutlaşdırma kodu isə tarixən görmürdü. Bütün mexanizm budur və bu, ehtiyat variantın bir ağıllı əmr deyil, üç birgə işləyən hissə olmasını izah edir.

Üç hissə ardıcıllıqla

Birincisi, yönləndirmək istədiyiniz axınları işarələyin; zəncir işarənin marşrut qərarından əvvəl mövcud olması üçün kifayət qədər erkən işləməlidir:

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

İkincisi, işarələnmiş paketləri ayrı cədvələ göndərin:

ip rule add fwmark 0x1/0x1 table 100

Üçüncüsü, o cədvələ fiziki kanal vasitəsilə defolt marşrut verin. Ünvanlar nümunədir; öz ünvanlarınızla əvəz edin:

ip route add default via 192.168.1.1 dev wlan0 table 100

Üçüncü addımı atlaysanız, işarələnmiş paket Cədvəl 100-də marşrut tapmır və uğursuz olur. Simptom elə görünür ki, qayda şəbəkəni sındırıb, halbuki əslində paketin qalan yeganə yolunu silib.

İlk paketdən sonra onu nə işlək saxlayır

İşarələr çıxan paketlərə aiddir. Cavab fiziki interfeysə həmin kanalın təyin etdiyi ünvanla gəlir və əsas cədvəl həmin hədəf üçün hələ də tunelə üstünlük verə bilər. Cavab yolunu iki mexanizm ardıcıl saxlayır: kanal ünvanı üçün mənbə əsaslı qayda və axının ömrü boyu qərarı qoruyan bağlantı izləmə. İşarəni conntrack-ə yazmaq və cavabda bərpa etmək vəziyyətdən asılı istisnanı sabit etməyin adi yoludur.

Əks yol süzgəci digər səssiz qatildir. Nüvə qayıdış yolunu ciddi yoxlayırsa və cavab əsas cədvəlin seçməyəcəyi interfeysə gəlirsə, paket heç bir mesaj olmadan atılır. rp_filter dəyərləri distributivə və interfeysin yönləndirilib-yönləndirilməməsinə görə fərqlənir, ona görə söndürülmüş olduğunu fərz etmək əvəzinə faktiki dəyəri oxuyun.

Tunelin öz nəqliyyatını işarələməyin. WireGuard və ya UDP OpenVPN tuneli TCP 22 deyil, ona görə yuxarıdakı resept təhlükəsizdir, lakin tunel hədəfindən başqa hər şey kimi yazılmış istisna şifrələnmiş paketləri tuta və tuneli marşrut dövrəsi kimi görünən şəkildə poza bilər.

Fərz etmək əvəzinə yoxlayın

Nüvədən soruşun hansı yolla gedəcəyini, həm hədəf, həm də port üçün, sonra real köçürməni işə salın:

ip route get 203.0.113.10
ip rule show
nft list ruleset

İşarə varsa, amma sayğaclar heç tərpənmirsə, qayda uyğunlaşmır. Sayğaclar yazdığınız konfiqurasiya ilə nüvənin tətbiq etdiyi siyasət arasındakı fərqdir.

Bu nə vaxt yanlış vasitədir

Port əsaslı istisnalar təbiətcə kövrəkdir. Xidmətlər portlarını dəyişir, HTTP/3 UDP 443 kimi gəlir və bir tətbiq müxtəlif növlü bir neçə axın aça bilər. Əsl tələb bu proqramın adi kanaldan istifadə etməsidirsə, marşrutlaşdırma qatı yanlış yerdir; şəbəkə ad sahəsi və ya hər tətbiq üçün proksi daha uyğundur.

Tələb bu alt şəbəkənin adi kanaldan istifadə etməsidirsə, işarələri tamamilə atlayın və daha konkret marşrut əlavə edin. Bu daha sadədir, bir cədvəldə görünür və növbəti şəxs qaydalar toplusunu oxumadan onu yoxlaya bilər.

Firewall-a toxunmadan əvvəl üç tələbdən hansının sizdə olduğunu yazın. Yuxarıdakı mexanizm dəqiqdir və yanlış qata tətbiq olunan dəqiqlik sadəcə daha uzun fasilədir.