openfortivpn მუდამ გადაწერს DNS-ს? იპოვეთ ნამდვილი მფლობელი

მიჰყევით კავშირს იმ მომენტიდან, როცა ის ადის: კლიენტი ავთენტიფიკაციას ახდენს, pppd მოლაპარაკებას აწარმოებს, და შემდეგ რაღაც DNS-ის პარამეტრებს წერს ოპერაციულ სისტემაში. თუ მხოლოდ იცით, რომ VPN-მა თქვენი გამხსნელი შეცვალა, ჯერ არ იცით, ამ ეტაპებიდან რომელმა გააკეთა ეს. ორ მათგანს შეუძლია, და დოკუმენტირებული pppd ინტეგრაციის მქონე კლიენტზე ისინი ერთმანეთთან საკმარისად ახლოს მუშაობენ, რომ ერთ მოქმედად გამოიყურებოდნენ. მწერის დასახელება პირველი ნაბიჯია; მისი შემცვლელის არჩევა მეორე, და ეს ცალკე გადაწყვეტილებაა საკუთარი წარუმატებლობის რეჟიმებით.

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

დაიწყეთ იმით, რაც კავშირმა ნამდვილად შეცვალა

ერთხელ დაუკავშირდით თქვენი ჩვეული ბრძანებით და შეადარეთ გარჩევა უწინ და შემდეგ. systemd-resolved-ის მქონე Linux ჰოსტზე resolvectl status ბეჭდავს DNS სერვერებს და საძიებო დომენებს თითოეული ბმულისთვის, და საკუთარი სერვერების მქონე ახალი tun ან ppp ბმული კლიენტის მხრიდან განახლების ანაბეჭდია. macOS-ზე scutil --dns გამხსნელის კონფიგურაციას აჩვენებს იმ თანმიმდევრობით, რომლითაც აპლიკაციები მას კითხულობენ.

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

ორი გადამრთველი და მწერი, რომელსაც თითოეული აჩუმებს

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

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns ხელს უშლის კლიენტს გამოიყენოს DNS სერვერები, რომლებიც ჭიშკრიდან ისწავლა, ხოლო --pppd-no-peerdns ხელს უშლის pppd-ს პარტნიორის DNS სისტემაში შეიყვანოს. upstream-ის სახელმძღვანელო გაფრთხილებთ, რომ PPP-ის გავლით DNS განახლებები შეიძლება შეეჯიბროს კლიენტის საკუთარ DNS განახლებებს, ამიტომ ორივე გადამრთველი ფრაგმენტში უნდა იყოს, ნაცვლად იმისა, რომ ერთ-ერთი საკმარისად ჩაითვალოს.

არც ერთი გადამრთველი არ ასახელებს შემცვლელ გამხსნელს, და არც ერთი არ უშლის ხელს ქსელის მმართველს, DHCP კლიენტს ან ცალკე VPN ინტეგრაციას შემდგომში გარჩევის ჩაწერაში. ორი მწერის გაჩუმება ველს ღიად ტოვებს და არა დაკუთრებულად. თუ მესამე კომპონენტი უკვე მართავს DNS-ს, ფრაგმენტი ვერაფერს ცვლის, რისი დაკვირვებაც შეგიძლიათ; თუ არაფერი მართავს მას, თქვენ ახლახან წაშალეთ კერძო სახელების გარჩევის ერთადერთი წყარო. ეს ნამდვილი განლაგებაა მხოლოდ მაშინ, როცა შემცვლელი მფლობელი ჯერ არჩეულ იქნა და ცალკე გამოცდილ იქნა.

აირჩიეთ მფლობელი, სანამ რაიმეს გამორთავთ

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

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

შეამოწმეთ გარჩევა თითოეული ბმულისთვის, და არა ფაილისთვის

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

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

ხელახლა დაუკავშირდით და დაადასტურეთ გათიშული მდგომარეობა

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

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

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