რას ავლენს STUN პასუხი, როცა VPN როუტერზე მუშაობს
როუტერის გვირაბის მისამართი ბრაუზერის ლოკალური მისამართი არ არის. თვალყური ადევნეთ, როგორ მარშრუტდება და ითარგმნება თითოეული მოთხოვნა, სანამ წაიკითხავთ, რას აცნობებს ამრეკლავი.
როცა გვირაბი როუტერზეა, ბრაუზერის გამრთველ მანქანას გვირაბის ინტერფეისი საერთოდ არ აქვს. ჰკითხეთ ამ მანქანას მისი ლოკალური მისამართები და მიიღებთ კერძო LAN მისამართს და უკუღმა მარყუჟს, არაფერს, რაც VPN მისამართს ჰგავს. მიუხედავად ამისა, მეორე მხარეს მდგარ STUN სერვერს ჯერ კიდევ შეუძლია რაღაც მნიშვნელოვანი შეატყობინოს გზაზე, და რასაც ის აცნობებს, მთლიანად დამოკიდებულია იმაზე, როგორ მარშრუტდა და ითარგმნა სწორედ ეს მოთხოვნა.
ეს არის ის ნაწილი, რომელზეც შენელება ღირს. „ბრაუზერი VPN მისამართის მფლობელი არ არის“ პასუხობს ინტერფეისებზე დასმულ კითხვას, ხოლო არეკლილი მისამართი პასუხია თარგმანში გამავალ გზაზე. ორივეს არევა წარმოშობს გამჟღავნების შესახებ თავდაჯერებულ დასკვნებს, რომლებსაც მტკიცებულება არ უჭერს მხარს.
ორი მოწყობილობა, ინტერფეისების ორი ნაკრები
როუტერზე დაფუძნებულ აწყობაში გვირაბი როუტერზე მთავრდება და LAN კლიენტი ჩვეულებრივ ტრაფიკს თავის ნაგულისხმევ კარიბჭეს უგზავნის. კლიენტის ინტერფეისების სია მოკლე რჩება: ერთი კერძო მისამართი, შესაძლოა მეორე სხვა ქსელისთვის, და უკუღმა მარყუჟი. რისკი არ არის ის, რომ ერთ-ერთი მათგანი შემთხვევით გვირაბის მისამართია; რისკი ის არის, რომ მოთხოვნა გადის გზით, რომელიც თქვენ არ აგირჩევიათ.
ჰკითხეთ კლიენტს რომელ გზას გაივლის კონკრეტული დანიშნულება იმის ნაცვლად, რომ იკითხოთ, რა ინტერფეისები არსებობს. პასუხი ასახელებს კარიბჭეს და იმ წყაროს მისამართს, რომელსაც ბირთვი გამოიყენებდა, და ეს უკვე უფრო ინფორმატიულია, ვიდრე მისამართების ნებისმიერი ნუსხა.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsდოკუმენტაციის დიაპაზონები კარგი საცდელი დანიშნულებებია, რადგან ისინი არასოდეს იხსნება რეალურ სერვისში. შეადარეთ, რას ამბობს კლიენტი, იმას, რას ამბობს როუტერი, და ნებისმიერი შეუთანხმებლობა მიიღეთ როგორც მტკიცებულება, რომ პოლიტიკის მარშრუტიზაცია, გაყოფილი გვირაბის წესი ან მეორე ნაგულისხმევი მარშრუტი აკეთებს რაღაცას, რაც არ გაგითვალისწინებიათ.
რისი თქმა შეუძლია Binding პასუხს
RFC 8489 განსაზღვრავს Binding მოთხოვნას და პასუხს, სადაც სერვერი აცნობებს იმ წყაროს სატრანსპორტო მისამართს, რომელიც ამ მოთხოვნისთვის დააკვირდა. ეს არის განცხადება ერთ ხუთეულზე ერთ მომენტში, და არა კლიენტის ინტერფეისების აღწერა. ამიტომ ყველაფერი საინტერესო ხდება კლიენტსა და დაკვირვების წერტილს შორის.
ამ ნაპრალს ავსებს მარშრუტიზაცია და თარგმანი. როუტერი, რომელიც გამავალ ტრაფიკზე წყაროს NAT-ს აკეთებს, კლიენტის კერძო წყაროს ცვლის საკუთარი მისამართით გამავალ ინტერფეისზე. თუ ეს ინტერფეისი გვირაბია, ამრეკლავი ხედავს გვირაბის მისამართს. თუ პაკეტი გვირაბიდან გამორიცხულია, ამრეკლავი ხედავს იმას, რაც WAN-ის თარგმანმა წარმოქმნა. იგივე კლიენტი, იგივე ამრეკლავი, სხვა პასუხი.
სამი შემთხვევა, რომლებიც ერთნაირად გამოიყურება და არ არის
სასარგებლო განსხვავება არ არის საჯარო კერძოს წინააღმდეგ, არამედ ის, თუ რომელმა აღსრულების წერტილმა გაუმკლავდა პაკეტს. გაიარეთ შემთხვევები როუტერის საკუთარი ცხრილებით ღიად, რადგან ერთ ბრაუზერს შეუძლია სამივეს წარმოქმნა იმ წესის მიხედვით, რომლის დაწერაც დაგავიწყდათ.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
მხოლოდ მეორე შემთხვევა არღვევს მოთხოვნას, რომ გარკვეული ტრაფიკი არასოდეს გავიდეს პირდაპირ, და მხოლოდ პირველი და მესამე ავლენენ იდენტიფიკატორს გვირაბის მხრიდან. სამი სტრიქონიდან არც ერთი არ არის მტკიცება კონკრეტული მომწოდებლის ქცევაზე: კერძო ამრეკლავის საერთოდ ხელმისაწვდომობა დამოკიდებულია მარშრუტიზაციაზე, მეორე მხარის დაშვებულ IP მისამართებზე და firewall პოლიტიკაზე ორივე ბოლოში.
იმავე მომწოდებელთან ანგარიშის ქონა ამათგან არაფერს ამტკიცებს. ასევე ღირს გახსენება, რომ მარშრუტირებულმა მოთხოვნამ შეიძლება შეინარჩუნოს კლიენტის LAN წყარო, თუ არაფერი თარგმნის მას, ამიტომ წყაროს ველს უნდა ადევნოთ თვალყური და არა ჩათვალოთ ტოპოლოგიის დიაგრამიდან.
შეგროვება არჩევა არ არის
WebRTC აგროვებს კანდიდატ მისამართებს გასასინჯად, და დიაგნოსტიკურ სიაში გამოჩენილმა კანდიდატმა შეიძლება არასოდეს ატაროს მედია. სიის წაკითხვა როგორც „ეს არის ის, რაც მეორე მხარემ ისწავლა“ გადაჭარბებულად აფასებს მტკიცებულებას. არჩეული წყვილი არის ის, რაც რეალურად ატარებდა სესიას, და ის სხვა ველში ცხოვრობს.
HTTPS გასასვლელის შემმოწმებელი პასუხობს კიდევ ერთ კითხვას: წყაროს იმ მისამართს, რომელიც ვებ სერვერმა დაინახა ამ მოთხოვნისთვის. ეს სასარგებლო ჯვარედინი შემოწმებაა სწორედ იმიტომ, რომ იყენებს სხვა პროტოკოლს და ხშირად სხვა დანიშნულებას, ვიდრე UDP ამრეკლავი, და ორივეს შორის შეუთანხმებლობა ჩვეულებრივ მიუთითებს მარშრუტიზაციის წესზე და არა ხარვეზზე.
გადაწყვიტეთ პოლიტიკა, შემდეგ წაიკითხეთ პასუხი
დაწერეთ განზრახვა ტესტამდე: რომელმა ტრაფიკმა უნდა გამოიყენოს გვირაბი, რომელს შეუძლია პირდაპირ გასვლა, რომელი მისამართების ოჯახებია მოცემულობაში, და რა უნდა მოხდეს, როცა გვირაბი გამორთულია. ამ საბაზისო ხაზის გარეშე ყოველი დაკვირვება ორაზროვანია, რადგან ვერ გამოყოფთ გაჟონვას იმ გზისგან, რომელიც შეგნებულად დაუშვით.
შემდეგ დასვით ერთი კითხვა ერთდროულად. რომელ გზას იღებს ეს დანიშნულება. რომელ მისამართს აცნობებს ეს ამრეკლავი. რომელი კანდიდატი წყვილი აირჩია სესიამ. შეინახეთ პასუხები პოლიტიკის გვერდით და დაათარიღეთ ისინი, რადგან პროგრამული უზრუნველყოფის განახლებამ შეიძლება შეცვალოს ნაგულისხმევი ქცევა ისე, რომ ჩუმად გააუქმოს გასული წლის დასკვნა.
როუტერი კვლავ ძლიერი აღსრულების წერტილია, რადგან ხედავს ტრაფიკს, რომელსაც კლიენტი ვერ გვერდს აუვლის საკუთარი თავის ხელახლა კონფიგურირების გარეშე. ეს არ არის დაპირება, რომ ყოველი ველი ყოველ აპლიკაციურ პროტოკოლში არაფერს ავლენს, და არ ცვლის იმ გზების ჩაწერას, რომელთა დაშვებაც აირჩიეთ.