OpenVPN-ის მიერ გაგზავნილი DNS იგნორირებულია: რომელი კომპონენტი იყენებს მას

ლოგი აჩვენებს სერვერის მიერ გაგზავნილ ოფციას, გვირაბი აქტიურია, და შიდა სახელები მაინც ვერ წყდება. პირდაპირი მოთხოვნა რეზოლვერზე პასუხობს, ასე რომ სერვერი რიგზეა, მაგრამ ყოველი აპლიკაცია მაინც ლოკალურ როუტერს ეკითხება. კლიენტამდე მისული შეთავაზებაა და არა ცვლილება რეზოლვერში, და სახელების გარჩევის მფლობელი კომპონენტი Linux-ზე, Windows-სა და macOS-ზე განსხვავდება. როგორც კი ოფციას მის მფლობელს გამოაცალკევებთ, ოთხი ხარვეზი ფარავს თითქმის ყველა მოხსენებას: hook არ არის, ორი კონკურენტი hook, გაყოფილი DNS მუშაობს როგორც დაპროექტებულია, ან მოკლე სახელს სერვერი კი არა, სუფიქსი სჭირდება.

გაგზავნილი ოფცია შეთავაზებაა, არა ინსტალაცია

სერვერზე ორი დირექტივა განზრახვას აღწერს და არა ეფექტს:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

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

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

დარწმუნდით, რომ გაგზავნა ჩავიდა, და იპოვეთ მფლობელი

დაიწყეთ გამშვების დასახელებით: შიშველი openvpn ბრძანება, systemd-ის ეგზემპლარი, NetworkManager ან მომწოდებლის კლიენტი. ეს განსაზღვრავს, სად შეიძლება იცხოვროს hook. systemd-resolved-იან ჰოსტზე, resolvectl status ჩამოთვლის ყოველ ბმულს რეალურად გამოყენებული DNS სერვერებითა და საძიებო დომენებით, და გვირაბის ბმულს ყოველთვის არ ჰქვია tun0.

თუ გაგზავნილი მისამართი ლოგშია, მაგრამ არც ერთ ბმულზე არ არის, ინტეგრაცია აკლია. თუ ის ბმულზეა და მოთხოვნები მაინც სხვაგან გადის, პრობლემა ისაა, რომელი მოთხოვნები ირჩევს იმ ბმულს. NetworkManager dns=dnsmasq ფაილში /etc/NetworkManager/NetworkManager.conf უშვებს ლოკალურ გადამცემს, რომელიც გაყოფილ DNS-ს განზრახ ახორციელებს: VPN დომენის შიგნით სახელები VPN რეზოლვერზე მიდის, დანარჩენი კი წინანდელ გზას ინარჩუნებს. ეს ქცევა ხარვეზად ჩანს, როცა ელოდით, რომ მთელი ტრაფიკი გადაადგილდებოდა; შეამოწმეთ კავშირისეული პარამეტრები ამით nmcli connection show "My VPN", სადაც ipv4.dns და ipv4.dns-search ინახავს მოწყობილობის მიერ მოხსენებულის უკან არსებულ მნიშვნელობებს, სანამ გატეხილს უწოდებთ. თუ ყოველი მოთხოვნა ნამდვილად უნდა აღწევდეს VPN რეზოლვერს, ამოიღეთ dns=dnsmasq -ი NetworkManager.conf ფაილიდან და გადატვირთეთ NetworkManager, რომელიც სახელების გარჩევას კავშირის პარამეტრებს უბრუნებს; წინააღმდეგ შემთხვევაში დატოვეთ გაყოფილი DNS და შეასწორეთ გაგზავნილი დომენების სია.

Linux: ოფციები რეზოლვერს გადაეცით

