Mikä linkki vastaa: reititysdomainit split-tunnel-VPN:n DNS:lle

Pidä tavallinen selailu paikallisella linkillä, kun taas yrityksen nimet ratkaistaan tunnelin tarjoaman DNS-palvelimen kautta. VPN:n oletusreitin sammuttaminen antaa sinulle ensimmäisen puoliskon ja jättää toisen puoliskon rakentamatta. Seuraavaksi tulevat puuttuva asetus, välimerkki joka muuttaa sen merkityksen, ja ainoa komento joka näyttää minkä linkin kautta vastattiin. NetworkManager ja systemd-resolved oletetaan koko tekstissä, koska juuri tuo pari on paikka, jossa sekaannus yleensä alkaa.

Ensimmäinen vaihe: erota reitti ratkaisijasta

ipv4.never-default vastaa reitityskysymykseen ja estää NetworkManageria asentamasta tätä yhteyttä kaiken IPv4-liikenteen poluksi. DNS-reititysdomaini vastaa toiseen kysymykseen: minkä linkin nimipalvelimet saavat vastaavaa suffiksia koskevan kyselyn. Kumpikaan ei edellytä toista, ja profiili voi kantaa toista vuosia toisen puuttuessa. Vain reitti tarkoittaa, että tunneli kantaa yrityksen aliverkot ja sen ratkaisija vastaa yrityksen nimiin, kun taas kaikki muu jätetään rauhaan.

Aseta vain reittiominaisuus, niin sisäiset nimet epäonnistuvat, yleensä aikakatkaisulla joka kuulostaa rikkinäiseltä tunnelilta. Aseta vain domain, niin olet hiljaa lisännyt hakusuffiksin koneen jokaiseen lyhyeen nimeen. Molemmat virheet lähettävät tiketin VPN-palvelimelle, joka harvoin on se osa, joka on väärin.

Toinen vaihe: lisää vain-reititysdomain profiiliin

Oletetaan, että yhteys on nimeltään corp-vpn, yrityksen suffiksi on internal.example ja tunnelin ratkaisija on jo tavoitettavissa. Lue nykyiset arvot ensin, koska alla olevat komennot muuttavat ominaisuuksia, joissa voi jo olla merkintöjä.

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

Korvaa omalla yhteysnimelläsi ja suffiksillasi, koska yllä olevat arvot ovat havainnollistavia. Plusmerkki on tärkeämpi kuin miltä näyttää: sen kanssa arvo lisätään olemassa olevaan luetteloon, kun taas ilman sitä ominaisuus korvataan ja liittymättömät domainit katoavat profiilista, joka toimi eilen. Tilde muuttaa käyttäytymistä eikä tyyliä, ja alla oleva kappale kertoo mitä se valitsee. Pidä lukeminen ennen kirjoittamista, jotta korvausmuoto ei koskaan yllätä sinua.

Alussa oleva tilde merkitsee vain-reititysdomainia, joten vastaavat kyselyt menevät tämän linkin palvelimille eikä suffiksia lisätä lyhyisiin nimiin. Poista tilde, niin sama merkkijono muuttuu myös hakusuffiksiksi, mikä on eri lopputulos jota ihmiset harvoin tarkoittavat. Molemmat yllä olevat asetukset ovat IPv4, joten kaksoispinoprofiili tarvitsee ipv6.never-defaultin ja saman reititysdomainin ipv6.dns-searchissa, muuten IPv6-puoli jatkaa oletusreitin käyttöä ja sisäiset nimet epäonnistuvat siellä.

Kolmas vaihe: kysy resolvectl:ltä mikä linkki vastasi

Suorita resolvectl status ja lue kunkin linkin DNS-palvelimet ja domainit, suorita sitten resolvectl query host.internal.example todellista sisäistä nimeä vastaan, jota sinulla on lupa kysellä. Toinen komento on ainoa suora todiste siitä, että reititysdomain tekee työnsä, koska se nimeää linkin joka vastasi. Pelkkä tilaluettelo todistaa kokoonpanon; kysely todistaa ratkaisun.

systemd-resolved valitsee parhaiten vastaavan reititysdomainin, joten tarkempi domain toisella linkillä voi silti voittaa kilpailun. Jos kysely palaa linkiltä jota et odottanut, lue domainluettelot ennen kuin kosket VPN:n DNS-palvelimeen. Juuridomain ~. sopii kaikkeen, ja jos se on jo olemassa, tarkempi domainisi voittaa silti omien nimiensä osalta samalla kun linkki vastaa paljon enemmän kuin pyysit. Poista tai kavenna tuo juurimerkintä, kun tarkoitus oli vain yrityksen nimet.

Jos VPN-linkki ei luettele lainkaan DNS-palvelinta, asiakas ei koskaan rekisteröinyt sellaista. Reititysdomain ilman palvelinta takanaan epäonnistuu eri tavalla kuin puuttuva domain, joten korjaa ensin rekisteröinti.

Neljäs vaihe: kun nimi ratkeaa mutta palvelu ei

Oikea vastaus todistaa vain, että ratkaisu toimi, ja sovellus tarvitsee silti reitin saamaansa osoitteeseen. Tuon reitin on kestettävä juuri määrittämäsi jaettu oletusreitti, joten tarkista se ennen kuin syytät DNS:ää uudelleen. Tarkista sitten tavoitettavuus palvelun portissa, koska tiedostojako tai hakemistopalvelu epäonnistuu ratkaisussa, reitityksessä tai todennuksessa ja tuottaa kussakin tapauksessa hyvin samankaltaisia viestejä. Pidä nuo kolme kerrosta erillään, kun raportoit tuloksen, muuten seuraava henkilö tarkistaa uudelleen DNS:n, joka oli jo oikein.

Samba-muutos, joka kiertää tämän kysymyksen rinnalla, koskee käyttökerrosta, ei DNS-valintaa. Sen soveltaminen nimenratkaisuvikaan on se, miten pienestä ongelmasta tulee toinen.

Viides vaihe: älä korvaa ratkaisijaa puuttuvan domainin korjaamiseksi

Neuvo, joka kirjoittaa ratkaisijan tiedoston yli tai asentaa toisen ratkaisijahallinnan, ratkaisee toisen ongelman. Ne ovat järjestelmäintegraation muutoksia omine vikatiloineen, eikä mikään niistä lisää reititysdomainia, jota ei koskaan määritetty. Selvitä, mikä komponentti omistaa nimenratkaisun koneella ennen sen korvaamista, koska NetworkManager-työpöydällä systemd-resolvedin kanssa tuo omistajuus on jo määritelty. Sitä vastaan taisteleminen on se, miten toimivasta asetuksesta tulee jotain, jota kukaan ei voi toistaa.

Työjärjestys: varmista että tunneli tarjoaa ratkaisijan, lisää vain-reititysdomain, yhdistä uudelleen profiilin ohjaimilla, vahvista vastaava linkki ja testaa sitten palvelu sen portissa. Tämä järjestys jättää tuloksen, jonka voit luovuttaa seuraavalle henkilölle ilman toista haastattelua.