Mesh Wi-Fi peykinin VPN marşrutlaşdırıcısından istifadə edib-etmədiyini necə yoxlamaq olar

Əsas marşrutlaşdırıcı ilə eyni Wi-Fi adına cavab verən peyk onun müştərilərinin paketlərinin hara getdiyi barədə demək olar ki, heç nə demir. Qovşaq radio və körpüdür, əksi sübut olunana qədər. Çıxışı hər müştərinin aldığı standart şlüz və onun qarşısındakı qovşağın ötürmə rejimi müəyyən edir. Bu beş yoxlamanı müştəridən bayıra doğru aparın, sürət testindən qalan təəssürat deyil, müdafiə edə biləcəyiniz cavab alacaqsınız.

Müştərinin həqiqətən aldığı şlüzü oxuyun

Müştəridə marşrut cədvəlini və qonşu cədvəlini çap edin. Standart marşrut trafiki ötürən ünvanı adlandırır; qonşu qeydi həmin ünvana sahib MAC-ı adlandırır. Marşrutlaşdırıcının cihaz siyahısını deyil, müştərini istifadə edin, çünki cihaz siyahısı əlaqələri göstərir, yolları yox.

ip route show default
ip -6 route show default
ip neigh show

Windows eyni faktları başqa formada çap edir: ipconfig /all standart şlüzü verir və arp -a MAC-ı verir. macOS-da route -n get default və arp -an eyni şeyi əhatə edir.

Bu şlüzü artıq bildiyiniz iki ünvanla müqayisə edin: əsas marşrutlaşdırıcının LAN ünvanı və peykin idarəetmə ünvanı. Şlüz marşrutlaşdırıcının LAN ünvanıdırsa, müştəri marşrutlaşdırıcıya körpü ilə qoşulub və marşrutlaşdırıcının həmin şəbəkə üçün siyasəti dəyişmədən qüvvədədir. Şlüz peykin ünvanıdırsa, peyk marşrutlaşdırma edir və marşrutlaşdırıcı müştərinin paketlərini heç vaxt LAN trafiki kimi görmür; qərar qovşaqda verilməlidir, əks halda heç verilmir.

Qovşağın həqiqətən hansı rejimdə olduğunu təsdiqləyin

Mesh məhsulları fərqli davranışlar üçün üç sözü təkrar istifadə edir, ona görə paketin yoluna tətbiqdəki etiketdən daha çox güvənin. Körpü və ya giriş nöqtəsi rejimi kadrları ötürür. Marşrutlaşdırıcı rejimi alt şəbəkəni bitirir və DHCP işlədir. Qonaq rejimi adətən müştəriləri öz qaydaları olan ayrı VLAN-da yerləşdirir. Başqa marşrutlaşdırıcının arxasında marşrutlaşdırıcı rejimində olan qovşaq ikiqat NAT-dır və onun müştəriləri VPN marşrutlaşdırıcısına artıq tərcümə olunmuş halda çatır, bu da mənbə ünvanına əsaslanan siyasəti zəiflədir.

MAC-ı müəyyən etmək üçün qovşaqdakı etiketi oxuyun və bununla müqayisə edin: ip neigh. İstehsalçılar əsas MAC-ı çap edir və hər radionun MAC-ını bir bayt artırmaqla çıxarır, ona görə son onaltılıq rəqəm fərqlənir; bütün ünvanı deyil, prefiksi müqayisə edin. Şlüzün MAC-ı marşrutlaşdırıcının LAN interfeysinə aiddirsə, qovşaq həmin müştəri üçün marşrutlaşdırma etmir.

Çıxışı marşrutlaşdırıcıda sübut edin, sürət testi ilə deyil

Tərcüməni yalnız marşrutlaşdırıcı tərəfinin vəziyyəti göstərir. OpenWrt-də siyasət qaydalarını və marşrut cədvəllərini sadalayın, sonra tunelin təzə handshake-i olduğunu təsdiqləyin:

