VPN qoşulmuş halda yerli şəbəkə əlçatmazdır? Dörd yoxlama

Tunel qalxır, intranet görünür və printer cavab verməkdən dayanır. Yerli şəbəkədə heç nə sıradan çıxmayıb; müştəri artıq yerli saymadığı ünvanlar üçün hansı yoldan istifadə etdiyini dəyişib. Aşağıdakı dörd yoxlamanı ardıcıl keçin və konkret uyğunsuzluq yaranan yerdə dayanın, çünki eyni simptomun dörd geniş yayılmış səbəbi var və onlardan yalnız biri VPN-i redaktə etməklə düzəlir.

Birinci, müştərinin quraşdırdığı marşrut cədvəlinə baxın

VPN qoşulmuş halda müştərinin marşrut cədvəlini açın. Linux-da ip route, Windows-da route print və ya Get-NetRoute, macOS-də isə netstat -rn istifadə edin. Siz tuneldən keçən standart marşrutu və fiziki standart marşruta nə olduğunu axtarırsınız.

Tam tunel müştərisi çox vaxt 0.0.0.0/0 əvəz etmək yerinə iki yarım-standart marşrut əlavə edir: 0.0.0.0/1 və 128.0.0.0/1. İlkin standart marşrut görünən qalır, lakin hər axtarışı itirir; buna görə cədvəl salamat görünə bilər, halbuki alt şəbəkədən kənar bütün trafik yer dəyişdirir. VPN müştərisi bölünmüş tunel seçimi təklif edirsə və siyasət buna icazə verirsə, ən təmiz düzəliş budur.

Tunel standart marşrut olaraq qalmalıdırsa, yerli alt şəbəkəni bərkidin. Linux-da marşrut fiziki interfeysi və şlüzü göstərir; Windows-da -p əlavə edin ki, davamlı olsun, və interfeys nömrəsini təxmin etmək yerinə route print çıxışından oxuyun:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Bərkidilmiş marşrut yalnız göstərdiyi ünvan dəyişməz qaldıqca işləyir. Hər qoşulmada Wi-Fi adapterini yenidən nömrələyən noutbuk qaydanı yenidən pozacaq, ona görə düzəlişin uğursuz olduğuna qərar verməzdən əvvəl interfeys ünvanını yoxlayın.

İkinci, ünvanın əvvəldən yerli olduğunu təsdiqləyin

Hədəf qoşulmuş alt şəbəkənin içindədirsə, tunelin standart marşrutu heç vaxt tətbiq olunmur və VPN səbəb deyil. 192.168.1.0/24 şəbəkəsinə sahib müştəridə 192.168.1.40 ünvanındakı printer qoşulmuş marşrutdan istifadə edir; bu ünvan uğursuz olursa, VPN-ə deyil, cihaza, kommutatora və ya müştəridəki firewall-a baxın.

İnsanları çaşdıran hal yerli server üçün ictimai ünvandır. Yerli şəbəkənin içindən router-in WAN ünvanına çatıb geri qayıtmaq üçün hairpin NAT tələb olunur və bir çox router port yönləndirmələri üçün bunu sadəcə tətbiq etmir. Şəxsi ünvanı ictimai ünvanın yanında sınayın. Şəxsi ünvan işləyirsə, ictimai işləmirsə, VPN yalnız artıq mövcud olan NAT məhdudiyyətini üzə çıxarıb.

Host adı vəziyyəti pisləşdirir. Yerli ad indi ictimai ünvana çevrilirsə, müştəri geri qayıda bilməyən yolu sınamağa davam edəcək. Test üçün şəxsi ünvandan istifadə edin, sonra başqa port yönləndirməsi əlavə etmək yerinə adı düzəldin.

Üçüncü, adlara indi kimin cavab verdiyinə baxın

Korporativ həlledici intraneti bilir və adətən NAS host adı, printerin Bonjour adı və ya router-in yerli ləqəbi haqqında heç nə bilmir. VPN öz DNS serverlərini itələdikdə, ünvanları hələ də əlçatan olsa da, bu adlar həll olunmaqdan qalır. Adı birbaşa sorğulayın və cavabı cihazın daşıdığını bildiyiniz ünvanla müqayisə edin.

Linux-da resolvectl query nas.local hansı həlledicinin cavab verdiyini göstərir. Windows-da nslookup nas.local serveri adlandırır, ipconfig /all isə həlledicilərin sırasını göstərir. Yerli şəkilçi artıq korporativ həlledici tərəfindən idarə olunursa, ya o şəkilçini yerli həllediciyə qaytarın, ya da cihaz üçün IP ünvanından istifadə edin.

Kəşf ayrı bir qatdır. mDNS və yayım marşrutlaşdırılmış tuneldən keçmir, ona görə cihaz ünvanla əlçatan ola bilər, adı isə görünməz qalar. Reflektor və ya yerli DNS qeydi bunu həll edir; marşrut etmir.

Dördüncü, digər maşının da VPN-də olub-olmadığını yoxlayın

Çatmaq istədiyiniz maşın da VPN müştərisi işlədirsə, sessiyanız gələ bilər, cavabı isə digər tuneldən çıxır. Bu, qurulan və sonra donan bir bağlantı, ya da sizin tərəfinizdə heç bir xəta olmadan vaxtı bitən RDP və SSH cəhdi yaradır. Müştərinizi günahlandırmazdan əvvəl digər hostun marşrut cədvəlini və standart yolunu yoxlayın.

Xidmətin dinlədiyi ünvanı da yoxlayın. Yalnız tunel ünvanına bağlanmış dinləyici VPN-dən gələn bağlantıları qəbul edir, yerli şəbəkədən gələnləri isə rədd edir, hətta marşrutlaşdırma mükəmməl olsa da. Bu, şəbəkə yolu deyil, xidmət konfiqurasiyasıdır və VPN ünvanına kilidlənmiş idarəetmə interfeyslərində geniş yayılmışdır.

Tuneldən asılı olmayan idarəetmə yolu saxlayın: mənbə şəbəkənizi göstərən statik marşrut, yerli şəbəkəyə qoşulmuş başqa interfeys və ya tuneli tamamilə yan keçən konsol. Bu yolu sessiya kəsiləndən sonra layihələndirmək növbəti qoşulmadan əvvəl əlavə etməkdən qat-qat çətindir.

Uğursuz olan yoxlamaya uyğun düzəlişi tətbiq edin

Marşrut cədvəli yarım-standart ələ keçirmə göstərdisə, siyasət icazə verəndə bölünmüş tunel, verməyəndə bərkidilmiş yerli marşrut seçin. Ünvan ictimai çıxdısa, testi və adı şəxsi ünvana keçirin. Həlledici əl dəyişdiribsə, yerli şəkilçini məhdudlaşdırın və ya ünvandan istifadə edin. Digər host tuneldədirsə, onun qayıdış yolunu və ya dinləyici bağlamasını düzəldin.

Bir şeyi dəyişin, sonra eyni yoxlamanı təkrarlayın. Səhv alt şəbəkə üçün əlavə edilmiş marşrut, yazı səhvi olan həlledici şəkilçisi və yenidən nömrələnən interfeysdəki bərkidilmiş marşrut ilkin nasazlıq kimi görünür. Təkrar düzəlişi təsadüfdən ayıran şeydir.

VPN qoşulmuş halda işləyən marşrutu, ünvanı və həlledicini yazın. Növbəti yenidən qoşulma onlardan ən azı birini dəyişəcək və qeyd növbəti kəsilməni yeni araşdırma yerinə qısa müqayisəyə çevirəcək.