OpenVPN sūta DNS, bet jūsu risinātājs to var arī nekad neredzēt

Klienta žurnāls rāda nosūtīto DNS serveri, tunelis ir savienots, un iekšējais nosaukums joprojām neizšķiras. Pašā nosūtīšanā nekas nav salūzis. Opcija ieradās, un operētājsistēmas risinātājs to nekad neizmantoja, jo lielākajā daļā Unix klientu OpenVPN nodod vērtību un atstāj lietojumprogrammu platformai.

Simptoms: žurnāls rāda DNS, un nosaukumi joprojām neizdodas

OpenVPN dhcp-option pārnēsā DNS un domēna informāciju, un klients ieraksta saņemto. Dažās implementācijās klients šos iestatījumus piemēro iekšēji; citās eksportē tos integrācijas skriptam vai tīkla servisam. Žurnāla rinda apraksta tikai pirmo stāsta pusi. Otrā puse notiek vietā, ko klients nekontrolē. Tur parasti mīt kļūme.

Tāpēc savienots tunelis un neizdevies iekšējais nosaukums tik bieži pastāv kopā. Vērtība ir, patērētājs trūkst vai ir nepareizi konfigurēts, un risinātājs klusi turpina izmantot publisko serveri, ko izmantoja pirms savienojuma.

Saņemts nav piemērots

Klients var ierakstīt nosūtīto DNS vērtību, kamēr sistēmas risinātājs joprojām pieder citam servisam. Pārlūkprogrammai var būt arī sava šifrētā DNS politika, kas pilnībā apiet sistēmas risinātāju, radot atmiņā paliekošo situāciju, kurā viena lietotne atrisina iekšējos nosaukumus, bet otra ne.

Pārbaudiet implementācijas atbalstīto integrāciju, nevis pieņemiet, ka katrs Unix klients pārraksta to pašu failu. Šis pieņēmums ir iemesls, kāpēc cilvēki rediģē risinātāja konfigurāciju, ko nekas nelasa.

Atrodiet risinātāja īpašnieku katrai platformai

Windows sistēmā nosaukumu izšķiršanas politikas tabula var novirzīt noteiktus sufiksus uz noteiktiem serveriem, un VPN klients tur var instalēt noteikumus. Pārbaudiet politiku, ne tikai adaptera DNS sarakstu. Linux sistēmā konfigurācija var piederēt NetworkManager vai systemd-resolved, un tas, kuram tā pieder, nosaka, ko saglabās atkārtots savienojums.

Nolasiet faktisko stāvokli ar rīku, kas patiešām atbild uz vaicājumiem: resolvectl query internal.example.net systemd-resolved saimniekā vai platformas ekvivalents. Pēc tam salīdziniet šo atbildi ar DNS serveri, kuru klienta žurnāls apgalvo, ka ir nosūtījis.

Izvairieties darbināt vairākus servisus, kas bez saskaņošanas pārraksta risinātāja iestatījumus. Divi īpašnieki rada rezultātu, kas šķiet intermitējošs, un katrs atkārtotais savienojums it kā nejauši to salabo vai salauž.

Skripti un foreign_option

OpenVPN eksportē nosūtītās opcijas skriptiem caur mainīgajiem ar nosaukumu foreign_option_N, un skripts var tās pārvērst risinātāja komandās. Šis izkārtojums ir atbalstīta integrācija, nevis automātiska uzvedība, un tas ir jāinstalē un jāizsauc klientā.

Ja paļaujaties uz skriptu, reģistrējiet tā izpildi un iziešanas statusu. Skripts, kas darbojas, bet klusi neizdodas, atstāj to pašu simptomu kā nekāds skripts, un to ir grūtāk pamanīt, jo konfigurācija izskatās pilnīga. Pārbaudiet skripta izvadi, nevis skripta failu. Esošs fails nav izpildīts skripts.

Pārbaudiet nosaukumu, nevis žurnālu

Pēc savienojuma pajautājiet klientam tikai iekšēju resursdatora nosaukumu, pēc tam publisku nosaukumu, pēc tam pārbaudiet, kurš serveris atbildēja. Strādājošā iestatījumā abas atbildes nāk no dažādām vietām, un abām jāsaskan ar dizainu.

Ja nosaukums izšķiras, bet serviss neizdodas, pārejiet pie maršrutēšanas un lietotņu piekļuves, nevis atkal mainiet DNS. OpenVPN rokasgrāmata dokumentē dhcp-option un skriptu vidi; izmantojiet to, lai apstiprinātu, kas jūsu klientam jāpiemēro, pirms rediģējat vēl vienu risinātāja failu.