Nə üçün VPN dəyişikliyindən sonra router inzibatçısı cavab vermir

Routerdə bir tuneli sınamaq üçün marşrut və ya firewall qaydası dəyişdirdiniz və indi inzibatçı səhifəsi on dəqiqə əvvəl yaxşı işləyən noutbukdan cavab vermir. Adətən günah VPN-də axtarılır. Çox vaxt tunel sağlam olur və üç başqa şeydən biri sınır: routerin öz ünvanına geri marşrut yoxdur, sorğunu atan giriş siyasəti var, ya da müraciət etdiyiniz ünvanda dinləməyən veb xidməti var. Hər üçü brauzerdə eyni görünür, buna görə insanlar tuneli bir saat yenidən başladır və heç nə öyrənmir.

Əvvəlcə öldürməli olduğumuz mif budur: işləyən tunel içəri qayıtma yolu deyil. O, öz etibar sualları olan yeni şəbəkə qoşulmasıdır və köhnə idarəetmə yolunuzu səssizcə silib heç kimin nəzərdən keçirmədiyi yenilərini aça bilər.

Tunel heç vaxt idarəetmə yolu olmayıb

Yönləndirmə və giriş fərqli işlərdir. "Müştəri tunel vasitəsilə NAS-a çata bilirmi?" routerdən keçən paketlər haqqında yönləndirmə sualıdır. "Routerin SSH portunu aça bilərəmmi?" routerin özünə ünvanlanmış paketlər haqqında giriş sualıdır. Yönləndirilən trafik üçün yazılmış icazə qaydası ikinci sual üçün heç nə etmir və trafiki mükəmməl daşıyan tunelin hələ də inzibatçı sessiyanızı rədd etməsinin ən çox yayılmış səbəbi budur.

Əks səhv interfeys adına güvənməkdir. Tunel qarşı tərəfə şifrələnir, onun arxasındakı hər xidmətə deyil və interfeys etiketindəki VPN sözü hansı mənbələrin daxil ola biləcəyi barədə heç nə demir.

Birinci qat: routerin öz ünvanına marşrut varmı?

Müştəridə başlayın və kerneldən paketin hara gedəcəyini soruşun. Linuxda ip route get 10.6.0.1 seçilmiş marşrutu, çıxış interfeysini və mənbə ünvanını çap edir. Əgər provayderinizə doğru standart marşrutu göstərirsə, paket heç vaxt tunelə daxil olmur və routerdə heç bir qayda onu xilas edə bilməz.

Tunel tərəfinin sualın öz versiyası var. WireGuard AllowedIPs-i kriptoaçar marşrut cədvəli kimi qəbul edir: hər tərəfdə qarşı tərəfin hansı mənbə ünvanlarından istifadə edə biləcəyini və hansı təyinatların o qarşı tərəfə göndəriləcəyini bildirir. Əgər müştəri qeydi routerin tunel ünvanını əhatə etmirsə, müştərinin ora marşrutu yoxdur. Əgər serverin həmin müştəri üçün qeydi müştərinin tunel ünvanını əhatə etmirsə, server hər hansı firewall qaydasına baxmadan paketi atır.

Siyasəti sazlamadan əvvəl çatmaq istədiyiniz dəqiq ünvanı təsdiqləyin. Köhnə DNS qeydi və ya dəyişiklikdən əvvəlki keşlənmiş qonşu qeydi sizi routerin heç vaxt sahib olmadığı ünvana göndərir.

İkinci qat: giriş siyasəti, yönləndirmə siyasəti deyil

Firewall-lar qaydaları paketin gəldiyi interfeysdə qiymətləndirir. pfSense və OPNsense-də interfeys sekmesi və qayda sırası firewallun öz xidmətlərinə trafikin icazəli olub-olmadığını müəyyən edir; LAN müştərilərini internetə buraxan qayda tunel qarşı tərəfinə veb GUI açmağa icazə verən qayda deyil. firewall4 ilə OpenWrt-də hər zona bir giriş siyasəti daşıyır, option input 'ACCEPT' və ya 'REJECT', və giriş siyasəti REJECT olan zonadakı tunel interfeysi idarəetmə bağlantılarını rədd edəcək, yönləndirməyə icazə verilirsə trafiki yenə də yönləndirəcək.

Yeni yolun işləməsi üçün anti-lockout qaydasını söndürməyin. O qayda LAN idarəetmə ünvanının pis qayda ilə bağlanmasının qarşısını alır; o, yenicə yaratdığınız tunel alt şəbəkəsini deyil, LAN alt şəbəkəsini qoruyur. İnzibatçı mənbəyi üçün bir dar qayda əlavə edin və təhlükəsizlik torunu toxunulmaz buraxın. pfSense inzibatçı girişi sənədləşməsi bu nəzarətlərin harada olduğunu izah edir.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Üçüncü qat: o ünvanda nə isə dinləyirmi?

