რომელი მისამართი უნდა ჩაიწეროს DNS-ში VPN-ით დაკავშირებული სერვერისთვის?
ჰოსტინგზე განთავსებულ სერვერს სამი მისამართი აქვს და ისინი ურთიერთშემცვლელნი არ არიან. აირჩიეთ მნიშვნელობა, რომელიც თითოეულ სერვისს სჭირდება, შემდეგ კი დაადასტურეთ იგი მანქანის გარედან.
ჰოსტინგზე განთავსებულ სერვერს, რომელზეც VPN არის დაყენებული, საბოლოოდ სამი მისამართი რჩება, და მათგან მხოლოდ ერთი ეკუთვნის თითოეულ იმ ადგილს, რომლის კონფიგურირებასაც აპირებთ. ნომრის პროვაიდერის პანელიდან DNS-ში, მსმენელში ან დაშვებულთა სიაში კოპირება ის გზაა, რომლითაც მომუშავე გვირაბი იქცევა სერვისად, რომელსაც ვერავინ მიაღწევს. ეს სახელმძღვანელო აწესრიგებს სამუშაოს ისე, რომ ყოველი მისამართი განსაზღვრული დანიშნულებისთვის შეირჩეს. ის ასევე ჩამოთვლის ბრძანებებს, რომლებიც ადასტურებენ, რა გამოაქვეყნეთ სინამდვილეში.
სანამ რაიმეს გამოაქვეყნებთ, სამი მისამართი დახაზეთ
დაარქვით მათ ფუნქციის მიხედვით. underlay მისამართი არის ის, რასაც მანქანა იყენებს VPN-ის საბოლოო წერტილამდე ინტერნეტის გავლით მისასვლელად, და ის ხშირად პროვაიდერის NAT-ის უკან კერძოა. გვირაბის მისამართი VPN-ის შიგნით ცხოვრობს და პროდუქტის მიხედვით სერვერი ან კლიენტი იძლევა. საჯარო გასასვლელია მისამართი, რომელსაც დისტანციური ვებსაიტი თარგმანის შემდეგ იწერს, და მას არ სჭირდება არსებობდეს არცერთ ინტერფეისზე, რომელსაც შეგიძლიათ ჰკითხოთ.
პანელი, რომელიც მანქანისთვის ერთ საჯარო მისამართს აჩვენებს, ძალიან ცოტას გეუბნებათ დანარჩენ ორ როლზე. underlay-ის მისადგომობა მოთხოვნაა და არა შესყიდვა: სახლის როუტერის უკან მდგარ ლეპტოპს შეუძლია ჰოსტინგზე განთავსებულ VPN-ის საბოლოო წერტილამდე მიაღწიოს საჯარო IPv4 მისამართის გარეშე. რასაც ვერ შეძლებთ, არის შემომავალი გზის გამოგონება იმ სახელის ჩაწერით, რომელიც იშლება მისამართად, რომელსაც არავინ გადასცემს.
აირჩიეთ მისამართი სერვისის მიხედვით და არა იარლიყის
ჩაწერეთ, რა უნდა გააკეთოს სერვერმა ნომრის არჩევამდე. გამავალ API გამოძახებებს სჭირდება სტაბილური გასასვლელი, როცა მეორე მხარე დაშვებულთა სიას აწარმოებს. კერძო წვდომას სჭირდება გვირაბის მისამართი, რომელზეც კლიენტებს შეუძლიათ მარშრუტიზაცია, და მასზე მიბმული მსმენელი. საჯარო ჰოსტინგს სჭირდება შემომავალი ასახვა, რომელსაც პროვაიდერი ნამდვილად სთავაზობს, და მხოლოდ გასასვლელის მისამართი ამას არ იძლევა.
ერთ მანქანას შეუძლია სამივე დანიშნულებას მოემსახუროს და მაინც სამი სხვადასხვა მისამართი გამოიყენოს. რაც ტყდება, არის ვარაუდი, რომ ერთი მნიშვნელობა ყველა მათგანს ფარავს:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
შემომავალი სტრიქონი არის ის, რაზეც ხალხი კამათობს. ჩანაწერი, რომელიც გასასვლელის მისამართზე მიუთითებს, არ ქმნის მსმენელს, ფაირვოლში ხვრელს ან პორტის ასახვას, და ლოდინი ამას არ ცვლის. როცა პროვაიდერი გამოყოფილ მისამართს შემომავალ წესთან ერთად ყიდის, სწორედ ეს პაკეტია ის შესაძლებლობა, რომელიც იყიდეთ; მხოლოდ მისამართი უფლება არ არის.
ბრძანებები, რომლებიც აჩვენებენ, რომელი მისამართი რომელია
წაიკითხეთ მანქანა და არა პანელი. ინტერფეისების სახელები სისტემებს შორის განსხვავდება, ამიტომ მისამართები მოწყობილობებს შეუსაბამეთ და ნუ დაეყრდნობით იარლიყს.
პირველი სტრიქონი ჩამოთვლის ყოველ IPv4 მისამართს და მის მოწყობილობას, ხოლო მეორე კითხულობს ბირთვს, რომელ მოწყობილობას გამოიყენებდა ცნობილი გარე დანიშნულებისთვის:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'თუ მარშრუტის ძიება საჯარო ტრაფიკისთვის გვირაბის მოწყობილობით პასუხობს, თქვენი სრული გვირაბი ძალაშია. მსმენელის შემოწმება თანაბრად მნიშვნელოვანია, რადგან მხოლოდ 127.0.0.1-ზე მიბმული პროცესი გვირაბის მისამართზე არასოდეს უპასუხებს, რა სახელსაც არ უნდა გამოაქვეყნოთ.
გამოაქვეყნეთ ის, შემდეგ კი გარედან გადაამოწმეთ
გამოაქვეყნეთ მხოლოდ ის მნიშვნელობა, რომელიც სერვისს სჭირდება: A ან AAAA ჩანაწერი ჰოსტინგისთვის, დაშვებულთა სიის ჩანაწერი გამავალი გამოძახებებისთვის, კლიენტის პროფილი კერძო წვდომისთვის. შემდეგ შეამოწმეთ იმ პოზიციიდან, რომელსაც მნიშვნელობა აქვს, და ეს არასოდეს არის ის მანქანა, რომელიც ახლახან შეასწორეთ.
ორი შემოწმება ფარავს უმეტესობას, და ორივე საკმარისად იაფია, რომ სკრიპტში შეინარჩუნოთ:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthDNS პასუხი, რომელიც ამტკიცებს, რომ თქვენი ჩანაწერი არსებობს, არ არის მტკიცებულება იმისა, რომ მოთხოვნა აღწევს, და ერთი წარმატებული მოთხოვნა მხოლოდ იმას ამტკიცებს, რომ ერთი გზა მუშაობს ერთი ქსელიდან. გაიმეორეთ შემოწმება მობილური კავშირიდან, როცა დაშვებულთა სიაა ჩართული, რადგან დაკვირვებული გასასვლელი შეიძლება დამოკიდებული იყოს მისამართების ოჯახზე და გავლილ მარშრუტზე. ჩაწერეთ, რომელი ოჯახი გადაამოწმეთ; მომუშავე IPv4 გზა IPv6-ზე საერთოდ არაფერს ამბობს.
თუ სერვისი შემომავალია, გასასვლელის მისამართი საკმარისი არ არის
შემომავალ წვდომას სჭირდება ოთხი რამ ერთ ხაზში: სახელი ან მისამართი, რომელზეც კლიენტს შეუძლია მიაღწიოს, მარშრუტი, რომელიც პაკეტს მანქანამდე მიიტანს, მსმენელი, რომელიც მიიღებს, და პოლიტიკა, რომელიც არ ჩამოაგდებს. VPN ცვლის მეორე ელემენტს და ზოგჯერ პირველსაც, ხოლო მესამე და მეოთხე ელემენტებისთვის არაფერს აკეთებს. როცა გვირაბი მიწოდების გზაა, კლიენტები გვირაბის მისამართზე უკავშირდებიან და არა გასასვლელს.
ჩაწერეთ, რომელ მისამართზეა დამოკიდებული თითოეული სერვისი, და გადახედეთ ამ ჩანაწერს ყოველთვის, როცა პროვაიდერი თავის მარშრუტიზაციის მოდელს შეცვლის. სერვერი, რომელიც კერძოდ პასუხობს და საჯაროდ მარცხდება, ჩვეულებრივ არ არის გატეხილი; ის არასწორი იდენტობით პასუხობს, და შეკეთება არის ასახვის გადაწყვეტილება და არა ფაირვოლის ცვლილება.