Windows VPN 255.255.255.255 ni ko’rsatadi: maska noto’g’rimi?

Tunnel ulanadi, siz adapter tafsilotlarini ochasiz va maska 255.255.255.255 ni ko’rsatadi. Ofis LAN ning 255.255.255.0 bilan solishtirganda bu buzilgan ko’rinadi va xato odatda shu yerda boshlanadi. Nuqtadan nuqtaga ulanishda host maskasi mahalliy oxirning to’g’ri tavsifidir va uzoq tarmoqlar biriktirilgan subnet emas, marshrut sifatida keladi. Quyidagi tartib ikkala savolni ajratadi, shunda siz faqat ko’rsatilgan qiymatni tuzatish uchun ishlayotgan DHCP diapazonini qayta qurmaysiz.

Nuqtadan nuqtaga ulanish Ethernet segmenti emas

Ethernet interfeysi subnet maskasiga muhtoj, chunki o’sha diapazondagi har bir manzil bir xil kabelda potentsial ravishda yetib boriladi. PPP uslubidagi tunnelning narigi uchida aynan bitta hamkor bor. Efir domeni yo’q, ARP yo’q va mahalliy manzil diapazonni tavsiflashi uchun hech qanday sabab yo’q.

Bu model uchun manzil muzokaralari RFC 1332 hujjatida belgilangan bo’lib, u ikki uch o’z manzillari bo’yicha qanday kelishishini qamrab oladi. U qilmaydigan narsa — ofis LAN ni mijozga bevosita ulangan tarmoq sifatida berish. Mijoz ofis qayerdaligini ulanish orqali marshrutlar o’rnatib o’rganadi va yetib borish imkoniyatini aynan o’sha marshrutlar belgilaydi.

Bu ko’rgan har bir maskangiz to’g’ri degani emas. Noto’g’ri sozlangan mijoz ham g’alati manzillash hosil qilishi mumkin. Masala torroq: bu turdagi adapterda host maskasi kutilgan holat, shuning uchun o’zi nosozlik isboti emas.

1-qadam: interfeys modelini tasdiqlang

Nima deyishini baholashdan oldin adapter nima ekanini ko’ring. Tavsif satri drayverni aniqlaydi va tayinlangan manzildagi prefiks uzunligi mijoz nimani kelishganini tasdiqlaydi:

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,NlMtu

Uchinchi buyruq bahslarning ko’pini hal qiladi. Past maksimal uzatish birligi inkapsulyatsiyalangan ulanishga xos, Ethernetga o’xshash qiymat esa boshqa virtual adapter modeliga ishora qiladi. Agar tavsifda PPP yoki RAS drayveri ko’rsatilgan bo’lsa va prefiks 32 bo’lsa, siz yuqorida tasvirlangan dizaynni aynan ko’ryapsiz va maska haqida qayg’urishni to’xtatishingiz mumkin.

2-qadam: ishlamayotgan manzilning marshrutini o’qing

Yetib borish imkoniyati har bir manzil bo’yicha hal qilinadi va bitta ulangan interfeys bu haqda sizga hech narsa aytmaydi. Marshrutlar jadvalidan foydalanuvchi haqiqatan yetib bormoqchi bo’lgan manzilni so’rang:

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute to’g’ridan-to’g’ri javob: u tizim bu manzil uchun ishlatadigan interfeys va manba manzilini ko’rsatadi. Agar u tunnelni qaytarsa, o’sha hostga trafik tunneldan o’tadi va maska hech qachon muammo bo’lmagan.

Agar u jismoniy adapterni qaytarsa, ikkita nomzod marshrutni va ularning ko’rsatkichlarini solishtiring. Aniqroq mahalliy marshrut, boshqa mijozdan qolgan yozuv yoki jismoniy yo’ldagi past ko’rsatkich keng tunnel marshrutidan ustun keladi. Ko’rinadigan natija — qolgan hamma narsa ishlayotganda yetib bo’lmaydigan resurs. Uzunroq prefikslar doim yutadi, shuning uchun g’olib ko’pincha bir necha oy oldin kimdir qo’shib unutgan host marshruti bo’ladi.

Bu yerda ikkala yo’nalishni ham tekshiring. Server tomonga marshrut zarur, lekin yetarli emas, chunki javob ham tunneldan qaytishi kerak. Bir ichki host ishlab, boshqasi ishlamasa, farq odatda adapter sozlamalarida emas, shu jadvalda bo’ladi.

3-qadam: nom hal qilishni xizmatga kirishdan ajrating

Ulashishni ochmaydigan dastur ikki juda boshqacha bosqichdan birida muvaffaqiyatsiz bo’lishi mumkin. Nomni hal qiling, keyin manzilga yeting. Birinchisi muvaffaqiyatsiz bo’lib ikkinchisi ishlasa, tunnel joyida va hal qiluvchi emas:

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Muvaffaqiyatli manzil testi bilan muvaffaqiyatsiz nom testi muammoni hal qilishda joylashtiradi va ikkinchi buyruq tunnel interfeysi umuman server olganmi-yo’qmi ko’rsatadi. Ko’p mijozlar DNS ni tunnel konfiguratsiyasining bir qismi sifatida itarib yuboradi va bu itarilgan variantlarni e’tiborsiz qoldiradigan profil mashinani shaxsiy zonani ko’rmaydigan hal qiluvchi bilan qoldiradi.

Ishlayotgan manzilni doimiy tuzatish deb qabul qilmang. Manzil orqali ulanish nom hal qilishni chetlab o’tadi va dastur aks holda bajaradigan server identifikatsiyasini tekshirishni zaiflashtirishi mumkin. Bu vaqtinchalik yechim niqobidagi xavfsizlik regressiyasi. Undan nosozlikni joylashtirish uchun foydalaning, keyin hal qilishni tuzating.

Orqaga qaytarish: ko’rsatilgan qiymat uchun DHCP ni qayta qurmang

Agar manzil xizmatini o’zgartirishni allaqachon boshlagan bo’lsangiz, to’xtang va o’zgartirgan narsalaringizdan birortasi yuk ko’taruvchimi-yo’qmi tekshiring. Diapazonni qayta yaratish, ijara shartlarini qayta berish yoki hovuzni ko’chirish boshqa mijozlar bog’liq bo’lgan holatni o’zgartiradi va bularning hech biri nuqtadan nuqtaga adapterdagi host maskasi bilan oqlanmaydi.

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

Bularni har bir maqsadli o’zgarishdan keyin ishga tushiring va oldingi ishga tushirish bilan solishtiring. Foydali natija resursga hujjatlashtirilgan yo’l, maskasi ofis LAN ga o’xshaydigan adapter emas.

Keyin maska aslida nimani anglatganini yozib qo’ying, chunki keyingi odam xuddi shu muloqot oynasini ochadi va xuddi shu noto’g’ri xulosaga keladi. Profil eslatmalarida bitta gap, tunnel nuqtadan nuqtaga ekani va uzoq subnetlar marshrut sifatida kelishi haqida, keyingi safar butun tekshiruvni tejaydi.