Xidmət işləyə bilər və yenə də əlçatmaz ola bilər, çünki bir ünvana bağlanıb. OpenWrt-nin uhttpd-si /etc/config/uhttpd faylında açıq dinləmə qeydləri saxlayır, məsələn list listen_http '0.0.0.0:80'; yalnız LAN ünvanına bağlanan qurulum tunel ünvanında heç nə qəbul etmir və dinləmə interfeysi parametri təqdim edən məhsullar da eyni cür davranır. Yuxarıdakı dinləmə əmrləri buna birbaşa cavab verir.

Sonra rəddi sükutdan ayırın. nc -vz 10.6.0.1 443 əmrinin rədd edilmiş bağlantı qaytarması paketin routerə çatdığını və nəyinsə onu rədd etdiyini bildirir: ya bağlı port, ya açıq rədd qaydası. Vaxt aşımına qədər asılı qalma paketin atıldığını və ya heç vaxt marşrutsuz qaldığını göstərir. Bu fərq hansı qatı növbəti yoxlayacağınızı söyləyir və beş saniyə çəkir.

VPN interfeysi sərhəddir, bərpa yolu deyil

Şifrələmə naqili qoruyur; kimin inzibatçı səhifəsini aça biləcəyi barədə heç nə demir. Tunel işləyəndən sonra əlçatanlığı tunel interfeysində hər şeyə icazə verməklə həll etmək istəyinə qarşı durun. İnzibatçılara öz tunel ünvanlarına bağlı qayda və ya ayrıca yalnız-inzibatçı tuneli verin, adi istifadəçiləri, NAS-ı, kameraları və ailə noutbuklarını idarəetmə portundan uzaq saxlayın. Fayl paylaşımına ehtiyacı olan qarşı tərəf routerin girişindən bir qayda uzaqda olmamalıdır.

Routerin rolu cavabı dəyişir. Tuneli sonlandıran router ondan inzibatçıları qanuni şəkildə qəbul edə bilər, tuneli yalnız internet çıxışı kimi istifadə edən router isə adətən bunu etməməlidir. Hər iki halda alt şəbəkə icazəsi giriş deyil, ona görə hesab autentifikasiyasını və nəqliyyat təhlükəsizliyini yandırılmış saxlayın.

İnsanların blokdan sonra etdiyi kompensasiya hərəkəti daha pisdir: WAN idarəetməsini yandırmaq və ya veb GUI-yə port yönləndirmək. Bu, qısa kəsintini daimi məruz qalmaya çevirir və giriş səhifəsi artıq internetdəki hər skaner üçün əlçatan olur. İcazə verilən tərəfi olduğu kimi rədd edilən tərəfi də sınayın ki, inzibatçı girişi olmamalı olan qarşı tərəf giriş istəyi almaq əvəzinə vaxt aşımına düşsün və ya rədd edilsin.

Təzə bağlantı ilə də sınayın. Vəziyyətli firewall mövcud axınları öz vəziyyət cədvəlində saxlayır, buna görə artıq açıq olan SSH sessiyanız hər yeni bağlantını bloklayan dəyişiklikdən sağ çıxa bilər. Blokun növbəti yenidən başlatmaya və ya noutbukun növbəti yatmasına qədər görünməz qalması belə olur.

Siyasətə toxunmadan əvvəl geri yolunu hazırlayın

İlk dəyişiklikdən əvvəl dörd şeyi yazın: tunel ölərsə cihaza necə çatacağınızı, məsələn serial konsol, provayder konsolu və ya LAN-dakı maşın; cari konfiqurasiyanın hara ixrac olunduğunu; dəyişəcəyiniz tək qaydanı və ya marşrutu; və həmin elementi dəqiq necə geri qaytaracağınızı. OpenWrt-də sysupgrade -b /tmp/backup.tar.gz konfiqurasiyanı götürür və düzəlişlər uci commit çalışana qədər gözləyir, bu da vaxtında fərq etsəniz sizə ucuz geri qaytarma verir. pfSense konfiqurasiya tarixçəsi saxlayır və AutoConfigBackup yalnız əvvəlcədən yandırılıbsa kömək edir. Router fail-closed qayda dəsti ilə işləyirsə, planlaşdırdığınız texniki xidmət yolunun o qaydanın blokladığı trafikin içində olmadığını təsdiqləyin və yadda saxlayın ki, yenidən başlatma davamlı qaydaları təmizləmək əvəzinə yenidən tətbiq edir.

Hər cəhddə bir sərhəd dəyişin, sonra açıq saxladığınız shell əvəzinə yeni bağlantıdan sınayın. Sınaq uğursuz olarsa, növbəti qata toxunmadan o bir dəyişikliyi geri qaytarın. Tunel bütün müddət qalxa bilər, lakin onun yaşıl status ikonu hələ də içəri girə bildiyinizin sübutu deyil.

Uzaqlaşmadan əvvəl qısa yoxlama:

• Routerə yenicə dəyişdiyiniz qaydadan asılı olmayan mənbədən çata bilirsinizmi?
• Tunel interfeysindəki giriş siyasəti yalnız inzibatçı mənbəyinə icazə verirmi?
• İdarəetmə xidməti tuneldə mövcud olan ünvana bağlanıbmı?
• Bir rədd edilən qarşı tərəfi və bir təzə sessiyanı sınamısınızmı?
• WAN idarəetmə səthi hələ də bağlıdırmı?