Iekšējie nosaukumi neizpildās VPN, bet publiskās vietnes atveras

Viens lietotājs ziņo, ka intraneta resursdatora nosaukums VPN netiek izpildīts. Otrs ziņojums no tā paša portatīvā datora saka, ka noplūdes tests joprojām rāda atbildes no vietējā resolvera. Tie izklausās kā viena problēma, bet ir divi ar atšķirīgiem pierādījumiem, un parastais pirmā labojums otro padara sliktāku. Atdaliet tos pirms jebkura iestatījuma aiztikšanas.

Divi simptomi, kas nav viens bojājums

Neizdevusies iekšējā nosaukuma izpilde nozīmē, ka jautājums aizgāja tur, kur atbildes uz to nav. Vaicājumi, kas iziet no tuneļa, nozīmē, ka jautājums aizgāja nepareizajā vietā pat tad, kad atbilde bija pieejama. Tie ir pretēji bojājumi: viens ir trūkstoša atbilde, otrs ir lieks galamērķis.

Slazds ir tāds, ka biroja resolvera pievienošana visur izlabo pirmo un garantē otro. Publiska resolvera pievienošana visur dara pretējo.

Pierakstiet abus novērojumus ar laika zīmi, tad pēc kārtas izpildiet četras pārbaudes zemāk.

Kura adaptera resolvers saņem jautājumu

Windows DNS klients serverus izvēlas pēc adapteru saistīšanas kārtības, un tuneļa adapters nav automātiski pirmais. Atveriet adaptera papildu iestatījumus un pārvietojiet attālās piekļuves savienojumu virs fiziskā adaptera, tad pievienojieties no jauna, lai izmaiņas attiektos uz jaunu sesiju.

Saistīšanas kārtība ir tikai pirmā puse. Klientam arī jāzina, kuri nosaukumi pieder šim adapteram, un tas ir sufiksa, nevis kārtības jautājums.

Nolieciet strādājošās mašīnas ipconfig /all blakus portatīvā datora izvadei, abus iegūtus, kamēr tunelis ir aktīvs. Strādājošā mašīna rādīs savienojumam raksturīgu DNS sufiksu savā biroja adapterī, bet portatīvais var nerādīt nevienu tunelī. Šī atšķirība izskaidro veselu ziņojumu klasi “serveris ir tepat, bet nosaukums joprojām neizpildās”, jo bez sufiksa īsais nosaukums nekad netiek papildināts līdz zonai, kuru apkalpo biroja resolvers.

Īsajam nosaukumam vispirms vajag sufiksu, tikai pēc tam maršrutu

Rakstot nekvalificētu resursdatora nosaukumu, jūs lūdzat resolveram uzminēt domēnu. Minējums nāk no savienojumam piesaistītā sufiksu saraksta, un, ja šis saraksts ir tukšs, vaicājums iziet kā viena etiķete, kurai nesaskanēs neviena privātā zona.

Nokopējiet strādājošās mašīnas sufiksu VPN adaptera IPv4 rekvizītos cilnē DNS, tad pievienojieties no jauna. Linux atbilstošais ir meklēšanas domēns tuneļa saitē, ko systemd-resolved parāda katrai saitei atsevišķi, nevis globāli.

Turiet abus iestatījumus atsevišķi savos pierakstos. Sufikss maina to, ko jautā, bet resolvera adrese — kam jautā. Labojot vienu, kamēr otrs ir nepareizs, rezultāts izskatās nejaušs.

Jautājiet resolveram tieši, tad nosaukumam

Tiešs vaicājums biroja resolveram atdala nosaukuma problēmu no ceļa problēmas, jo tas pilnībā apiet klienta resolvera izvēli.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Pirmā komanda konkrētam serverim prasa pilnībā kvalificētu nosaukumu. Ja tā atbild, resolvers un ceļš uz to ir kārtībā, un bojājums ir izvēlē vai sufiksā. Ja iestājas noildze, adrese ir nepareiza vai nesasniedzama, un problēma ir maršrutēšana, nevis DNS. Otrā komanda parāda, kas notiek ar īso nosaukumu, un trešā izdrukā katras saites resolvera konfigurāciju systemd resursdatorā.

Uzmanieties no aizstājējzīmju atbildēm, ko daži tīkli atgriež nezināmiem nosaukumiem. Ticami izskatoša atbilde nav pierādījums, ka atbildēja paredzētais serveris, tāpēc salīdziniet atgriezto adresi ar to, ko faktiski izmanto iekšējais serviss. Ja adrese pieder stāvvietas lapai vai starpniekserverim, resolvers atbildēja, bet atbilde nekad nebija jūsu. Šī atšķirība ietaupa stundu, dzenoties pēc tuneļa, kas darbojās visu laiku.

Linux VPN klients, kas pārraksta /etc/resolv.conf, pilnībā aizstāj vietējos resolverus. vpnc piedāvā DNSUpdate no, lai to apturētu, un systemd-resolved var maršrutēt tikai uzskaitītos domēnus uz tuneļa saiti. Abas pieejas patur publiskos nosaukumus vietējā resolverā, bet iekšējos nosaukumus sūta uz biroju.

Noplūdi nosaka noteikums, nevis ķeksītis

Nosaukumu izpilde ir UDP apmaiņa uz 53 portu, tāpēc tunelis, kas pārvada tīmekļa trafiku, bet ne UDP, atstāj vaicājumu fiziskajā ceļā. Pierādiet to, uzķerot fiziskajā tīkla kartē, kamēr tiek izpildīts publisks nosaukums. Vaicājums, kas redzams šajā saskarnē lasāmā formā, nozīmē, ka tunelis to nepārvada.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Ja vaicājums parādās šajā saskarnē lasāmā formā, tunelis to nepārvada. Labojums ir noteikums, kas atļauj 53 portu tikai VPN nosūtītajam resolveram un atmet citus galamērķus, kopā ar klienta konfigurāciju, kas klusām neizmet nosūtīto opciju.

Tā pēdējā daļa ir svarīgāka, nekā izskatās. Sāciet OpenVPN ar route-nopull, un nosūtītā DNS opcija pazūd kopā ar maršrutiem, ja vien vilkšanas filtrs netiek paplašināts, lai to saglabātu. un klients, kas ignorē dhcp-option DNS, turpinās izmantot to, kas tam bija iepriekš. Jebkura izmaiņa servera pusē prasa jaunu sesiju, lai stātos spēkā, jo resolveru saraksts tiek piegādāts, kad tunelis paceļas, un novecojusi sesija turpina rādīt veco stāvokli.

Pierakstiet, kuru bojājumu jūs faktiski novērojāt, pirms aizverat pieteikumu. Trūkstoša iekšējā atbilde un vaicājums, kas izbēg no tuneļa, prasa atšķirīgus labojumus, un sufiksa maiņa, kas izlabo pirmo, var klusām pasliktināt otro. Ikviens, kas pārņems pieteikumu tālāk, uzticēsies apzīmējumam, tāpēc padariet apzīmējumu precīzu.