Kura saite atbild: maršrutēšanas domēni split-tunnel VPN DNS

Turiet parasto pārlūkošanu vietējā saitē, kamēr uzņēmuma nosaukumi tiek atrisināti caur DNS serveri, ko nodrošina tunelis. Izslēdzot VPN noklusējuma maršrutu, jūs iegūstat pirmo pusi, bet otrā paliek neuzbūvēta. Tālāk ir trūkstošais iestatījums, pieturzīme, kas maina tā nozīmi, un vienīgā komanda, kas parāda, kura saite faktiski atbildēja. Visā tekstā tiek pieņemti NetworkManager un systemd-resolved, jo tieši šis pāris parasti ir vieta, kur sākas apjukums.

Pirmais solis: atdaliet maršrutu no atrisinātāja

ipv4.never-default atbild uz maršrutēšanas jautājumu un neļauj NetworkManager instalēt šo savienojumu kā ceļu visam IPv4 trafikam. DNS maršrutēšanas domēns atbild uz citu jautājumu: kuras saites nosaukumu serveri saņem vaicājumu par atbilstošu sufiksu. Neviens neietver otru, un profilā var gadiem būt viens, kamēr trūkst otra. Tikai maršruts nozīmē, ka tunelis pārvadā uzņēmuma apakštīklus un tā atrisinātājs atbild uz uzņēmuma nosaukumiem, bet viss pārējais paliek neskarts.

Iestatiet tikai maršruta īpašību, un iekšējie nosaukumi neizdodas, parasti ar taimautu, kas izklausās kā salauzts tunelis. Iestatiet tikai domēnu, un jūs klusi esat pievienojis meklēšanas sufiksu katram īsajam nosaukumam mašīnā. Abas kļūdas sūta biļeti uz VPN serveri, kas reti ir tā daļa, kas ir nepareiza.

Otrais solis: pievienojiet profilam tikai-maršrutēšanas domēnu

Pieņemsim, ka savienojums saucas corp-vpn, uzņēmuma sufikss ir internal.example un tuneļa atrisinātājs jau ir sasniedzams. Vispirms izlasiet pašreizējās vērtības, jo zemāk esošās komandas maina īpašības, kurās jau var būt ieraksti.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Aizstājiet ar savu savienojuma nosaukumu un sufiksu, jo iepriekš minētās vērtības ir ilustratīvas. Pluszīme ir svarīgāka, nekā šķiet: ar to vērtība tiek pievienota esošajam sarakstam, bet bez tās īpašība tiek aizstāta un nesaistīti domēni pazūd no profila, kas vakar darbojās. Tilde maina uzvedību, nevis stilu, un zemāk esošā rindkopa paskaidro, ko tā izvēlas. Saglabājiet lasīšanu pirms rakstīšanas, lai aizstāšanas forma jūs nekad nepārsteigtu.

Sākuma tilde apzīmē tikai-maršrutēšanas domēnu, tāpēc atbilstošie vaicājumi dodas uz šīs saites serveriem un sufikss netiek pievienots īsajiem nosaukumiem. Noņemiet tildi, un tā pati virkne kļūst arī par meklēšanas sufiksu, kas ir cits rezultāts, ko cilvēki reti domā. Abi iepriekš minētie iestatījumi ir IPv4, tāpēc divkāršā steka profilam vajag ipv6.never-default un to pašu maršrutēšanas domēnu ipv6.dns-search, citādi IPv6 puse turpina izmantot noklusējuma maršrutu, un iekšējie nosaukumi tur neizdodas.

Trešais solis: pajautājiet resolvectl, kura saite atbildēja

Palaidiet resolvectl status un izlasiet katras saites DNS serverus un domēnus, pēc tam palaidiet resolvectl query host.internal.example pret īstu iekšēju nosaukumu, kuru jums ir atļauts vaicāt. Otrā komanda ir vienīgais tiešais pierādījums, ka maršrutēšanas domēns dara savu darbu, jo tā nosauc saiti, kas atbildēja. Tikai statusa saraksts pierāda konfigurāciju; vaicājums pierāda atrisināšanu.

systemd-resolved izvēlas vislabāk atbilstošo maršrutēšanas domēnu, tāpēc konkrētāks domēns citā saitē tomēr var uzvarēt sacensībā. Ja vaicājums atgriežas no saites, ko negaidījāt, izlasiet domēnu sarakstus pirms VPN DNS servera aiztikšanas. Saknes domēns ~. atbilst visam, un, ja tas jau ir, jūsu konkrētais domēns tomēr uzvar saviem nosaukumiem, kamēr saite atbild uz daudz ko vairāk, nekā jūs prasījāt. Noņemiet vai sašauriniet šo saknes ierakstu, kad nodoms bija tikai uzņēmuma nosaukumi.

Ja VPN saite vispār neuzskaita DNS serveri, klients to nekad nav reģistrējis. Maršrutēšanas domēns bez servera aiz tā neizdodas citādi nekā trūkstošs domēns, tāpēc vispirms salabojiet reģistrāciju.

Ceturtais solis: kad nosaukums atrisinās, bet pakalpojums ne

Pareiza atbilde pierāda tikai to, ka atrisināšana darbojās, un lietojumprogrammai joprojām vajag maršrutu uz saņemto adresi. Šim maršrutam jāpārdzīvo tikko konfigurētais sadalītais noklusējuma maršruts, tāpēc pārbaudiet to pirms DNS vainošanas vēlreiz. Pēc tam pārbaudiet sasniedzamību pakalpojuma portā, jo failu koplietošana vai direktoriju pakalpojums neizdodas atrisināšanā, maršrutēšanā vai autentifikācijā un katrā gadījumā sniedz ļoti līdzīgus ziņojumus. Turiet šos trīs slāņus atsevišķi, kad ziņojat rezultātu, citādi nākamais cilvēks vēlreiz pārbauda DNS, kas jau bija pareizs.

Samba izmaiņas, kas cirkulē līdzās šim jautājumam, attiecas uz piekļuves slāni, nevis DNS izvēli. To piemērošana nosaukumu atrisināšanas kļūmei ir veids, kā maza problēma iegūst otru.

Piektais solis: neaizstājiet atrisinātāju, lai salabotu trūkstošu domēnu

Padoms, kas pārraksta atrisinātāja failu vai instalē citu atrisinātāja pārvaldnieku, atrisina citu problēmu. Tās ir sistēmas integrācijas izmaiņas ar saviem kļūmes režīmiem, un neviena no tām nepievieno maršrutēšanas domēnu, kas nekad netika konfigurēts. Nosakiet, kura komponente pārvalda nosaukumu atrisināšanu mašīnā, pirms to aizstājat, jo NetworkManager darbvirsmā ar systemd-resolved šī īpašumtiesība jau ir definēta. Cīņa ar to ir veids, kā strādājošs iestatījums kļūst par kaut ko, ko neviens nevar atkārtot.

Darba secība: pārliecinieties, ka tunelis nodrošina atrisinātāju, pievienojiet tikai-maršrutēšanas domēnu, atkārtoti izveidojiet savienojumu ar profila vadīklām, pārbaudiet atbildošo saiti un pēc tam pārbaudiet pakalpojumu tā portā. Šī secība atstāj rezultātu, ko varat nodot nākamajam cilvēkam bez otrās sarunas.