Windows VPN-ის მისამართის ველში პორტი მხოლოდ SSTP-ით მუშაობს

ველი სერვერის სახელი host:port არ არის. PPTP-ს, L2TP-ს და IKEv2-ს ფიქსირებული პორტები აქვთ; SSTP პორტს მხოლოდ სრული https:// URL-ის სახით იღებს, და 443-ის გადაგზავნა უფრო სუფთაა.

VPN სერვერი პასუხობს TCP 10443-ზე, Windows-ის ჩაშენებულ კლიენტს სწორი მონაცემები აქვს, და კავშირი მაინც წყდება DNS-ის ვადის გასვლის მსგავსი პაუზის შემდეგ. მიზეზი ჩვეულებრივ მისამართის ველია: vpn.example.com:10443-ის სერვერის სახელში ან მისამართში ჩაწერა აიძულებს Windows-ს მთელი სტრიქონი ჰოსტის სახელად წაიკითხოს, რადგან ეს უჯრა ზოგადი host:port შეყვანა არ არის. შესაძლებელია თუ არა პორტის იქ გამოხატვა, დამოკიდებულია პროფილის მიერ გამოყენებულ გვირაბის ტიპზე, და ოთხი ტიპიდან მხოლოდ ერთი განიხილავს მნიშვნელობას როგორც რაღაცას, რისი ანალიზიც შეუძლია.

რატომ არ არის მისამართის ველი host:port უჯრა

ამ ველის უკან მდგომი პროფილის თვისება ServerAddress-ია, და გვირაბის თითოეული ტიპი თავად წყვეტს, რა უნდა ქნას სტრიქონთან. მათგან სამს შესავსები პორტის პარამეტრი არ აქვს, ამიტომ ორწერტილი და რიცხვი უბრალოდ სიმბოლოებია სახელში, რომელიც ვერასდროს გადაწყდება. მეოთხე HTTPS-ზე მუშაობს, სადაც პორტი URL-ის ნაწილია, ამიტომ მნიშვნელობა იმ ფორმით უნდა დაიწეროს, რომელიც URL-ად გაანალიზდება.

ამიტომ შეცდომა სახელების გადაწყვეტას ჰგავს, და არა უარყოფილ კავშირს. მოსახსენებელი ცუდი პორტი არ არის, მხოლოდ არარსებული ჰოსტის სახელია, და შეცდომა მოდის მას შემდეგ, რაც გადამწყვეტი დანებდება. სერვერზე შეხებამდე შეამოწმეთ, რომელი გვირაბის ტიპს აცხადებს პროფილი.

სამი ტიპი ფიქსირებული პორტით

PPTP უკავშირდება TCP 1723-ს და შემდეგ გვირაბს GRE-ში, IP პროტოკოლ 47-ში ატარებს. L2TP/IPsec გვირაბისთვის იყენებს UDP 1701-ს, ხოლო IPsec-ისთვის UDP 500-ს და 4500-ს, სადაც 4500 NAT-ის გავლის პორტია. IKEv2 ასევე იყენებს UDP 500-ს და 4500-ს. ამ პროფილების არც ერთი არ აჩვენებს პორტის ველს ინტერფეისში არსად, და არც ერთი არ მოილაპარაკებს არასტანდარტულ პორტზე.

ამიტომ მორგებულ პორტზე მომსმენი სერვერი მიუწვდომელია ამ პროფილებისთვის, როგორც არ უნდა იყოს მისამართი დაწერილი. პრაქტიკული პასუხები ვიწროა: გამოაქვეყნეთ სტანდარტული პორტი სერვერზე, ან გადათარგმნეთ სტანდარტული პორტი მორგებულში მის წინ მდგარ მარშრუტიზატორზე. ორივე კლიენტის პროფილს ხელუხლებლად ტოვებს, რაც დიდად ღირს, როცა პროფილი პოლიტიკით ნაწილდება და არა ხელით იწერება.

SSTP-ს URL სჭირდება, არა სახელი