დისტრიბუციის პაკეტები ამისთვის hook-ს აწვდიან, და კლიენტს უნდა ჰქონდეს მისი გაშვების ნებართვა. ტიპიური განლაგება systemd-resolved-ის გარეშე ჰოსტზე:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved-ით ძველმა resolv.conf სკრიპტმა შეიძლება ვერაფერი მნიშვნელოვანი შეცვალოს, რადგან stub რეზოლვერი ბმულის მიხედვით ინახავს მდგომარეობას. update-systemd-resolved დამხმარე აღწერს hook-ის ფორმას, რომელიც იყენებს up-restart და down-pre, რაც მნიშვნელოვანია, როცა ინტერფეისი ერთ დაკავშირების ცდას გადაურჩება. რასაც არ უნდა აირჩიოთ, მდგომარეობას ერთი კომპონენტი უნდა ფლობდეს. NetworkManager-ის გვერდით უკავშირო hook-ის დამატება იმავე ბმულს ორ მწერალს აძლევს, და შედეგი მაშინ კონფიგურაციაზე კი არა, თანმიმდევრობაზეა დამოკიდებული.

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

Windows და macOS სხვადასხვა ნაწილს იყენებენ

Windows-ის კლიენტი ნამდვილად აყენებს VPN ადაპტერის DNS სერვერებს, მაგრამ Windows მაინც მეტრიკით ირჩევს ინტერფეისს და მაინც სჭირდება სუფიქსი მოკლე სახელის გასაშლელად. დაადასტურეთ ადაპტერის მდგომარეობა და არა პროფილი:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

თუ მისამართი აკლია, დააყენეთ ამით Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, შემდეგ დაამატეთ სუფიქსი ადაპტერის IPv4 თვისებებში, რომ fileserver გახდეს fileserver.corp.example. მანქანის მასშტაბის SearchList მნიშვნელობა Tcpip\Parameters -ის ქვეშ იგივეს აკეთებს. სადაც გრძელი სახელი წყდება, შიშველი კი არა, რეზოლვერი უკვე სწორია და ბრალი საძიებო სიას ეკისრება. შესწორებები თანმიმდევრობით: გაგზავნეთ DOMAIN რომ კლიენტმა სუფიქსი ისწავლოს, დაამატეთ ის სუფიქსი ადაპტერის ან კავშირის საძიებო სიას, და დროებითი ღონისძიების სახით ჩაამაგრეთ სახელი hosts ფაილში, ან LMHOSTS -ში Windows-ზე; NetBIOS-ის დათვალიერება როუტერს არ კვეთს, ამიტომ ოფისის LAN-ზე მოკლე სახელის პოვნელი მაუწყება გვირაბის კლიენტამდე ვერასოდეს აღწევს.

block-outside-dns block-outside-dns Windows-ის კლიენტის ქცევაა და არა გადატანადი პროფილის ხაზი, და Linux-ისა თუ macOS-ის პროფილში კოპირება მას იქ არ იმეორებს. თუ Windows-ზე საჯარო სახელები მუშაობს, შიდა კი ვერა, შეადარეთ ადაპტერების რიგი გაფართოებულ პარამეტრებში ამასთან ipconfig /all. macOS-ზე სერვისისეული რეზოლვერის რიგი სისტემას ეკუთვნის, ამიტომ გამოიყენეთ scutil --dns რომ ნახოთ, რომელი რეზოლვერი იკითხება რომელი დომენისთვის, და ნებისმიერი ცალკეული მოხსენებული პროფილის შესწორება კლიენტზე დამოკიდებულად მიიჩნიეთ და არა ზოგადად.

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

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

დაამტკიცეთ, სად წავიდა მოთხოვნა

ერთი ძებნის დროს გადაღება კამათს წყვეტს: tcpdump -ni eth0 port 53 აჩვენებს მოთხოვნებს ფიზიკურ ინტერფეისზე, რაც ნიშნავს, რომ ისინი გვირაბის გარეთ გადიან და რეზოლვერი არასოდეს შეცვლილა. dig @10.8.0.1 name.corp.example შემდეგ ჰყოფს დარჩენილ ორ შემთხვევას. თუ პირდაპირი მოთხოვნა პასუხობს, რეზოლვერი მუშაობს და კლიენტი მას არ იყენებს; თუ დრო ამოიწურა, რეზოლვერი გვირაბის გავლით მიუწვდომელია და ლოკალური ცვლილება ვერ დაეხმარება.

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

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

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

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

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