რატომ არ ხსნის თქვენი VPN გვირაბის მისამართი შემავალ პორტს
გვირაბის მისამართი თქვენს კლიენტს იდენტიფიცირებს იმ პირებთან, რომლებსაც შეუძლიათ მასზე მარშრუტიზაცია, და არასდროს ქმნის მსმენელს. შეამოწმეთ მიბმა, დაბრუნების მარშრუტი, შემდეგ პოლიტიკა.
დაუკავშირდით ოფისის VPN-ს, გაუშვით პატარა სერვისი 8443 პორტზე, გაუგზავნეთ გვირაბის მისამართი კოლეგას და ნახეთ, როგორ ვერ ხდება კავშირი, მაშინ როცა კლიენტი კვლავ აცხადებს, რომ დაკავშირებულია. გვირაბში არაფერი გატეხილა: მისამართი გაცემულია, სესია აქტიურია, და პაკეტები, რომლებსაც პასუხი უნდა მიეტანათ, უბრალოდ არასდროს უშვებენ. შეასრულეთ ქვემოთ მოცემული სამი შემოწმება თანმიმდევრობით და გაჩერდით იმაზე, რომელიც ვერ გაივლის, რადგან თითოეულს განსხვავებული შესწორება აქვს და მხოლოდ ერთი მათგანი ეხება VPN-ს.
დაიწყეთ იქიდან, სადაც სოკეტი რეალურად არის მიბმული
სანამ რაიმე მარშრუტიზდება, რაღაც უნდა უსმენდეს მისამართზე, რომელზეც გამომძახებელს შეუძლია მისვლა. განვითარების სერვერები ჩვეულებრივი დამნაშავეები არიან, რადგან ბევრი მათგანი ნაგულისხმევად loopback-ზე იბმება და მხოლოდ იმავე მანქანიდან წამოსულ კავშირებს იღებს. გვირაბის მისამართი ამ მიბმას არ ცვლის და ოპერაციული სისტემა კავშირს უარყოფს ბევრად ადრე, ვიდრე VPN ჩაერთვება.
ss -ltnp | grep 8443
netstat -ano | findstr 8443წაიკითხეთ ადგილობრივი მისამართის სვეტი და არა მდგომარეობა. 127.0.0.1:8443 ნიშნავს მხოლოდ loopback-ს და შესწორებაა მიბმა 0.0.0.0-ზე ან თავად გვირაბის მისამართზე. 0.0.0.0:8443 ყველა ინტერფეისზე იღებს, რაც უფრო ფართოა, ვიდრე უმეტესობა გულისხმობს, როცა მანქანას საჯარო მისამართიც აქვს; 10.64.7.15:8443 არის ვიწრო ვერსია, რომელიც მხოლოდ იქ უსმენს, სადაც კოლეგას შეუძლია მისვლა. ყურადღება მიაქციეთ პროცესის სახელსაც იმავე გამოსავალში, რადგან წინა ტესტისგან დარჩენილი ზედმეტი ეგზემპლარი გავრცელებული მიზეზია, რომ პორტი ღიად ჩანს და არასწორი შიგთავსით პასუხობს.
შემდეგ ჰკითხეთ, შეუძლია თუ არა რაიმეს ამ მისამართზე მარშრუტიზაცია
გვირაბის მისამართს აზრი აქვს მხოლოდ იმ პირებისთვის, რომლებიც კონფიგურირებულნი არიან ამ პრეფიქსის გვირაბში გაგზავნაზე. კოლეგის მანქანას საკუთარი ცხრილი აქვს და თუ გვირაბის ქვექსელის მარშრუტი არ აქვს, პაკეტი ნაგულისხმევ კარიბჭესთან მიდის და იღუპება ადგილას, რომელმაც არ იცის მისამართის არსებობა. ეს გამომძახებლის მხარეს მარშრუტიზაციის საკითხია, არა ნებართვა თქვენს მხარეს.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
სერვერი ორ კლიენტს შორის არანაკლებ მნიშვნელოვანია. დისტანციური წვდომის ჩვეულებრივ დიზაინში თითოეული კლიენტი კარიბჭისკენ გამავალ კავშირს ხსნის და კარიბჭე ამ ნაკადების მდგომარეობას ინახავს, ამიტომ პასუხები იმ გზით ბრუნდება, რომელიც უკვე იცის. ერთი კლიენტიდან მეორესთან კავშირი ახალი ნაკადია, რომელიც კარიბჭემ უნდა მიიღოს და გადაამისამართოს, და ბევრი განლაგება ამას განზრახ თიშავს კლიენტების ერთმანეთისგან იზოლირებისთვის. სამომხმარებლო VPN სერვისები ჩვეულებრივ ნაგულისხმევად იზოლირებენ; კორპორატიული კარიბჭეები ზოგჯერ ჯგუფების მიხედვით უშვებენ.
შეამოწმეთ მიმართულება სანამ ჰოსტზე რაიმეს შეცვლით. თუ გვირაბის მისამართი პასუხობს თავად კარიბჭიდან, მაგრამ არა პირისგან, განსხვავება კარიბჭის კლიენტ-კლიენტის პარამეტრია და ადგილობრივი ფაირვოლის არც ერთი რედაქტირება ვერ შეცვლის მას.
დაბოლოს, იპოვეთ პოლიტიკა, რომელიც ნაკადს უშვებს
მარშრუტიზებულ პაკეტსა და პასუხის მომცემ სერვისს შორის სამი პოლიტიკის ფენა დგას: VPN სერვერის გადამისამართების გადაწყვეტილება, ჰოსტის ფაირვოლი და ეგზემპლარის წინ არსებული ნებისმიერი ღრუბლოვანი უსაფრთხოების ჯგუფი. სამივე უნდა შეთანხმდეს და ისინი სხვადასხვაგვარად ფუჭდებიან, ამიტომ ზემოთ ცხრილში მოცემული სიმპტომი უფრო სასარგებლოა, ვიდრე ბრაუზერის შეცდომის შეტყობინება.
ჰოსტის ფაირვოლი არის ფენა, რომელსაც ხალხი წარმატებული მიბმის შემდეგ ივიწყებს, რადგან LAN ინტერფეისზე პორტის დამშვები წესი მას გვირაბის ინტერფეისზე ავტომატურად არ უშვებს. ინტერფეისით შეზღუდული წესები სწორი დიზაინია და ამავე დროს ჩვეულებრივი მიზეზი იმ სერვისისა, რომელიც ოფისიდან მუშაობს და სახლიდან არა. წაიკითხეთ წესის ფარგლები და არა მისი პორტის ნომერი.
მდგომარეობაზე დაფუძნებული ფილტრაცია ხსნის საპირისპირო შემთხვევას. თქვენი ლეპტოპიდან გამავალი კავშირი ქმნის მდგომარეობას და მისი პასუხები შემავალი წესის გარეშე უშვებენ. კოლეგის კავშირი სრულიად ახალი ნაკადია მის უკან მდგომარეობის გარეშე, ამიტომ მას გამოკვეთილი ნებართვა სჭირდება. ეს ასიმეტრია არის სრული მიზეზი იმისა, რომ თქვენს მანქანაზე მომუშავე ბრაუზერის სესია არაფერს ამბობს იმაზე, არის თუ არა სერვისი გარედან ხელმისაწვდომი.
როცა ერთი შემოწმება ვერ გაივლის, შეცვალეთ დიზაინი და არა გვირაბი
თუ მოთხოვნაა, რომ კოლეგამ თქვენი ადგილობრივი სერვისი გახსნას, პატიოსანი პასუხი ჩვეულებრივ შემავალი წვდომისთვის აგებული მექანიზმია. უკუ SSH გვირაბი ყველაზე პატარაა: თქვენი მანქანა გარეთ უკავშირდება ჰოსტს, რომელზეც კოლეგას უკვე შეუძლია მისვლა, და მსმენელი სწორედ იმ ჰოსტზე არსებობს.
ssh -N -R 8443:127.0.0.1:8443 [email protected]რელეს სჭირდება GatewayPorts clientspecified თავისი SSH სერვერის კონფიგურაციაში, თორემ გადამისამართებული მსმენელი რელეზე loopback-ზე იბმება და კოლეგა იმავე უარს ხვდება, როგორც ადრე. ყველაფრისთვის, რაც ერთ შუადღეზე მეტხანს გრძელდება, დატვირთვის ბალანსირებელი ან ingress ჯანმრთელობის შემოწმებით და გამოქვეყნებული სახელის სერტიფიკატით უკეთესი ინსტრუმენტია, ხოლო საიტ-საიტ გვირაბი ორივე ქვექსელის მარშრუტებით სწორი პასუხია, როცა ორ ქსელს ნამდვილად სჭირდება საუბარი.
თითოეული ამ დიზაინიდან გამოვლენას გამოკვეთილს ხდის და ეს არის არსი. VPN პაკეტებს გადაადგილებს ქსელებს შორის, რომელთა გამოყენების უფლებაც უკვე გქონდათ; ის არ აქვეყნებს სერვისს და არ აქცევს ლეპტოპს ინტერნეტისკენ მიმართულ ჰოსტად. ამოცანაა გადაწყვიტოთ, სამი ფენიდან რომელი შეცვალოთ, და გვირაბი იშვიათად არის ერთ-ერთი მათგანი.