ip rule show
ip route show table all | grep default
wg show

pfSense və ya OPNsense-də eyni sübutlar bunlardadır: pfctl -sr qaydalar üçün, pfctl -ss aktiv vəziyyətlər üçün və WireGuard-ın status səhifəsində tərəfdaş sayğacları üçün, buna uyğun olaraq: WireGuard müştəri sənədləri. Vəziyyət cədvəlini müştərinin ünvanı ilə süzün. Vəziyyət müştərini tunel ünvanına tərcümə olunmuş göstərirsə, trafik tunelin içindədir; WAN ünvanını göstərirsə, deyil, panelin nişanı nə deyirsə desin.

Müştəridən traceroute vəziyyət cədvəlinin verə bilmədiyi bir faktı əlavə edir: ilk atlama. İlk atlama marşrutlaşdırıcının LAN ünvanıdırsa, müştəri marşrutlaşdırıcıya birbaşa çatıb. Bu qovşağın ünvanıdırsa və ardınca başqa bir şəxsi atlama gəlirsə, siz marşrutlaşdırılmış seqmentdəsiniz və o ikinci atlama siyasəti saxlamalı olan cihazdır.

Qovşağın ünvandan başqa nə payladığına baxın

DHCP seçimləri icarə ilə birlikdə gedir, ona görə öz DHCP-sini verən qovşaq öz DNS-ini və öz IPv6 marşrutlaşdırıcı elanlarını da verə bilər. Buna görə müştəri tuneldən çıxa və yenə də qovşaqdakı həlledicilərə sorğu göndərə, ya da tunel siyasətinin heç vaxt əhatə etmədiyi qlobal IPv6 ünvanı ala bilər. İkisini də müştəridə çap edin:

cat /etc/resolv.conf
ip -6 addr show scope global

Həlledici qovşaqdırsa və qovşaq marşrutlaşdırıcıya ötürürsə, DNS tuneli izləyir. Qovşaq yerli həll edirsə və ya provayderin həlledicisinə işarə edirsə, HTTP etməsə belə sorğular tuneldən kənara çıxır. IPv6 da eyni sınağa layiqdir: qlobal ünvan və tuneli yan keçən standart marşrut sızma deməkdir, Mesh proqram təminatı isə tez-tez IPv6-nı açıq qoyur, halbuki VPN siyasəti yalnız IPv4-ü əhatə edir.

Tuneli qəsdən qırın, sonra nəticəni yazın

Tuneli aşağı salın və həmin qovşağa qoşulmuş müştərini izləyin, marşrutlaşdırıcının yanında oturan müştərini deyil. ping və curl qısa gözləmə müddəti ilə kifayətdir; sual trafikin dayanıb-dayanmadığı və ya WAN-a geri düşüb-düşmədiyidir. Tuneli marşrutlaşdırıcının öz xidmət əmri ilə dayandırın, məsələn wg-quick down wg0 və ya OpenVPN xidmətini dayandırmaqla, və sınağı qısa saxlayın.

Müştəri işləməyə davam edirsə, qovşaq və ya marşrutlaşdırıcı həmin seqment üçün açıq şəkildə sıradan çıxır və mesh kill switch-i səssizcə ləğv edib. Tuneli geri qaytarın, handshake sayğacının tərpəndiyini təsdiqləyin və üçüncü addımdaki vəziyyət cədvəli yoxlamasını təkrarlayın.

Hər qovşaq üçün bir sətir yazın: etiket, SSID, şlüz ünvanı, MAC prefiksi, çıxış təsdiqləndi bəli və ya xeyr, IPv6 əhatə olunub və tunel aşağı olanda davranış. Rouminq cavabın dəyişdiyi yerdir, ona görə həqiqətən istifadə etdiyiniz otaqları sınayın. Bir sətir digərləri ilə uyğun gəlmirsə, araşdırılmalı olan həmin qovşaqdır və düzəliş həmin sətrin şlüzünə sahib cihazda edilməlidir.