OpenVPN nosūtīja DNS serveri, bet Linux to ignorē
Nosūtītais DNS serveris ir žurnālā, tunelis ir pacelts, un iekšējie nosaukumi joprojām neizdodas. Pārbaudiet atrisinātāja saiti un izvēlieties vienu savienojuma īpašnieku.
Nosūtītais DNS serveris ir žurnālā, tunelis ir pacelts, un iekšējie nosaukumi joprojām neizdodas. Pašā nosūtīšanā nekas nav salūzis; iestatījums atnāca un tur apstājās. Nosūtītais DNS parametrs ir ziņa klientam, nevis norādījums operētājsistēmas atrisinātājam, un tieši pārnese starp tiem ir vieta, kur beidzas vairums šādu gadījumu. Piecas pārbaudes pēc kārtas atrod pārnesei, kas nenotika.
Pirmā pārbaude: kā sākas savienojums
Savienojuma īpašnieks nosaka, kas var piemērot atrisinātāja iestatījumus. Tiešs openvpn komandas izsaukums no čaulas nepieder nekam, izņemot savu procesu, savukārt systemd vienībai, NetworkManager vai piegādātāja klientam katram ir savs DNS publicēšanas veids. Izlasiet procesu sarakstu un vienības nosaukumu pirms kāda no tiem pieņemšanas.
Komandrindas process nav automātiski NetworkManager savienojums, un NetworkManager savienojums nav automātiski tas, kas ierakstīja resolv.conf. Šie divi pieņēmumi izskaidro lielāko daļu šajā izmeklēšanā izšķērdēto stundu. Pajautājiet, kura komponente publicētu DNS tai saskarnei, kuru jūs tiešām redzat.
Pierakstiet īpašnieku pirms turpināt. Katra nākamā pārbaude ir no tā atkarīga.
Otrā pārbaude: ko atrisinātāja saite patiešām tur
Hostā ar systemd-resolved, resolvectl status uzskaita katru saiti ar tās DNS serveriem un domēniem. Atrodiet tuneļa saiti un izlasiet tās ierakstus, un nepieņemiet, ka saskarne saucas tun0, jo numerācija seko izveides secībai. Ja nosūtītā adrese saitē nav, neizdevās pārnese, nevis vaicājums.
Ja adrese ir, nākamais jautājums ir, kurus domēnus šī saite pieprasa. Saite bez domēnu saraksta atbild tikai uz nosaukumiem, par kuriem tiek jautāts tieši, un tas reti ir tas, ko vēlas split-DNS izvietojums. Viena adrese ir nepieciešama, bet nepietiekama.
Pirms izdarāt kādu secinājumu, salīdziniet saites nosaukumu atrisinātāja izvadē ar saskarnes nosaukumu VPN žurnālā. Nesakritība tur parasti nozīmē, ka žurnāla rinda nākusi no cita procesa.
Trešā pārbaude: vai nosaukumvieta izvēlas šo saiti
Atrisinātājam var būt pareizais serveris, un tomēr tam var nevaicāt. Domēns katrai saitei nosaka, kuri vaicājumi uz kuru saiti iet, un bez maršrutēšanas domēna privātā nosaukumvieta atgriežas pie tā, ko saka noklusējuma saite. Tāpēc resolvectl query var izdoties iekšējam nosaukumam, kamēr lietojumprogramma joprojām neizdodas. Iespējams, lietojumprogramma izmanto pavisam citu atrisinātāja ceļu.
Pārbaudiet domēna piešķiršanu, ne tikai servera adresi. Domēns, kas rakstīts kā ~corp.example, ir maršrutēšanas domēns, un tildīte maina to, kā nosaukums tiek saskaņots.
Ja lietojumprogrammai ir savs atrisinātājs, pārbaudiet ar to pašu mehānismu, ko tā izmanto, nevis ar sistēmas rīku. Vaicājumu rīks, kas apiet sistēmas atrisinātāju, izdosies neatkarīgi no saites stāvokļa.
Ceturtā pārbaude: viens īpašnieks, nevis divi
Ja NetworkManager jau pārvalda VPN un atrisinātāja stāvokli, nesaistīta hook skripta pievienošana rada konkurējošus rakstītājus. Pakotnes nodrošinātais systemd-resolved hook ir atbalstīta integrācija, un tā gaida noteiktu dzīves ciklu: script-security 2, up ceļu, up-restart, down ceļu un down-pre. Šīs opcijas panāk, ka reģistrācija un noņemšana notiek īstajos brīžos, nevis tikai pirmajā savienojumā.
Izmantojiet pakotnē instalēto ceļu, nevis ilustratīvu, kas nokopēts no rokasgrāmatas. Arī atļaujas ir svarīgas, jo hook darbojas pēc tam, kad privilēģijas ir samazinātas.
Distribūcijas atrisinātāja skripta rediģēšana, lai mainītu tā izvades mērķi, reģistrē viena resursdatora apiešanas risinājumu. Tas nav vispārējs labojums.
Piektā pārbaude: tas pats rezultāts pēc atkārtotas pievienošanās
Pievienojieties atkārtoti un vēlreiz izlasiet saiti. Reģistrācija, kas parādās vienreiz un pazūd nākamajā pārejā, ir kļūme, kuras dēļ pastāv visa šī kontrolsaraksts. Pārbaudiet pēc miega, pēc piespiedu atkārtotas pievienošanās un pēc atrisinātāja pakalpojuma restartēšanas. Katra pāreja pārbauda citu secības pieņēmumu.
Tikai tad, kad atkārtotas pievienošanās laikā iztur visas piecas pārbaudes, varat teikt, ka nosūtītie iestatījumi tiek izmantoti. Viss pirms tam ir laimīga mirkļa uzņēmums.