Windows VPN-ზე ინტერნეტი არ არის? ეჭვმიტანილი მისამართების აუზია

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

წაიკითხე იჯარა სანამ შეცვლი

გაუშვი ipconfig /all კლიენტზე და მოძებნე VPN ადაპტერი ჩანაწერებს შორის. მის მიერ ჩამოთვლილი მისამართი, ნაგულისხმევი კარიბჭე და DNS სერვერი ის ფაქტებია, რომლებიც გჭირდება, და ისინი ხშირად განსხვავდება იმისგან, რაც ადმინისტრატორს ჰგონია, რომ გაიცა.

სამი ნიმუში სამ ხარვეზს შეესაბამება. მისამართი 169.254.0.0/16-ში ნიშნავს, რომ კლიენტმა საერთოდ არაფერი მიიღო და თავად მისცა საკუთარ თავს ბმულ-ლოკალური მისამართი. დამაჯერებელი მისამართი კარიბჭის გარეშე ნიშნავს, რომ აუზი მიეწოდა იმ ოპციის გარეშე, რომელიც კლიენტს ნაგულისხმევ მარშრუტს აძლევს. სრული იჯარა, რომელიც მაინც არსად აღწევს, მიუთითებს სერვერის მხარეს გადაგზავნაზე ან თარგმნაზე.

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

რატომ შეიძლება ავტომატურმა მინიჭებამ კარიბჭე დატოვოს

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

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

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

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

დააყენე ცხადი დიაპაზონი, რომელსაც სერვერი შეძლებს მარშრუტიზაციას

აირჩიე პატარა ბლოკი ქვექსელში, რომელსაც სერვერი აღწევს, LAN მარშრუტიზატორის მიერ განაწილებული დიაპაზონის გარეთ და ქსელის ნებისმიერი სხვა აუზის გარეთ. თუ სერვერი 172.20.10.0/24-ზე ზის და მარშრუტიზატორი ფლობს 172.20.10.1-ს, მოკლე ბლოკი ამ ქვექსელის ზედა ნაწილთან, ვთქვათ 172.20.10.201-დან 172.20.10.209-მდე, გვირაბის იჯარებს შორს ინახავს მარშრუტიზატორის უკვე მართული განაწილებისგან.

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

ეს ბრძანებები ბეჭდავს შედეგ კონფიგურაციას და მარშრუტებს, რომლებიც კლიენტს ახლა აქვს:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

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

მისამართი ინტერნეტის გზა არ არის

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

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

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

ჯერ გამორიცხე გარე გზა

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

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

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