Hairpin NAT: რატომ არ მუშაობს VPN-ის ბოლო წერტილი შიგნიდან

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

პაკეტი გადის გარეთ და ბრუნდება შიგნით

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

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

RFC 4787 აღწერს იმ ქცევას, რომელიც NAT-ისგან ამ შემთხვევაში მოსალოდნელია, და მოკლე ვერსიაა, რომ პრაქტიკაში ის არასავალდებულოა მაშინაც, როცა თეორიულად განსაზღვრულია. ზოგი როუტერი ამ პარამეტრს NAT loopback-ს უწოდებს, ზოგი hairpin NAT-ს ან NAT reflection-ს, ზოგი კი საერთოდ არაფერს აჩვენებს. როუტერი, რომელსაც ეს არ აქვს, არასწორად კონფიგურირებული არ არის; ის ჩვეულებრივ რამეს აკეთებს, და გამოსწორება სხვაგანაა. არ დაასკვნათ წარუმატებელი ლოკალური ტესტიდან, რომ საჯარო გადამისამართების წესი არასწორია.

შემოწმება 1: გამოსცადეთ ორი გზა ცალ-ცალკე

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

ზუსტი ლოკალური ტესტი ინარჩუნებს ჰოსტის სახელს და ცვლის მხოლოდ მისამართს: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ აგზავნის მოთხოვნას საჯარო მისამართზე და ამავდროულად წარმოადგენს სწორ სერვერის სახელს. ეს გამოყოფს სახელის გადაწყვეტის პრობლემას თარგმნის პრობლემისგან, რომლებიც ადვილად აირევა, როცა იგივე სახელი კაფედან მუშაობს. დააკვირდით, კლიენტი TCP კავშირზე ვარდება თუ მოგვიანებით TLS-ზე, რადგან პირველი თარგმნაზე მიუთითებს, მეორე კი იდენტობაზე.

შემოწმება 2: წაიკითხეთ, რას ხედავს სერვერი

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

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

შემოწმება 3: გაასწორეთ გარე გზის შეხების გარეშე

არსებობს სამი მხარდაჭერილი ფორმა, ზემოქმედების რადიუსის ზრდადობით. ყველაზე ვიწრო არის გაყოფილი DNS: გამოაქვეყნეთ შიდა ჩანაწერი, რომ იგივე სერვერის სახელი LAN-ის კლიენტებისთვის შიდა მისამართზე გადაწყდეს, რაც საჯარო გზას სრულად გვერდს უვლის. შემდეგია როუტერის დოკუმენტირებული loopback ან reflection პარამეტრის ჩართვა, თუ არსებობს, და მხოლოდ ამ სერვისზე გამოყენება. ყველაზე ფართოა source-NAT წესი როუტერზე, რომელიც გადაწერს LAN-იდან მომავალ ტრაფიკს სერვერისკენ, რომ პასუხი როუტერიდან დაბრუნდეს; Linux როუტერზე ეს არის MASQUERADE წესი POSTROUTING-ში, რომელიც ემთხვევა სერვერის მისამართსა და პორტს. სამივე გარე გზას ხელუხლებლად ტოვებს, და სწორედ ეს თვისება უნდა შენარჩუნდეს.

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

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

შემოწმება 4: შემდეგ გადაამოწმეთ ორივე გზა

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

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