OpenVPN uzspiestais DNS tiek ignorēts: kura komponente to piemēro

Žurnālā redzama servera uzspiestā opcija, tunelis darbojas, un iekšējie vārdi joprojām netiek izšķirti. Tiešs vaicājums risinātājam atbild, tātad serveris ir kārtībā, taču katra lietotne joprojām jautā vietējam maršrutētājam. Tas, kas nonāca pie klienta, ir piedāvājums, nevis izmaiņa risinātājā, un komponente, kurai pieder vārdu izšķiršana, Linux, Windows un macOS sistēmās atšķiras. Tiklīdz atdalāt opciju no tās īpašnieka, četras kļūdas aptver gandrīz katru ziņojumu: nav hook, divi konkurējoši hook, dalītais DNS darbojas kā projektēts, vai īsam vārdam vajag sufiksu, nevis serveri.

Uzspiestā opcija ir piedāvājums, nevis instalācija

Serverī divas direktīvas apraksta nodomu, nevis ietekmi:

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

Klients nesaņem konfigurētu risinātāju. Tas saņem vides mainīgos, foreign_option_1 un turpmākos, pa vienam par katru uzspiesto rindu, un kaut kam lokālam tie jāizlasa un jāpārraksta operētājsistēmas risinātāja stāvoklis. Linux sistēmā pēc noklusējuma nekas to nedara, tāpēc pareizs serveris un pievienots klients joprojām var izšķirt vārdus caur LAN.

Starp abiem galiem ir trīs posmi: uzspiešanai jānonāk, klientam tā jāatklāj, un hook tai jāpiemēro. Lasiet vidējo posmu klienta žurnālā un pēdējo risinātāja stāvoklī, nekad otrādi, jo žurnāla rinda pierāda tikai pirmos divus.

Pārliecinieties, ka uzspiešana nonāca, un atrodiet īpašnieku

Sāciet ar palaidēja nosaukšanu: vienkārša openvpn komanda, systemd instance, NetworkManager vai piegādātāja klients. Tas nosaka, kur hook var dzīvot. Uz resursdatora ar systemd-resolved, resolvectl status uzskaita katru saiti ar DNS serveriem un meklēšanas domēniem, ko tā faktiski izmanto, un tuneļa saite ne vienmēr saucas tun0.

Ja uzspiestā adrese ir žurnālā, bet nevienā saitē, integrācijas trūkst. Ja tā ir saitē un vaicājumi joprojām iziet citur, problēma ir tajā, kuri vaicājumi izvēlas šo saiti. NetworkManager dns=dnsmasq failā /etc/NetworkManager/NetworkManager.conf palaiž vietēju pāradresētāju, kas dalīto DNS īsteno apzināti: vārdi VPN domēnā iet uz VPN risinātāju, viss pārējais saglabā iepriekšējo ceļu. Šāda uzvedība izskatās kā kļūda, kad gaidījāt, ka pārvietosies viss trafiks; pārbaudiet katra savienojuma iestatījumus ar nmcli connection show "My VPN", kur ipv4.dns un ipv4.dns-search tur vērtības aiz tā, ko ierīce ziņo, pirms saukt to par salauztu. Ja ikvienam vaicājumam tiešām jāsasniedz VPN risinātājs, noņemiet dns=dnsmasq no NetworkManager.conf un restartējiet NetworkManager, kas atgriež vārdu izšķiršanu savienojuma iestatījumiem; citādi saglabājiet dalīto DNS un izlabojiet uzspiesto domēnu sarakstu.

Linux: nododiet opcijas risinātājam

Izplatījumu paketes tam piegādā hook, un klientam jābūt atļautam to izpildīt. Tipisks izvietojums resursdatorā bez systemd-resolved:

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

Ar systemd-resolved vecākais resolv.conf skripts var nemainīt neko svarīgu, jo stub risinātājs uztur stāvokli katrai saitei. update-systemd-resolved palīgs dokumentē hook formu, kas izmanto up-restart un down-pre, un tas ir svarīgi, kad saskarne pārdzīvo vienu savienošanās mēģinājumu. Ko vien izvēlaties, stāvoklim jāpieder vienai komponentei. Nesaistīta hook pievienošana NetworkManager malā dod divus rakstītājus vienai saitei, un rezultāts tad atkarīgs no secības, nevis no jūsu konfigurācijas.

Ir arī gadījums, kad NetworkManager pilnībā ignorēja uzspiesto opciju, līdz servera adrese tika ievadīta savienojuma IPv4 iestatījumos, un pēc tam risinātāja stāvoklis parādīja, ka tā tiek lietota. To ir vērts pamēģināt pirms skriptu pārrakstīšanas, jo tas pārvieto problēmu no shell hook uz savienojuma profilu, kas jau nes tuneli.

Windows un macOS piemēro dažādas daļas

Windows klients tiešām iestata VPN adaptera DNS serverus, bet Windows joprojām izvēlas saskarni pēc metrikas un joprojām vajag sufiksu, lai paplašinātu īsu vārdu. Pārbaudiet adaptera stāvokli, nevis profilu:

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

