Windows-ის NAT-T რეესტრის მნიშვნელობა: ჯერ ტოპოლოგია შეამოწმეთ

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

რას ირჩევს მნიშვნელობა სინამდვილეში

AssumeUDPEncapsulationContextOnSendRule განსაზღვრავს, ეცდება თუ არა Windows-ის IPsec რეალიზაცია ასოციაციების დამყარებას NAT მოწყობილობის მიღმა მყოფ პარტნიორთან. დოკუმენტირებული ნაგულისხმევი 0 არ უშვებს ამ შემთხვევას, 1 უშვებს, როცა სერვერი NAT-ის მიღმა მდებარე მხარეა, ხოლო 2 მოიცავს ორივე ბოლოს გადათარგმნას. ეს ტოპოლოგიის შესახებ განაცხადებია — ვინ სად არის.

თანმიმდევრობად წაკითხვისას რიცხვები აღწერენ უფრო მეტ თარგმანს და არა უფრო მეტ საიმედოობას. 2-ის დაყენება ქსელში, სადაც არაფერი ითარგმნება, კავშირს არ აჩქარებს და არ ასტაბილურებს, და ავთენტიფიკაციის ჩავარდნასაც არ ასწორებს. Microsoft-ის NAT-ის სახელმძღვანელო L2TP/IPsec-ისთვის აფიქსირებს პოლიტიკას და მის ისტორიულ პლატფორმულ კონტექსტს. შეადარეთ ეს კონტექსტი იმ Windows ვერსიასა და როლს, რომელსაც რეალურად უშვებთ, რადგან რამდენიმე გამოშვებას გადარჩენილი დოკუმენტი არ არის განაცხადი ყოველ მიმდინარე build-ზე.

შეუსაბამეთ ტოპოლოგია რიცხვამდე

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

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

ჯერ შეამოწმეთ ჩავარდნის ეტაპი

L2TP/IPsec წარმოქმნის სულ მცირე სამ განსხვავებულ ჩავარდნას: პარტნიორი მიუწვდომელია, IPsec დაცვა ვერ დამყარდება, და PPP მომხმარებლის ავთენტიფიკაცია უარყოფილია მას შემდეგ, რაც გვირაბი არსებობს. უარყოფილი ანგარიში არ სწორდება NAT პოლიტიკის შეცვლით, და წინადადებების შეუთავსებლობა არ სწორდება გადატვირთვით.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

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

HTTPS-ზე SSTP-ს და მშობლიურ IKEv2-ს საკუთარი ჟურნალები და საკუთარი კონტროლი აქვთ. არც ერთი მათგანი არ ხდება NAT-traversal შემთხვევა მხოლოდ იმიტომ, რომ ისინიც Windows-ზე მუშაობენ.

შეასრულეთ ცვლილება დაბრუნების გზით

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

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