SSTP გამონაკლისია, რადგან TLS სესიის შიგნით მუშაობს. ველი URL-ად უნდა გაანალიზდეს: ჯერ https:// სქემა, შემდეგ ჰოსტი, შემდეგ ორწერტილი და პორტი. სქემის გარეშე Windows აგრძელებს მნიშვნელობის ჩვეულებრივ სახელად განხილვას და კავშირი იშლება ნებისმიერ TLS გაცვლამდე.

მიზეზი, რის გამოც ეს ხალხს აკვირვებს, არის ის, რომ ნაგულისხმევი პორტი შიშველ ჰოსტის სახელს იღებს. პროფილი, რომელსაც არასდროს დასჭირდა მორგებული პორტი, ამ წესს არასდროს ასწავლის, და პირველი ადამიანი, ვინც ერთს დაამატებს, ამას მარცხით აღმოაჩენს. შენახვის შემდეგ წაიკითხეთ შენახული მნიშვნელობა დიალოგის ნდობის ნაცვლად:

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress აჩვენებს ზუსტად იმას, რაც შეინახა. თუ ის ორწერტილიან შიშველ ჰოსტის სახელად იკითხება, პროფილმა არასდროს მიიღო URL და რამდენჯერც არ უნდა სცადოთ ხელახლა, ეს არ გამოსწორდება.

იგივე უჯრაში ჩასმული მწარმოებლის სინტაქსი

ზოგიერთი კარიბჭე ამ ველისთვის დამატებით კონვენციებს ადგენს, მაგალითად პორტის შემდეგ დამატებულ realm-ს ან მოთხოვნის პარამეტრებს, რომლებიც სერტიფიკატების დამუშავებას ცვლის. მათ ესმის ამ მწარმოებლის სერვერს და ზოგიერთ კონსტრუქციაში მის საკუთარ კლიენტს. ისინი Windows-ის პროფილის ფორმატის ნაწილი არ არის, და ჩაშენებულ პროფილში მათი ჩასმა ჩვეულებრივ იმავე ჩუმ სახელის შეცდომას იძლევა.

სერტიფიკატის შემოწმების გამომრთველ პარამეტრს მოეპყარით როგორც გაფრთხილებას და არა შესწორებას. თუ პროფილი მხოლოდ ამ პარამეტრით უკავშირდება, სერტიფიკატი არ ემთხვევა გამოყენებულ სახელს, და სწორი შეკეთება კარიბჭეზეა, და არა კლიენტში. პორტის შემდეგ realm-ს იგივე თვისება აქვს: ის რაღაცას აკეთებს მხოლოდ მაშინ, როცა მეორე მხარეს სერვერი მას ელის.

დაამტკიცეთ პორტი, შემდეგ წაიკითხეთ წარუმატებელი ეტაპი

სანამ პროფილს დაადანაშაულებთ, დაადასტურეთ, რომ კლიენტის ქსელიდან რაღაც იღებს TCP-ს ამ პორტზე:

Test-NetConnection vpn.example.com -Port 10443

წარმატება ამტკიცებს მსმენელს, და არა SSTP-ს. ვებ სერვერს, საპირისპირო პროქსის ან დატვირთვის გამანაწილებელს შეუძლია TCP ხელის ჩამორთმევა დაასრულოს და მაინც არ ილაპარაკოს SSTP-ზე, ამიტომ მწვანე ტესტი წითელ VPN-თან რეალური კომბინაციაა. შეადარეთ სერტიფიკატის სუბიექტი პროფილში არსებულ სახელს და შეამოწმეთ RasClient ჟურნალი იმ კონსტრუქციებში, სადაც ის არის, რადგან ის აფიქსირებს წარუმატებელ ეტაპს და არა ზოგად ვადის გასვლას.

შემდეგ განიხილეთ ის ვარიანტი, რომელიც პრობლემას დოკუმენტირების ნაცვლად გვერდს უვლის: გადაამისამართეთ TCP 443 გარედან VPN სერვერის 10443-ზე. მაშინ კლიენტი იყენებს ნაგულისხმევ პროფილს ყოველგვარი პორტის გარეშე, რაც ჩვეულებრივ ყველაზე სუფთა მოწყობაა მართული ფლოტისთვის და მორგებულ პორტს შიდა დეტალად ტოვებს.

დაკავშირებული სტატიები