Router VPN ilə bir cihaz üçün üç qayda lazımdır, tək açar yox

Router VPN-də hər cihaz üçün ayrı açar yoxdur; axtardığınız düymə sizin əvəzinizə siyasət marşrutu qaydalarını yazan bir qısayoldur. Bir noutbuk, bir port aralığı, bir ünvan siyahısı və ya bir LAN seqmenti tuneldən istifadə etməli olub, qalan hər şey WAN-da qaldığı an siz funksiya açmır, siyasət marşrutu qurursunuz. İşin üç hərəkətli hissəsi var və hər biri fərqli şəkildə sıradan çıxır: marşrutsuz işarələnmiş cədvəl sükut kimi görünür, yanlış zəncirdə tətbiq olunan işarə heç nə olmamış kimi görünür, çatışmayan NAT qaydası isə qoşulan, amma heç nə daşımayan tunel kimi görünür. Daha iki hissə itir, çünki onlar heç vaxt mangle qaydasında görünmür, bunlar DNS və IPv6-dır.

Mif: tunel müştəri ayarıdır

Router tərəfindəki VPN müştərisi bir kobud işi yaxşı görür: 0.0.0.0/0-ı əsas marşrut cədvəlinə qoyur və tunelə yönəldir. WireGuard bunu AllowedIPs-dən, OpenVPN isə itələnmiş redirect-gateway-dən çıxarır və hər ikisi routerin arxasındakı hər host üçün yolu dəyişir. AllowedIPs-i daraltmaq və ya route-nopull əlavə etmək müştərinin quraşdırdığını dəyişir. Amma quraşdırmanın kimə aid olduğunu dəyişmir, çünki müştəri heç vaxt cihazları görmür. O, yalnız paketləri görür.

Mənbə və ya təyinat üzrə seçim marşrut qərarıdır, buna görə routerin siyasət qatına aiddir: RouterOS-da mangle qaydası üstəgəl ikinci cədvəl, OpenWrt və ya DD-WRT-də MARK üstəgəl ip rule, pfSense-də isə şlüzü tunel olan firewall qaydası. Netgate-in WireGuard müştəri resepti təxmin etməzdən əvvəl oxunmalı olandır, çünki o platformada qaydanın şlüzü, interfeys təyinatı və çıxan NAT yazısı hamısı razılaşmalıdır ki, bir müştəri tuneldən istifadə etsin.

Mifin ikinci yarısı ikinci routerdir. Başqa bir qutu almaq və ya cihazı qonaq SSID-ə köçürmək çox vaxt işləyir və səbəb aparat deyil: bu, cihazı öz alt şəbəkəsinə qoyur, bu da sizə proqram təminatının artıq anladığı mənbə seçicisini verir. Əgər həmin seqmenti sahib olduğunuz routerdə təyin edə bilirsinizsə, əlavə qutu sizdə olmayan bir problemi həll edir.

Birinci hissə: əsas marşrut olmayan tunel

RouterOS-da müştərini əsas marşrutsuz əlavə edin və tunelə öz cədvəlini verin. Birinci marşrut işarələnmiş əsas marşrutdur; ikincisi uğursuzluq yarısıdır.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

Çatılmayan marşrut işarələnmiş cədvəlin əsas cədvəldəki istisna siyahısından üstün olmasının səbəbidir. Tunel düşəndə işarələnmiş paketlər səssizcə WAN-a qayıtmaq əvəzinə dərhal «çatılmır» alır, beləliklə nasazlıq bir saat sonra baxdığınız geo-məkan səhifəsində deyil, tətbiqin xəta mesajında görünür.

RouterOS 7, 6.x-in bir yerdə saxladığını ayırır: cədvəli /routing table add name=vpn fib ilə elan edirsiniz, sonra marşrutda və mangle qaydasında ona adı ilə istinad edirsiniz. Cədvəli təyin etmədən routing-mark-ı içəri yazan 6.x fraqmenti təmiz yüklənir və heç nəyə uyğun gəlmir. Digər klassik hal bir cədvəldə eyni məsafədə iki 0.0.0.0/1 yarısı və ya iki əsas marşrutdur: nüvə birini seçir və davranış yenidən başlatmadan sonra dəyişə bilər.

İkinci hissə: marşrut axtarışından əvvəl işarələ

Seçici hansı paketlərin o cədvələ girəcəyini müəyyən edir. RouterOS adətən təyinat siyasəti üçün ünvan siyahısı, cihaz siyasəti üçün isə mənbə ünvanı ilə başlayır:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux proqram təminatı eyni şeyi netfilter işarəsi və işarələnmiş paketləri doldurduğunuz cədvələ yönəldən qayda ilə edir:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

Zəncir üslub seçimi deyil. Paket FORWARD-a çatana qədər marşrut axtarışı artıq baş verib, buna görə orada MARK və ya DROP yalnız yenidən yaza və ya atə bilər. İşarə yönləndirilən trafik üçün PREROUTING-də, routerin özünün yaratdığı trafik üçün isə OUTPUT-da yer almalıdır, routerin DNS, NTP və yeniləmə yoxlamaları da orada yaşayır. Məhz bu çıxış yolu tam tunellənmiş quruluşun sızma testində hələ də ISP həlledicisindən cavab verməsinin adi səbəbidir.

