Windows VPN 255.255.255.255 göstərir: maskə səhvdir?
Nöqtədən-nöqtəyə tuneldə host maskası normaldır. İnterfeys modelini təsdiqləyin, uğursuz olan hostun marşrutunu oxuyun və DNS-i xidmət girişindən ayırın.
Tunel qoşulur, adapter detallarını açırsınız və maskə 255.255.255.255 göstərir. Ofis LAN-ının 255.255.255.0 ilə müqayisədə qırıq görünür və səhv adətən buradan başlayır. Nöqtədən-nöqtəyə bağlantıda host maskası yerli son nöqtənin düzgün təsviridir və uzaq şəbəkələr qoşulmuş alt şəbəkə kimi deyil, marşrut kimi gəlir. Aşağıdakı prosedur iki sualı ayırır ki, yalnız göstərilən dəyəri düzəltmək üçün işləyən DHCP sahəsini yenidən qurmayasınız.
Nöqtədən-nöqtəyə bağlantı Ethernet seqmenti deyil
Ethernet interfeysi alt şəbəkə maskasına ehtiyac duyur, çünki həmin aralıqdakı hər ünvan eyni kabeldə potensial olaraq əlçatandır. PPP üslubunda tunelin digər ucunda tam olaraq bir həmkarı var. Yayım domeni yoxdur, ARP yoxdur və yerli ünvanın bir aralığı təsvir etməsi üçün heç bir səbəb yoxdur.
Bu model üçün ünvan danışıqları RFC 1332 sənədində müəyyən edilib və iki ucun ünvanları barədə necə razılaşdığını əhatə edir. Etmədiyi şey ofis LAN-ını müştəriyə birbaşa qoşulmuş şəbəkə kimi verməkdir. Müştəri ofisin harada olduğunu bağlantı üzərindən marşrutlar quraşdıraraq öyrənir və əlçatanlığı əslində həmin marşrutlar müəyyən edir.
Bu, gördüyünüz hər maskənin düzgün olduğu demək deyil. Səhv konfiqurasiya edilmiş müştəri də qəribə ünvanlama yarada bilər. Məsələ daha dardır: bu tip adapterdə host maskası gözləniləndir, ona görə tək başına nasazlıq sübutu deyil.
Addım 1: interfeys modelini təsdiqləyin
Nə dediyini qiymətləndirməzdən əvvəl adapterin nə olduğuna baxın. Təsvir sətri drayveri müəyyən edir və təyin edilmiş ünvandakı prefiks uzunluğu müştərinin nəyi razılaşdırdığını təsdiqləyir:
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtuMübahisələrin çoxunu üçüncü əmr həll edir. Aşağı maksimum ötürmə vahidi kapsullaşdırılmış bağlantının xüsusiyyətidir, Ethernetə bənzər dəyər isə fərqli virtual adapter modelinə işarə edir. Təsvirdə PPP və ya RAS drayveri göstərilibsə və prefiks 32-dirsə, yuxarıda təsvir olunan dizaynı tam olaraq görürsünüz və maskə ilə bağlı narahatlığı dayandıra bilərsiniz.
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
Addım 2: uğursuz təyinatın marşrutunu oxuyun
Əlçatanlıq hər təyinat üzrə müəyyən edilir və bir qoşulmuş interfeys bu barədə sizə heç nə demir. Marşrut cədvəlindən birbaşa istifadəçinin həqiqətən çatmaq istədiyi ünvanı soruşun:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute birbaşa cavabdır: sistemin həmin təyinat üçün istifadə edəcəyi interfeysi və mənbə ünvanını göstərir. Tuneli qaytarırsa, həmin hosta trafik tuneldən keçir və maskə heç vaxt problem olmayıb.
Fiziki adapteri qaytarırsa, iki namizəd marşrutu və onların metrikalarını müqayisə edin. Daha dəqiq yerli marşrut, başqa müştəridən qalan qeyd və ya fiziki yolda daha aşağı metrika geniş tunel marşrutunu üstələyir. Görünən nəticə hər şey işləyərkən əlçatmaz olan resursdur. Daha uzun prefikslər həmişə qazanır, buna görə qalib çox vaxt aylar əvvəl kiminsə əlavə edib unutduğu host marşrutudur.
Burada hər iki istiqaməti də yoxlayın. Server tərəfinə marşrut zəruridir, lakin kifayət deyil, çünki cavab da tuneldən geri qayıtmalıdır. Bir daxili host işləyib digəri işləmədikdə, fərq adətən adapter konfiqurasiyasında deyil, bu cədvəldə olur.
Addım 3: ad həlletməsini xidmət girişindən ayırın
Paylaşımı açmayan tətbiq iki çox fərqli mərhələdən birində uğursuz ola bilər. Adı həll edin, sonra ünvana çatın. Birincisi uğursuz olub ikincisi işləsə, tunel qaydasındadır, həlledici isə deyil:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Uğurlu ünvan testi ilə uğursuz ad testi problemi həlletmədə lokallaşdırır və ikinci əmr tunel interfeysinin ümumiyyətlə server alıb-almadığını göstərir. Bir çox müştəri DNS-i tunel konfiqurasiyasının hissəsi kimi itələyir və bu itələnmiş seçimləri nəzərə almayan profil maşını şəxsi zonanı görməyən həlledici ilə buraxır.
İşləyən ünvanı daimi düzəliş kimi qəbul etməyin. Ünvanla qoşulmaq ad həlletməsini yan keçir və tətbiqin başqa cür edəcəyi server kimliyi yoxlamasını zəiflədə bilər. Bu, müvəqqəti həll kimi maskalanmış təhlükəsizlik geriləməsidir. Nasazlığı lokallaşdırmaq üçün istifadə edin, sonra həlletməni düzəldin.
Geri qaytarma: göstərilən dəyərə görə DHCP-ni yenidən qurmayın
Ünvan xidmətini dəyişməyə artıq başlamısınızsa, dayanın və dəyişdiyiniz hər hansı şeyin daşıyıcı olub-olmadığını yoxlayın. Sahəni yenidən yaratmaq, icarələri yenidən vermək və ya hovuzu köçürmək digər müştərilərin asılı olduğu vəziyyəti dəyişir və bunların heç biri nöqtədən-nöqtəyə adapterdəki host maskası ilə əsaslandırılmır.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Bunları hər hədəflənmiş dəyişiklikdən sonra işlədin və əvvəlki işə salma ilə müqayisə edin. Faydalı nəticə resursa sənədləşdirilmiş yoldur, maskəsi ofis LAN-ına bənzəyən adapter deyil.
Sonra maskənin əslində nə demək olduğunu yazın, çünki növbəti şəxs eyni dialoqu açacaq və eyni səhv nəticəyə gələcək. Profil qeydlərində bir cümlə, tunelin nöqtədən-nöqtəyə olduğunu və uzaq alt şəbəkələrin marşrut kimi gəldiyini söyləyərək növbəti dəfə bütün araşdırmanı qoruya bilər.