შეუძლია მოძრავ VPN კლიენტს ოფისისთვის სერვისის ჰოსტინგი?

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

შემოსვლის მიმართულება არაფერს ამბობს სერვისის მიმართულებაზე

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

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

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

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

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

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

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

სახელები და მისამართები დიზაინის გადაწყვეტილებებია

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

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

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

გამოსცადეთ სერვისი და არა წევრობა

სამიზნიდან დაადასტურეთ, რა ისმენს და რომელ მისამართზე, შემდეგ დაადასტურეთ კარიბჭის ხედვა დაბრუნების გზაზე:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

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

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

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