Cihaz siyasəti sürüşməyən uyğunluq tələb edir. Ünvanı DHCP-də qoru və ya ayrı seqment üçün interfeys uyğunlaşdır; sonradan başqa cihaza keçən ünvan tuneli səssizcə yanlış müştəriyə tətbiq edir. Öz alt şəbəkəsi olan hər SSID üçün körpü eyni ideyanın daha davamlı versiyasıdır və IPv6 qaydalarına da yaşayacaq yer verir.

Üçüncü hissə: NAT, DNS və LAN istisnası

Tuneldən çıxan trafik uzaq tərəfin cavab verəcəyi mənbə ünvanına ehtiyac duyur. Tərcüməni tunel interfeysi ilə məhdudlaşdırın: RouterOS-da out-interface=VPN_NAME, Linux-da -o tun0, pfSense-də uyğun çıxan NAT yazısı. Bu məhdudiyyətsiz masquerade qaydası toxunulmaz qalmasını istədiyiniz trafiki yenidən yazır və simptom tunellənməmiş cihazın ictimai ünvanını itirməsidir.

LAN istisnası tunelin özündən daha çox dəstək müzakirəsinə səbəb olur. İşarələnmiş cədvəldə yalnız əsas marşrut varsa, seçilmiş cihazın printer və ya NAS təyinatı həmin əsas marşruta uyğun gəlir və tuneldə yox olur. LAN marşrutunu eyni cədvələ əlavə edin və ya yerli alt şəbəkəni seçicidə istisna edin; ikisi də işləyir və sonradan VLAN-lar əlavə edəndə istisnanı düzgün saxlamaq daha asandır.

DNS ayrı yol tutur. Routerin yönləndirdiyi sorğular routerdən yaranır və yönləndirilmiş işarəyə deyil, OUTPUT-a tabedir, buna görə tam tunellənmiş noutbuk hələ də ISP vasitəsilə həll edə bilər. Müştəriləri tuneldən əlçatan həllediciyə yönəldin və ya routerin öz port-53 trafikini işarələyin, sonra cavabın veb sorğu ilə birlikdə getdiyini fərz etmək əvəzinə həll olunmuş ünvanı yoxlayın.

Qayda uyğun gələndə, amma tətbiq hələ də WAN istifadə edəndə

Təyinat siyahıları tez köhnəlir. Ad siyahıda olmayan ünvana həll olunur, buna görə sorğu WAN-a gedir, halbuki siyahıdakı ünvana qarşı etdiyiniz hər test işləyirdi. Siyahını müştərinin istifadə etdiyi həlledicidən yeniləyin və həqiqətən bir cihazdan bütün trafiki istəyəndə mənbəyə əsaslanan seçiciyə üstünlük verin.

IPv6 sakit yan keçiddir. Cihazın öz əsas marşrutu və öz qayda dəsti olan ikinci ünvan ailəsi var və yalnız IPv4 ünvanını uyğunlaşdırmaq siyasətin yarısıdır. Eyni seçicini ip6tables və ya nftables ekvivalentinə tətbiq edin, ya da o seqmentdə IPv6-ı təsadüfən deyil, qəsdən söndürün.

Qurulmuş bağlantılar da vacibdir. Dəyişiklikdən əvvəl yaradılmış conntrack yazısı bitənə qədər köhnə yolu izləyir, buna görə düzəliş zamanı açıq qalan brauzer heç vaxt tətbiq olunmamış qayda kimi görünür. Siyasəti qiymətləndirməzdən əvvəl təzə bağlantı açın və ya vəziyyəti təmizləyin.

İki cihaz və yenidən başlatma ilə yoxlayın

Tunellənməli olan cihazı və olmamalı olan cihazı sınayın və sürət rəqəmi əvəzinə ikinci hopu müqayisə edin. Hər birindən traceroute ikinci hopda ya tunel şlüzünü, ya da ISP şlüzünü göstərir; əgər ikisi eyni görünürsə, işarə və ya cədvəl qaydanın dediyini etmir. Test üçün yeni bağlantılardan istifadə edin.

Sonra yenidən başladın. İşə salma sırası işlək siyasətin pozulduğu yerdir, çünki müştəri çatılmayan marşrut quraşdırılmadan əvvəl işlək olmalıdır və köhnə qayda dəstini bərpa edən yadda saxlanmış snapshot cədvəlinizin üzərinə yazacaq. Hər qaydanın saxlanmış konfiqurasiyada olduğunu və işarələnmiş əsas marşrutun yalnız yazdıqdan sonra deyil, yükləmədən sonra da mövcud olduğunu yoxlayın.

Bir şey sıradan çıxsa, əvvəlcə işarəni silin və normal trafikin qayıdıb-qayıtmadığına baxın, sonra cədvəli silin. Bu sıra sizə deyir ki, marşrut problemi, yoxsa firewall problemi araşdırırsınız, və işi bitirərkən evi işlək printerlə qoyur.