Windows VPN marşrut cədvəliniz niyə 0.0.0.0/1 və 128.0.0.0/1 göstərir

Windows VPN-ə qoşulun və marşrut cədvəlini açın, iki giriş diqqəti çəkir: 0.0.0.0/1 və 128.0.0.0/1. Bunlar yazı səhvi deyil və standart marşrutu əvəz etmir. Onların görünüb-görünməməsi bir profil seçimindən asılıdır və bu cüt tam tunelin necə qurulduğunu göstərir, bölünmüş tunel xüsusiyyəti deyil. Bir sətir dəyişməzdən əvvəl seçimi, prefiksi və interfeysi birlikdə oxuyun.

Standart şlüz seçimi nə quraşdırır

Hər şeyi tuneldən keçirən profil seçimi həmin iki prefiksi əlavə etməklə işləyir. Seçimi sildikdə onlar yox olur və yalnız tunel adapterinə verilən alt şəbəkəni əhatə edən marşrut qalır. Onay qutusu cütü idarə edir; tək standart marşrutu yenidən yazmır. Buna görə işarəni götürdükdən sonra cədvəl silinmə kimi deyil, qismən yenidən yazma kimi görünür.

0.0.0.0/1 IPv4 fəzasının aşağı yarısını, 128.0.0.0/1 yuxarı yarısını əhatə edir, birlikdə isə hər unikast ünvanı əhatə edirlər. Hər biri 0.0.0.0/0 standartından daha dəqiqdir, yəni ən uzun prefiks uyğunluğu adi trafiki tunelə göndərir, fiziki standart marşrut isə olduğu yerdə qalır. O standartı saxlamaq kosmetik deyil: şifrələnmiş yükü bükən paketlər serverin ictimai ünvanına ünvanlanır və fiziki adapterdən çıxmalıdır. Standartı bölmək əvəzinə onu əvəz etsəniz, tunelin öz nəqli tunelə girməyə çalışır, bu isə əlaqə deyil, dövrədir.

Ona görə VPN adapterinə yönələn hərfi 0.0.0.0/0 marşrutu dayanmağa dəyər. Doğma klient bunu adətən yazmır, deməli əl ilə yaradılmış marşrut və ya başqa klientin konfiqurasiyası cədvəli arxanızca dəyişib. Aşağıdakı hər hansı sazlamağa başlamazdan əvvəl onu tapın.

Sökmə şlüzü saxlamaqdan ucuzdur

Sökmə iki girişin bir girişdən üstünlüyünün praktik arqumentidir. Klient qoşulmuş halda dəqiq iki marşruta sahibdir və qoşulma kəsiləndə onları silir, fiziki adapterin həmin anda saxladığını qoyub gedir. Tək standartı əvəz etmiş klient əvvəlki şlüzü yadda saxlamalı olardı və DHCP icarəsi dəyişdikdən sonra artıq mövcud olmayanı bərpa edə bilərdi. İki sahibli giriş belə vəziyyət daşımır.

Başqa klientlər də eyni dizayna gəlir. redirect-gateway def1 ilə OpenVPN profili standartı silmək əvəzinə həmin iki prefiksi quraşdırır və Windows klienti eyni marşrut səbəbindən bu naxışı izləyir.

Buna görə də bölünmə gözlədiyiniz halda cədvəl tam tunel kimi görünə bilər. Cüt tam tunelin qurulma üsuludur, bölünmüş tunel səhvinin sübutu deyil. Profil uzaq şlüzdən istifadəyə ayarlanıbsa, hər şey marşrutlanır, bir yerli tətbiq nəyə çatsa da.

Ən uzun prefiks istənilən metrikgdən əvvəl qalib gəlir

Prefiks uzunluğu axtarışı hər hansı digər sahədən əvvəl həll edir. Metrik yalnız eyni prefiksli marşrutlar arasında bərabərliyi pozur, ona görə /1 girişi metrik daha pis olsa da /0 standartını üstələyir. İnterfeys bağlanması isə iki marşrut eyni prefiksi böldükdə və Windows paketi hansı adapterin göndərəcəyini seçməli olduqda qalanı həll edir.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Bölünmüş tunel cədvəli fiziki standartı, iki yarım-standartı, tunel alt şəbəkəsinin marşrutunu və əlavə etdiyiniz istənilən ofis prefiksini saxlayır. Fiziki standart klientdən və profildən asılı olaraq daha aşağı və ya daha yüksək metrikgdə ola bilər və /1 cütü mövcud olduqca bu fərq heç nəyi dəyişmir. Cüt çıxarılan anda hər şey dəyişir, köhnəlmiş şlüz və ya səhv interfeys məhz o zaman üzə çıxır. Dəyişməsini gözlədiyiniz bir sətir yerinə bütün cədvəli oxuyun.

Ofis prefiksi üçün bir sahib seçin

Bölünmüş tunel üçün yalnız VPN-dən istifadə etməli olan prefiksi adlandırın və onu sahiblənmək üçün bir üsul seçin. Marşrutu təyin edilmiş tunel ünvanına yönəltmək o ünvan dəyişənə qədər işləyir, interfeysə bağlamaq isə ünvandan sağ çıxır, lakin profil yenidən qurulduqdan sonra indeks yenidən təyin olunanda pozulur. Profilə bağlı cmdlet hər iki problemi aradan qaldırır, qarşılığında profilə ehtiyac duyur.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

Cmdlet prefiksi adlandırılmış profilə bağlayır, ona görə marşrut bağlantı ilə görünür və onunla gedir, idarə olunan noutbuk bunu istəyir. Davamlı marşrut yenidən başlatmalardan və onu doğuran profildən uzun yaşayır, köhnə VPN-in illərlə girişlər buraxması belə olur. Hər prefiks üçün bir üsul seçin və seçimi qeyd edin, çünki eyni prefiks üçün davamlı marşrut üstəgəl profil marşrutu sökülmə zamanı açmaq ağrılı olan dublikatlar yaradır. Hansını seçsəniz də, sahiblik yalnız maşında deyil, biletdə görünməlidir.

Sahiblik bu bölmənin cavablandırdığı sualdır, sintaksis deyil. Bir prefiks üçün iki sahib qaçınılası uğursuzluq modelidir.

Vebsaytla deyil, təyinatla yoxlayın

Tuneldən keçməli olan təyinatı sınayın, çıxış ünvanı göstərən vebsaytı deyil. Find-NetRoute seçilmiş marşrutu və mənbə ünvanını qaytarır, beləliklə ofis prefiksinin yoxsa fiziki standartın qalib gəldiyini görürsünüz və sonra paylaşmanın özünü açırsınız.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Çıxış ünvanı saytı zəif yoxlamadır, çünki DNS, IPv6 və brauzer proksisi həmin sorğunu hər biri fərqli yolla göndərə bilər. IPv4 və IPv6 eyni dialoqda ayrı ayarlara malikdir və bir qutunu təmizləmək digər ailəni toxunulmaz qoyur, ona görə ikili yığın maşın IPv4 bölünmə marşrutunu izləyərkən IPv6-nı tuneldən keçirə bilər. Profili bölünmüş adlandırmazdan əvvəl hər iki ailəni yoxlayın. Marşrut düzdürsə və xidmət hələ də uğursuz olursa, qalan qat marşrutlaşdırma deyil, filtrləmədir.

Klient tərəfindən idarə olunan firewall mükəmməl marşrut cədvəli olduğu halda ofis alt şəbəkəsini bloklaya bilər. Bu siyasət profili yayan tərəfə aiddir, marşrutları redaktə edən şəxsə deyil.