Windows VPN ünvan sahəsindəki port yalnız SSTP üçün işləyir
Server adı sahəsi host:port deyil. PPTP, L2TP və IKEv2 sabit portlardan istifadə edir; SSTP portu yalnız tam https:// URL kimi qəbul edir və 443-ü yönləndirmək daha təmizdir.
VPN serveri TCP 10443 üzərində cavab verir, Windows-un daxili klienti düzgün etimad məlumatlarına malikdir, amma bağlantı DNS taym-autuna bənzəyən fasilədən sonra yenə də kəsilir. Səbəb adətən ünvan sahəsidir: Server adı və ya ünvan sahəsinə vpn.example.com:10443 yazdıqda Windows bütün sətri host adı kimi oxuyur, çünki bu xana ümumi host:port girişi deyil. Portun orada ümumiyyətlə ifadə oluna bilməsi profilin istifadə etdiyi tunel növündən asılıdır və dörd növdən yalnız biri dəyəri təhlil edə bildiyi bir şey kimi qəbul edir.
Ünvan sahəsi niyə host:port xanası deyil
Bu sahənin arxasındakı profil xassəsi ServerAddress-dir və hər tunel növü sətirlə nə edəcəyini özü müəyyən edir. Onlardan üçünün doldurulacaq port parametri yoxdur, ona görə iki nöqtə və rəqəm sadəcə heç vaxt həll olunmayacaq bir addakı simvollardır. Dördüncüsü HTTPS üzərində işləyir, burada port URL-in hissəsidir, yəni dəyər URL kimi təhlil olunan formada yazılmalıdır.
Buna görə də nasazlıq ad həllinə bənzəyir, rədd edilmiş bağlantıya deyil. Bildiriləcək pis port yoxdur, sadəcə mövcud olmayan host adı var və xəta həlledici əl çəkdikdən sonra gəlir. Serverə toxunmazdan əvvəl profilin hansı tunel növündən istifadə etdiyini yoxlayın.
Sabit portu olan üç növ
PPTP TCP 1723-ə qoşulur və sonra tuneli GRE, IP protokolu 47 daxilində daşıyır. L2TP/IPsec tunel üçün UDP 1701, IPsec üçün isə UDP 500 və 4500 istifadə edir, 4500 NAT-traversal portudur. IKEv2 də UDP 500 və 4500 istifadə edir. Bu profillərin heç biri interfeysin heç bir yerində port sahəsi göstərmir və heç biri qeyri-standart port üzərində razılaşmır.
Beləliklə, fərdi portda dinləyən server ünvan necə yazılmasından asılı olmayaraq bu profillər üçün əlçatmazdır. Praktik cavablar azdır: standart portu serverdə dərc edin və ya onun qarşısındakı marşrutlaşdırıcıda standart portu fərdi porta çevirin. Hər ikisi müştəri profilini toxunulmaz saxlayır, bu da profil əl ilə yazılmaq əvəzinə siyasətlə yerləşdirildikdə çox dəyərlidir.
SSTP-yə ad deyil, URL lazımdır
SSTP istisnadır, çünki TLS sessiyası daxilində işləyir. Sahə URL kimi təhlil olunmalıdır: əvvəlcə https:// sxemi, sonra host, sonra iki nöqtə və port. Sxem olmadan Windows dəyəri adi ad kimi qəbul etməyə davam edir və hər hansı TLS mübadiləsindən əvvəl bağlantı uğursuz olur.
Bunun insanları təəccübləndirməsinin səbəbi standart portun çılpaq host adını qəbul etməsidir. Heç vaxt fərdi porta ehtiyac duymayan profil bu qaydanı öyrətməz və onu ilk əlavə edən şəxs bunu uğursuzluqla kəşf edir. Saxladıqdan sonra dialoqa güvənmək əvəzinə saxlanılan dəyəri geri oxuyun:
Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType
ServerAddress dəqiq saxlanılanı göstərir. Əgər içində iki nöqtə olan çılpaq host adı kimi oxunursa, profil heç vaxt URL almayıb və nə qədər təkrar cəhd etsəniz də bu düzəlməyəcək.
Eyni xanaya yapışdırılan vendor sintaksisi
Bəzi şlüzlar bu sahə üçün əlavə konvensiyalar sənədləşdirir, məsələn portdan sonra əlavə olunan realm və ya sertifikat emalını dəyişən sorğu parametrləri. Onlar həmin vendorun serveri və bəzi buraxılışlarda öz klienti tərəfindən başa düşülür. Onlar Windows profil formatının hissəsi deyil və daxili profilə yapışdırmaq adətən eyni səssiz ad nasazlığına səbəb olur.
Sertifikat yoxlamasını söndürən parametri düzəliş deyil, xəbərdarlıq kimi qəbul edin. Əgər profil yalnız bu parametrlə qoşulursa, sertifikat istifadə olunan ada uyğun gəlmir və düzgün təmir klientdə deyil, şlüzda aparılmalıdır. Portdan sonrakı realm də eyni xüsusiyyətə malikdir: yalnız qarşı tərəfdəki server onu gözləyirsə bir iş görür.
Portu sübut edin, sonra uğursuz mərhələni oxuyun
Profili günahlandırmazdan əvvəl müştərinin şəbəkəsindən həmin portda TCP-ni nəyinsə qəbul etdiyini təsdiqləyin:
Test-NetConnection vpn.example.com -Port 10443
Uğur dinləyicini sübut edir, SSTP-ni deyil. Veb serveri, tərs proxy və ya yük balanslaşdırıcısı TCP əl sıxışmasını tamamlaya və yenə də SSTP danışmaya bilər, ona görə yaşıl testlə qırmızı VPN real birləşmədir. Sertifikat subyektini profildəki adla müqayisə edin və onu göndərən buraxılışlarda RasClient jurnalına baxın, çünki o, ümumi taym-aut əvəzinə uğursuz olan mərhələni qeyd edir.
Sonra problemi sənədləşdirmək əvəzinə aradan qaldıran variantı nəzərdən keçirin: xaricdə TCP 443-ü VPN serverində 10443-ə yönləndirin. Onda klient heç bir port olmadan standart profildən istifadə edir, bu da idarə olunan donanma üçün adətən ən təmiz həlldir və fərdi portu daxili təfərrüat kimi saxlayır.