VPN Windows-da yerli LAN-ı bloklayır: marşrut, yoxsa müştəri siyasəti?

Masanızdakı printer, NAS və ya inkişaf qutusu iş VPN-i qoşulan anda cavab verməyi dayandırır. Bəzən bir marşrut əmri bunu saniyələr içində düzəldir; bəzən eyni marşrut düzgündür və paketlər yenə yox olur, yəni oxşar simptomlu fərqli bir problemə baxırsınız. Qərar üç suala gəlir və onları yanlış sırada vermək insanların bütün axşamı marşrutları silib yenidən əlavə etməklə keçirməsinin səbəbidir.

Hər hansı əmrdən əvvəl üç sual

Birinci: yerli prefiks üçün giriş varmı və o, fiziki adapterə işarə edirmi? İkinci: müştəri qoşulma anında şlüzdən yerli şəbəkə icazəsi və ya qadağası alırmı? Üçüncü: sizə yalnız LAN-a çıxan giriş lazımdır, yoxsa internetdəki nəyinsə də maşınınızda işləyən xidmətə çatması lazımdır?

Birinci sual marşrut xətasını filtrləmə xətasından ayırır. İkincisi marşrut düzəlişinin ümumiyyətlə işləməsinə icazə verildiyini deyir. Üçüncüsü təmiri dəyişir: marşrut çıxan trafiki düzəldir, çatılmayan gələn xidmət isə adətən dinləyici bağlaması və geri yol problemidir ki, marşrut onu daha da pisləşdirir.

Birinci sual: marşrut, filtr, yoxsa ad

Cədvəli ona bir şey əlavə etməzdən əvvəl oxuyun. İnterfeys indeksi vacibdir, çünki aşağıdakı hər marşrut əmri ona bağlanır:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Birbaşa qoşulmuş alt şəbəkə adətən tunel qalxarkən belə on-link marşrutunu saxlayır, yəni giriş mövcud ola bilər və trafik yenə də uğursuz ola bilər. Bu birləşmə marşrutlamadan sonra işləyən filtrin imzasıdır və ikinci, daha konkret marşrutun heç nəyi dəyişmədiyi haldır.

Ünvana və ada görə ayrı-ayrılıqda sınaqdan keçirin. Əgər ping 192.168.1.50 cavab verirsə və net view 192.168.1.50 vermirsə, marşrut cədvəli heç vaxt problem olmayıb: tunel həlledicini dəyişib və yerli ad artıq həll olunmur. Bunun üçün marşrut əlavə etmək boşa səydir.

İkinci sual: şlüz yerli LAN girişinə icazə verirmi?

Kommersiya müştərisi yalnız marşrutlar quraşdırmır. O, qoşulma anında siyasət alır və bu siyasət açıq yerli şəbəkə icazəsini ehtiva edə bilər. Cisco IPsec yerləşdirmələrində qrup siyasəti split-tunel ayarını və ayrıca yerli LAN giriş bayrağını daşıyır; müştəridəki onay qutusu şlüzün imtina edə biləcəyi bir xahişdir. AnyConnect-də profil split daxil etmə və istisna siyahılarına və eyni icazəyə nəzarət edir. Windows RRAS-da ekvivalentlər profildəki defolt şlüz seçimi və serverin təyin etdiyi statik marşrutlardır.

Bayraq söndürüldükdə sənədləşdirilmiş davranış budur ki, müştəri düzgün, daha konkret marşrut mövcud olsa da birbaşa qoşulmuş alt şəbəkəyə trafiki bloklayır. Bu həm də müştərinin sahibi olmadığı marşrutların əlavə etdikdən saniyələr sonra yox olmasının səbəbidir: müştəri ona qurulması tapşırılan vəziyyəti yenidən qurur, sizinlə mübarizə aparmır.

Müştəri jurnalı qərarı qoşulma anında qeyd edir və onu oxumaq maşındakı istənilən təcrübədən sürətlidir. Jurnal yerli girişin bloklandığını deyirsə, dayanın: heç bir əmr sətri düzəlişi buna dözmür və qalan yollar siyasət dəyişikliyi, resursa tunel vasitəsilə çatmaq və ya müştərini virtual maşında saxlamaq və hostu yerli şəbəkədə buraxmaqdır.

Üçüncü sual: hansı istiqamət lazımdır?

Yaxın cihaza çıxan trafik marşrut sualıdır. LAN prefiksini tunelin defolt marşrutunu üstələmək üçün kifayət qədər aşağı metrik ilə yerli şlüzə yönəldin:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

İkinci forma bir cihazı sabitləyir, bütün tələb bir ünvandırsa istədiyiniz budur. netsh ekvivalenti eyni qərarı indeks yerinə interfeys adı ilə qeyd edir:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Marşrut əmrləri ünvan və maska uyğun gəlmədikdə Parametr yanlışdır xətası ilə uğursuz olur, məsələn /24 maskalı host ünvanı. Alt şəbəkə marşrutu üçün şəbəkə ünvanını, tək host üçün host maskasını istifadə edin.

Gələn trafik fərqlidir. Eyni maşındakı VNC və ya SSH serveri gələn bağlantıya cavablar VPN şlüzündən çıxıb heç vaxt qayıtmadıqda əlçatmaz olur. Marşrutlara toxunmadan əvvəl xidmətin nəyi dinlədiyini yoxlayın:

netstat -ano | findstr :5900

Bir konkret ünvana bağlanmış dinləyici digər interfeysdə cavab verməyəcək. Onu bütün interfeyslərə bağlamaq, etibar etdiyiniz şəbəkəyə hədd qoyulmuş firewall qaydası ilə birlikdə verilən qəsdən qərardır. Yalnız bundan sonra marşrut təmiri geri yolu bərpa edir.

Uyğun gələn ən kiçik dəyişikliyi tətbiq edin

Digər ümumi addım IPv4 qabaqcıl xassələrində “Uzaq şəbəkədə defolt şlüzdən istifadə et” işarəsini götürməkdir. Bu internet trafikini yerli saxlayır, amma eyni anda iki şey edir: VPN defolt yol olmaqdan çıxır və müştəri uzaq şəbəkə üçün marşrutları, multicast daxil olmaqla, almağı dayandırır. İşarəni götürsəniz, server hər müştərinin ehtiyac duyduğu konkret uzaq prefiksləri itələməsə, uzaq LAN yox olur.

Bu asimmetriya iş sırasını müəyyən edir. Uzaq tərəf tam əlçatan qalmalıdırsa, uzaq alt şəbəkələri serverdən itələyin və yerli defolta toxunmayın. Serveri dəyişə bilmirsinizsə, tunelin təyin etdiyi ünvan vasitəsilə uzaq prefiksə davamlı marşrut əlavə edin və route print ilə prefiksin VPN interfeysinə, defoltun isə hələ də fiziki şlüzə işarə etdiyini yoxlayın.

Sonra təmirin yenidən qoşulmadan sağ çıxdığını təsdiqləyin, çünki davamlı olmayan marşrutlar adapterlə birlikdə ölür və hər qoşulmadan sonra işləyən skript onlar üçün dürüst yerdir. Eyni sessiyada bir yerli cihazı və bir uzaq resursu sınayın, ayrılın, yenidən qoşulun və yenidən sınayın. Marşrut düzgün görünərkən yerli cihaz hələ də uğursuz olursa, ikinci suala qayıdın: müştəri filtrləyir və cavab ikinci rəqabətli marşrut deyil, siyasət dəyişikliyidir.