UFW tunel qalxdıqdan sonra VPN-in DNS serverini rədd edir

VPN qoşulan anda adlar həll olunmaqdan dayanır, halbuki ümumi ünvana ping hələ də cavab verir və firewall statusu səhv görünən heç nə göstərmir. Siyasətdə heç nə dəyişməyib; dəyişən odur ki, yeni interfeys yaranıb və default deny onu ilk paketdən əhatə edir. UFW istiqamətə və interfeysə görə qərar verir, ona görə də simsiz keçid üçün yazılmış qayda tuneldən çıxan trafik haqqında heç nə demir. Düzəliş müəyyən ardıcıllıqla tətbiq olunan bir neçə dar qaydadır.

Simptom yalnız tunel qalxdıqdan sonra görünür

Default deny siyasəti ona deyiləni dəqiq edir: uyğun qaydası olmayan hər şey, mövcud olan hər interfeysdə rədd edilir. Qaydalar yazılarkən tunel mövcud deyildi, ona görə də heç biri ona uyğun gələ bilməz və həmişə orada olan deny indi ad həllinə tətbiq olunur. Birbaşa ünvana gedən trafik daha geniş allow ilə əhatə olunduqda hələ də işləyə bilər, buna görə ümumi resolver-ə ping uğurlu olur, ad axtarışı isə uğursuz qalır. Boşluq siyasətin heç vaxt görmədiyi interfeys üçün qaydadır.

Bu həm də izah edir ki, nasazlıq təmiz şəkildə tərsinə çevrilir: tuneli söndür və adlar yenidən həll olunur, çünki sorğu qaydaları olan interfeysə qayıdır. Yalnız tunel qalxanda uğursuz olan siyasət DNS problemi deyil və resolver-in özünü tənzimləmək burada ən çox vaxt itirir. Resolver konfiqurasiyasını oxumazdan əvvəl interfeys siyahısını oxu.

Üç istiqamət, üç fərqli qayda dəsti

Tək bir sessiya birdən çox istiqamətdə qaydalara toxunur və tunel onların demək olar hamısına ikinci interfeys əlavə edir. Trafiki əvvəlcə istiqamətə və interfeysə görə sıralamaq qalanı mexaniki edir, çünki aşağıdakı hər sətir öz yerində öz qaydasını tələb edir. Nümunələr tun0 və 10.8.0.0/24 hovuzundan istifadə edir, ona görə adları və diapazonları müştərinin öz çıxışından götürülənlərlə əvəz et.

İki sətir tez-tez qarışdırılır, çünki hər ikisi tuneli qeyd edir. Resolver üçün qayda müştərinin tunelə göndərdiyi trafikə icazə verir, SSH üçün qayda isə serverin ondan aldığı trafikə icazə verir; onlar fərqli maşınlarda yaşayır və ayrı-ayrılıqda uğursuz olur. Ən çox unudulan sətir ikincidir, çünki müştəri serverin ümumi ünvanına gedən trafikinə icazə verilməyincə tuneli ümumiyyətlə qura bilməz. Yuxarıdan aşağı işlə və hər uğursuzluğun bir ehtimal olunan səbəbi var.

Push edilən resolver öz qaydasını tələb edir

Tunelin DNS daşıyıb-daşımaması serverin nə göndərdiyindən asılıdır. Resolver seçimini push edən server müştərinin konfiqurasiyasına özəl ünvan quraşdırır və həmin ünvana yalnız tunel vasitəsilə marşrut mümkündür. Server heç nə push etmirsə, müştəri artıq malik olduğu resolver-i saxlayır və aşağıdakı qaydaların icazə verəcəyi heç nə qalmır. Hər hansı bir şey yazmazdan əvvəl push edilmiş vəziyyəti və cari sorğu nəticəsini yoxla:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Status çıxışı istifadə olunan resolver-i və onun bağlandığı keçidi göstərir, onun arxasındakı marşrut axtarışı isə hansı interfeysin həmin ünvana sorğu daşıyacağını göstərir. Resolver başqa keçiddə yerləşirsə, problem firewall-dan əvvəldir və heç bir qayda kömək etməyəcək. Hər ikisi tunel barədə razılaşanda iki qayda lazımdır, çünki sorğuların çoxunu UDP daşıyır və cavab kəsiləndə TCP işə keçir. Hər iki dəyəri qeyd et, çünki qaydalar məhz onları adlandıracaq:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

Xarici yolu daxildən əvvəl aç

Müştəri tunel yaranmazdan əvvəl serverin ümumi ünvanına çatmalıdır, ona görə onun qaydası fiziki keçiddə oturur və ilk olaraq yerində olmalıdır. Resolver-ə icazə verib serveri unudan siyasət müştərini tuneli ümumiyyətlə qura bilməyən vəziyyətdə qoyur və bu simptom adətən kill switch-in üzərinə atılır. Sonra həqiqətən tuneldən istədiyin xidmətlərə icazə ver, hər dəfə bir dar qayda ilə, interfeysi bütövlükdə açmaq əvəzinə. Dar qaydalar deny-in yerində qalmasının səbəbidir.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

Test edərkən sıra vacibdir, çünki tunelin ümumiyyətlə qalxmasına imkan verən ilk qaydadır. Onu əlavə et, qoşul və xidmət qaydasını əlavə etməzdən əvvəl tunelin qalxdığını təsdiqlə, çünki hər ikisini birdən etmək uğursuzluğun hansı yarısının səhv olduğunu söyləməməsi deməkdir. Yuxarıdakı sənədləşmə ünvanını müştərinin istifadə üçün konfiqurasiya olunduğu son nöqtə ilə əvəz et.

Müştəri tərəfini qəsdən əlaqəni kəsməklə bitir. Deny qəsdən istisna etdiyin trafikə hələ də imtina etməlidir, çünki tunel qalxanda cavab verən resolver şübhə halında imtina edən siyasətin yalnız yarısını əhatə edir.

Qoşulan müştəri hələ qəbul edilməyib

Serverin nəzərə almalı olduğu öz istiqaməti var və əl sıxışmasını tamamlayan müştəri server onu qəbul etməyincə serverdə işləyən heç nəyə çata bilməz. Ümumi dinləyici qaydası yalnız tunelin mövcud olmasına imkan verir; tunelin trafikini içəri buraxmır. Serverdə bu, iki qayda üstəgəl xidmətin həqiqətən dinlədiyini yoxlayan bir yoxlamadır:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

Qaydadakı hovuz serverin ayırdığı diapazona bərabər olmalıdır və tunel nömrəsi serverin yaratdığı ilə uyğun gəlməlidir, çünki fərqli interfeys üçün qaydanı heç qayda olmamasından ayırmaq mümkün deyil. limit inzibati port üçün qəsdəndir, çünki təkraredici bağlantıları hədsiz qəbul etmək əvəzinə məhdudlaşdırır. Dinləyici yoxlaması bağlı portu düşmüş paketdən ayırır, onlar müştəridən eyni görünür. Nömrələnmiş qaydalar da bütöv mənzərə deyil: UFW-nin before qaydaları və əl ilə yazılmış istənilən nftables sətri daha əvvəl uyğun gəlir və siyahının icazə verdiyi görünən paketi yenə də rədd edə bilər.