Hokker keppeling antwurdet: routingdomeinen foar split-tunnel VPN-DNS

Hâld gewoan browsen op 'e lokale keppeling wylst bedriuwsnammen fia de DNS-tsjinner oplost wurde dy't de tunnel leveret. De standertrûte fan 'e VPN útskeakelje jout jo de earste helte en lit de twadde helte ûnbouwd. Wat folget is de ûntbrekkende ynstelling, it lêsteken dat de betsjutting feroaret, en it iene kommando dat sjen lit hokker keppeling eins antwurde. NetworkManager en systemd-resolved wurde troch de hiele tekst oannommen, om't dat pear is wêr't de betizing meastal begjint.

Stap ien: skied de rûte fan 'e oplosser

ipv4.never-default beantwurdet in routingfraach en stopet NetworkManager derfan om dizze ferbining te ynstallearjen as it paad foar al it IPv4-ferkear. In DNS-routingdomein beantwurdet in oare fraach: hokker nammetsjinners fan hokker keppeling in fraach foar in oerienkommend suffiks krije. Gjin fan beide ferûnderstelt de oare, en in profyl kin jierrenlang ien drage wylst de oare mist. Allinnich-rûte betsjut dat de tunnel de subnetten fan it bedriuw draacht en syn oplosser bedriuwsnammen beantwurdet, wylst al it oare gewurde litten wurdt.

Set allinnich de rûte-eigenskip en ynterne nammen mislearje, meast mei in tiidferrin dat klinkt as in brutsen tunnel. Set allinnich it domein en jo hawwe stil in syksuffiks tafoege oan elke koarte namme op 'e masine. Beide flaters stjoere it ticket nei de VPN-tsjinner, dy't komselden it diel is dat ferkeard is.

Stap twa: foegje in allinnich-routingdomein ta oan it profyl

Stel dat de ferbining corp-vpn hjit, it bedriuwssuffiks internal.example is, en de oplosser fan 'e tunnel al berikber is. Lês earst de hjoeddeiske wearden, want de kommando's hjirûnder feroarje eigenskippen dy't al ynfier hawwe kinne.

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

Ferfang troch jo eigen ferbiningsnamme en suffiks, want de wearden hjirboppe binne yllustratyf. It plusteken is wichtiger as it liket: dermei wurdt de wearde taheakke oan 'e besteande list, wylst sûnder it de eigenskip ferfongen wurdt en net-relatearre domeinen ferdwine út in profyl dat juster noch wurke. De tilde feroaret gedrach, net styl, en de paragraaf hjirûnder behannelet wat it selektearret. Hâld it lêzen foar it skriuwen, sadat de ferfangingsfoarm jo nea ferrasse.

In liedende tilde markearret in allinnich-routingdomein, dus oerienkommende fragen gean nei de tsjinners fan dizze keppeling en it suffiks wurdt net taheakke oan koarte nammen. Helje de tilde fuort en deselde tekenrige wurdt ek in syksuffiks, wat in oar resultaat is dat minsken komselden bedoele. Beide ynstellings hjirboppe binne IPv4, dus in dûbel-stackprofyl hat ipv6.never-default en itselde routingdomein yn ipv6.dns-search nedich, oars bliuwt de IPv6-kant de standertrûte brûken en mislearje ynterne nammen dêr.

Stap trije: freegje resolvectl hokker keppeling antwurde

Rin resolvectl status en lês de DNS-tsjinners en domeinen fan elke keppeling, rin dan resolvectl query host.internal.example tsjin in echte ynterne namme dy't jo freegje meie. It twadde kommando is it iennige direkte bewiis dat it routingdomein syn wurk docht, om't it de keppeling neamt dy't antwurde. In statuslist allinnich bewiist konfiguraasje; de fraach bewiist oplossing.

systemd-resolved kiest it bêst oerienkommende routingdomein, dus in spesifiker domein op in oare keppeling kin de wedstriid noch winne. As de fraach weromkomt fan in keppeling dy't jo net ferwachte, lês dan de domeinlisten foardat jo de DNS-tsjinner fan 'e VPN oanreitsje. In woarteldomein fan ~. komt mei alles oerien, en as it al oanwêzich is, wint jo spesifike domein noch foar syn eigen nammen wylst de keppeling folle mear beantwurdet as jo fregen. Ferwiderje of ferfynje dat woartelynfier as de bedoeling allinnich bedriuwsnammen wie.

As de VPN-keppeling hielendal gjin DNS-tsjinner neamt, hat de klant der nea ien registrearre. In routingdomein sûnder tsjinner der efter mislearret oars as in ûntbrekkend domein, dus reparearje earst de registraasje.

Stap fjouwer: as de namme oplost mar de tsjinst net

In korrekt antwurd bewiist allinnich dat de oplossing wurke, en de applikaasje hat noch in rûte nei it adres nedich dat it krige. Dy rûte moat de splitste standert oerlibje dy't jo krekt konfigurearre hawwe, dus kontrolearje dy foardat jo DNS wer de skuld jouwe. Kontrolearje dan berikberens op 'e poarte fan 'e tsjinst, want in bestânsdieling of mapstsjinst mislearret by oplossing, routing of autentikaasje en jout yn elk gefal tige gelykse berjochten. Hâld dy trije lagen skieden as jo it resultaat rapportearje, oars kontrolearret de folgjende persoan DNS wer dat al korrekt wie.

De Samba-feroaring dy't njonken dizze fraach sirkulearret, giet oer de tagongslag, net oer de DNS-kaai. It tapasse op in namme-oplossingsfout is hoe't in lyts probleem in twadde krijt.

Stap fiif: ferfang de oplosser net om in ûntbrekkend domein te reparearjen

Advys dat it oplosserbestân oerskriuwt of in oare oplosserbehearder ynstallearret, lost in oar probleem op. Dat binne systeemyntegraasjeferoarings mei har eigen mislearringsmodi, en gjin fan har foeget in routingdomein ta dat nea konfigurearre wie. Stel fêst hokker komponint namme-oplossing op 'e masine besit foardat jo it ferfange, want op in NetworkManager-buroblêd mei systemd-resolved is dat besit al definiearre. Der tsjin fjochtsje is hoe't in wurkjende opset wat wurdt dat nimmen reprodusearje kin.

Wurkfolchoarder: befêstigje dat de tunnel in oplosser leveret, foegje it allinnich-routingdomein ta, ferbyn wer fia de profylkontrôles, ferifiearje de antwurdzjende keppeling, en test dan de tsjinst op syn poarte. Dy folchoarder lit in resultaat efter dat jo sûnder in twadde petear oan 'e folgjende persoan jaan kinne.