რატომ შეწყვიტა თქვენმა split tunnel წესმა სერვისთან შესაბამისობა

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

რას ამაგრებს წესი და რას აბრუნებს DNS

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

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

სამი გზა, რომლითაც შესაბამისობა ირღვევა

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

ქეშირებული კავშირი მეოთხე ვარიანტია და ადვილი გამოტოვებადი. აპი შეიძლება ჯერ კიდევ საუბრობდეს მისამართთან, რომელიც საათის წინ ამოხსნა, რაც ნიშნავს, რომ თქვენი ახალი ძიება და მისი ღია socket არ თანხმდებიან, სად ცხოვრობს სერვისი.

წაიკითხეთ დანიშნულება, რომელსაც აპი რეალურად იყენებს

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

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

შეაკეთეთ მექანიზმი და არა სიმპტომი

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

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

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

გადაამოწმეთ განზრახვის ორივე ნახევარი

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

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

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