Ja adreses nav, iestatiet to ar Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, tad pievienojiet sufiksu adaptera IPv4 rekvizītiem, lai fileserver kļūtu fileserver.corp.example. Visas mašīnas SearchList vērtība Tcpip\Parameters apakšā dara to pašu. Kur garais vārds tiek izšķirts, bet kailais ne, risinātājs jau ir pareizs, un vaina ir meklēšanas sarakstā. Labojumi secībā: uzspiediet DOMAIN lai klients iemācītos sufiksu, pievienojiet šo sufiksu adaptera vai savienojuma meklēšanas sarakstam, un kā pagaidu pasākumu piespraudiet vārdu hosts failā, vai LMHOSTS sistēmā Windows; NetBIOS pārlūkošana nešķērso maršrutētāju, tāpēc apraide, kas biroja LAN atrod īsu vārdu, nekad nesasniedz tuneļa klientu.

block-outside-dns block-outside-dns ir Windows klienta uzvedība, nevis pārvietojama profila rinda, un kopēšana Linux vai macOS profilā to tur neatkārto. Ja Windows sistēmā publiskie vārdi strādā, bet iekšējie neizdodas, salīdziniet adapteru secību sadaļā Papildu iestatījumi ar ipconfig /all. macOS sistēmā risinātāju secība katram pakalpojumam pieder sistēmai, tāpēc izmantojiet scutil --dns lai redzētu, kurš risinātājs tiek jautāts kuram domēnam, un uzskatiet jebkuru atsevišķu ziņoto profila labojumu par atkarīgu no klienta, nevis vispārīgu.

Virtuālā mašīna tajā pašā klēpjdatorā neko no tā nemanto. Dodiet viesim savu risinātāja ierakstu iekšējam domēnam, vai ļaujiet hipervizora NAT pārsūtīt tā vaicājumus caur resursdatoru, un tas ir pareizi tikai tik ilgi, kamēr resursdatora tunelis darbojas.

Vēsture ir trešais iemesls. Iepriekšējā profila DNS serveri vai sufiksa iestatījumi var pārdzīvot atkārtotus savienojumus, tāpēc, kad adapters izskatās pareizi un meklēšana joprojām neizdodas, salīdziniet dzīvo adapteri ar Get-VpnConnection un izdzēsiet vai pārrakstiet novecojušo ierakstu, pirms aiztiecat serveri.

Pierādiet, kur vaicājums aizgāja

Uzņemšana vienas meklēšanas laikā izšķir strīdu: tcpdump -ni eth0 port 53 parāda vaicājumus fiziskajā saskarnē, kas nozīmē, ka tie iziet ārpus tuneļa un risinātājs nekad netika pārslēgts. dig @10.8.0.1 name.corp.example tad atdala divus atlikušos gadījumus. Ja tiešais vaicājums atbild, risinātājs strādā un klients to neizmanto; ja laiks beidzas, risinātājs caur tuneli nav sasniedzams un nekāds vietējs labojums nepalīdzēs.

Ja joprojām lietotais risinātājs ir tas, ko piešķīra pakalpojumu sniedzējs, tunelis šifrē trafiku, bet vārdi paliek redzami tam sniedzējam. Tas ir noplūdes, nevis funkcionalitātes jautājums, un tā pati uzņemšana uz to atbild: vaicājums fiziskajā saskarnē iet pie kāda ārpus tuneļa.

Sasniedzamība ietver VPN resursdatora ugunsmūri, kam jāatļauj UDP un TCP 53 no pūla. Aizvērts ports izskatās tieši kā salauzta uzspiešana, un tāpat arī risinātājs, kas atbild tikai no tuneļa tīkla iekšpuses. Atkārtojiet uzņemšanu pēc vienas atvienošanās un atkārtotas pievienošanās, jo iestatījumi, kas parādās pirmajā savienojumā un pazūd otrajā, ir hook dzīves cikla kļūda, nevis trūkstoša opcija.

Turiet vienu īpašnieku un pārbaudiet secībā

Skripts, kas pārraksta adaptera DNS, pamatojoties uz minētu tuneļa stāvokli, dublē konfigurāciju, ko profils jau nes, un klusi neizdodas pirmajā reizē, kad minējums ir nepareizs. Dodiet priekšroku paša savienojuma DNS iestatījumiem vai vienam dokumentētam hook, un pierakstiet, kuru izvēlējāties, lai nākamais cilvēks nepievienotu otru.

Noslēdziet ciklu ar četrām pārbaudēm: uzspiestā adrese ir tuneļa saitē, iekšējais vārds tiek izšķirts kā pilnīgi kvalificēts vārds, tas pats vārds tiek izšķirts bez sufiksa, un abi joprojām ir patiesi pēc vienas atkārtotas pievienošanās. Viena uzņemšana pasaka, kura no četrām neizdevās. OpenVPN 2.6 rokasgrāmata uzskaita dhcp-option un skriptu direktīvas ar to platformu piezīmēm.