Milline link vastab: marsruutimisdomeenid split-tunnel VPN-i DNS-ile
Vaikimisi marsruut ja DNS-i marsruutimisdomeen on eri seaded. Lisage ettevõtte sufiks tildemärgiga ja küsige seejärel resolvectl-ilt, milline link tegelikult vastas.
Hoidke tavaline sirvimine kohalikul lingil, samal ajal kui ettevõtte nimed lahendatakse DNS-serveri kaudu, mille tunnel pakub. VPN-i vaikimisi marsruudi väljalülitamine annab teile esimese poole ja jätab teise poole ehitamata. Järgneb puuduv seade, kirjavahemärk, mis muudab selle tähendust, ja ainus käsk, mis näitab, milline link tegelikult vastas. Kogu teksti jooksul eeldatakse NetworkManageri ja systemd-resolvedi, sest just see paar on koht, kus segadus tavaliselt algab.
Esimene samm: eraldage marsruut lahendajast
ipv4.never-default vastab marsruutimisküsimusele, takistades NetworkManageril seda ühendust kogu IPv4-liikluse teeks paigaldada. DNS-i marsruutimisdomeen vastab teisele küsimusele: millise lingi nimeserverid saavad sobiva sufiksi päringu. Kumbki ei eelda teist ning profiil võib aastaid kanda ühte, samal ajal kui teine puudub. Ainult marsruut tähendab, et tunnel kannab ettevõtte alamvõrke ja selle lahendaja vastab ettevõtte nimedele, samal ajal kui kõik muu jääb puutumata.
Määrake ainult marsruudi omadus ja sisemised nimed ei lahene, tavaliselt aegumisega, mis kõlab nagu katkine tunnel. Määrake ainult domeen ja olete vaikselt lisanud otsingusufiksi masina igale lühikesele nimele. Mõlemad vead saadavad pileti VPN-serverile, mis on harva see osa, mis on vale.
Teine samm: lisage profiilile ainult-marsruudi domeen
Oletame, et ühendus kannab nime corp-vpn, ettevõtte sufiks on internal.example ja tunneli lahendaja on juba kättesaadav. Lugege esmalt praegused väärtused, sest allolevad käsud muudavad omadusi, milles võib juba olla kirjeid.
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 yesAsendage oma ühenduse nimi ja sufiks, sest ülalolevad väärtused on illustratiivsed. Plussmärk on tähtsam, kui tundub: sellega lisatakse väärtus olemasolevale loendile, ilma selleta omadus asendatakse ja seostamata domeenid kaovad profiilist, mis eile veel töötas. Tilde muudab käitumist, mitte stiili, ja allolev lõik selgitab, mida see valib. Hoidke lugemine enne kirjutamist, et asendusvorm teid kunagi ei üllataks.
Algne tilde tähistab ainult-marsruudi domeeni, nii et sobivad päringud lähevad selle lingi serveritesse ja sufiksit lühikestele nimedele ei lisata. Eemaldage tilde ja sama string muutub ka otsingusufiksiks, mis on teistsugune tulemus, mida inimesed harva kavatsevad. Mõlemad ülalolevad seaded on IPv4, seega kahe virna profiil vajab ipv6.never-defaulti ja sama marsruutimisdomeeni ipv6.dns-searchis, muidu jätkab IPv6 pool vaikimisi marsruudi kasutamist ja sisemised nimed ebaõnnestuvad seal.
Kolmas samm: küsige resolvectl-ilt, milline link vastas
Käivitage resolvectl status ja lugege iga lingi DNS-servereid ja domeene, seejärel käivitage resolvectl query host.internal.example tõelise sisemise nime vastu, mida teil on lubatud pärida. Teine käsk on ainus otsene tõend, et marsruutimisdomeen teeb oma tööd, sest see nimetab lingi, mis vastas. Ainult olekurida tõestab seadistust; päring tõestab lahendust.
systemd-resolved valib parima sobivusega marsruutimisdomeeni, seega täpsem domeen teisel lingil võib ikkagi võistluse võita. Kui päring tuleb lingilt, mida te ei oodanud, lugege domeenide loendeid enne VPN-i DNS-serveri puutumist. Juurdomeen ~. sobib kõigega ja kui see on juba olemas, võidab teie konkreetne domeen ikkagi oma nimede jaoks, samal ajal kui link vastab palju rohkemale, kui te küsisite. Eemaldage või kitsendage see juurkirje, kui kavatsus oli ainult ettevõtte nimed.
Kui VPN-i link ei loetle üldse ühtegi DNS-serverit, ei registreerinud klient kunagi ühtegi. Marsruutimisdomeen ilma serverita selle taga ebaõnnestub teisiti kui puuduv domeen, seega parandage esmalt registreerimine.
Neljas samm: kui nimi laheneb, aga teenus mitte
Õige vastus tõestab ainult seda, et lahendamine töötas, ja rakendus vajab endiselt marsruuti saadud aadressini. See marsruut peab üle elama äsja seadistatud jagatud vaikimisi marsruudi, seega kontrollige seda enne, kui DNS-i uuesti süüdistate. Seejärel kontrollige kättesaadavust teenuse pordil, sest failijagamine või kataloogiteenus ebaõnnestub lahendamisel, marsruutimisel või autentimisel ja annab igal juhul väga sarnaseid sõnumeid. Hoidke need kolm kihti eraldi, kui tulemusest teatate, muidu kontrollib järgmine inimene uuesti DNS-i, mis oli juba õige.
Samba muudatus, mis selle küsimuse kõrval ringleb, puudutab juurdepääsukihti, mitte DNS-i valikut. Selle rakendamine nime lahendamise tõrkele on viis, kuidas väike problem saab teise.
Viies samm: ärge asendage lahendajat puuduva domeeni parandamiseks
Nõuanne, mis kirjutab üle lahendaja faili või paigaldab teise lahendajahalduri, lahendab teise probleemi. Need on süsteemiintegratsiooni muudatused oma tõrkerežiimidega ja ükski neist ei lisa marsruutimisdomeeni, mida kunagi ei seadistatud. Tehke kindlaks, milline komponent omab masinas nimede lahendamist, enne selle asendamist, sest NetworkManageri töölaual koos systemd-resolvediga on see omandus juba määratletud. Selle vastu võitlemine on viis, kuidas töötav seadistus muutub millekski, mida keegi ei suuda korrata.
Töö järjekord: kinnitage, et tunnel pakub lahendajat, lisage ainult-marsruudi domeen, ühendage profiili juhtelementide kaudu uuesti, kontrollige vastavat linki ja seejärel testige teenust selle pordil. See järjestus jätab tulemuse, mille saate ilma teise vestluseta järgmisele inimesele üle anda.