CIFS-liitoksesi epäonnistuu VPN:n yli nsswitchin järjestyksen takia

Tunneli on pystyssä. Tiedostopalvelin vastaa pingiin osoitteella. Sitten mount.cifs isäntänimellä istuu siinä hetken ja ilmoittaa, ettei isäntä ole tavoitettavissa, ja sinä aloitat uudelleen sellaisen VPN-profiilin rakentamisen, joka ei koskaan ollut ongelma. Linuxissa glibc selvittää nimen ennen kuin yhtään SMB-pakettia on olemassa, ja tuon resolverin järjestys voi lopettaa haun ennen kuin DNS:ää edes kysytään. Tässä on polku, jonka kuljen, aloittaen epäonnistuneesta komennosta enkä asiakkaasta.

Lue vika oikeasta paikasta

Kaksi työkalua kulkee eri reittejä samaan nimeen, ja niiden vertailu maksaa yhden komennon. getent käy läpi määritetyn nimipalvelupinon; host ja dig kysyvät DNS:ää suoraan ja jättävät pinon huomiotta. Jos suora kysely palauttaa osoitteen ja getent ei palauta mitään, DNS-palvelin on tavoitettavissa ja sinun resolveriasetuksesi on se, joka epäonnistuu.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

Kolmas komento on ratkaisija: se pakottaa DNS-lähteen ja ohittaa pinon lopun. Kun se toimii ja tavallinen getent ei, olet todistanut, että syy on järjestyksessä, ei tunnelissa eikä palvelimessa.

hosts-rivi on sarja, joka pysähtyy aikaisin

glibc-resolveri lukee /etc/nsswitch.conf ja kulkee hosts:-merkinnän vasemmalta oikealle. Monet jakelut toimittavat rivin, jossa multicast-haku tulee ensin ja siihen on liitetty varhaisen paluun toiminto. Toiminto ei ole koriste: kun mDNS vastaa “not found”, [NOTFOUND=return] lopettaa koko haun, joten yrityksen nimeä ei koskaan lähetetä resolverille, jonka VPN tyrkytti. Mikään ei kirjaa sitä, koska yhtään kyselyä ei lähetetty resolverin hylättäväksi. Siksi liitos näyttää jumittuvan ja ilmoittaa sitten tavoittamattomasta isännästä.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

Siirrä DNS varhaisen paluun toiminnon eteen sen sijaan että poistaisit mDNS:n, ja muuta sitä konfiguraationhallinnan kautta. Käsikäsin tehty korjaus elää seuraavaan imagen buildiin, ja sitten sama tiketti saapuu toiselta koneelta, joka ei muista korjausta.

Resolveri ei ole hakudomeeni

Selvitys tarvitsee myös, että nimeä yritetään. Kvalifioimaton nimi kuten fileserver muuttuu fileserver.corp.exampleiksi vasta, kun kyselyä kantavaan liitäntään on liitetty hakudomeeni. VPN, joka tyrkyttää DNS-palvelinta ilman hakuluetteloa, tuottaa hyvin tietyn jaon: täysin kvalifioitu nimi selvitetään ja jokainen lyhyt nimi epäonnistuu.

Testaa molemmat muodot ennen profiilin muokkaamista, koska kaksi vikaa osoittavat eri suuntiin. systemd-resolved-isännässä tunnelin linkillä on omat palvelimensa ja reititysdomeeninsa, joten lue linkkiä, älä globaalia tiedostoa.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

Jos kysely kohdistetaan linkille, joka ei kanna tunnelia, reititysdomeeni puuttuu, vaikka DNS-osoite on läsnä. Se on käytäntöongelma resolved-konfiguraatiossa, ei tunnelin reititysongelma.

Kontit kantavat oman kopionsa vastauksesta

Yleisestä imagesta rakennettu kontti toimittaa yleensä kiinteän resolv.conf. Isännän resolverimuutokset eivät yllä siihen eikä hakudomeenikaan, joten build-työ, joka liittää jaon tunnelin yli, epäonnistuu, kun taas sama komento kontin ulkopuolella toimii. Anna kontille omat DNS- ja hakuasetukset compose-tiedostossa tai run-argumenteissa, ei vain isännän profiilissa.

Tarkista kontin sisältä ennen kuin syytät imagea. Kaksi komentoa toistaa koko diagnoosin sekunneissa, ja toinen todistaa, mikä resolveri todella vastasi.

Vasta sitten katso jakoa ja suodatinta

Kun nimi on selvitetty, jäljellä olevat viat ovat tavallisia verkkovikoja. SMB tarvitsee TCP 445:n palvelimelle, ja työryhmäluettelon selaaminen riippuu nimipalveluista, joita tunneli ei todennäköisesti välitä. Yhdistä isäntänimen mukaan sen sijaan että odottaisit luettelon täyttymistä, ja anna asiakkaan kertoa, mihin vaiheeseen se pääsi. Hylätty yhteys ja äänetön timeout kannattaa myös erottaa, koska ensimmäinen tarkoittaa yleensä, että jokin vastasi, ja toinen, ettei mikään.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

Selvitetty osoite, jonka portti 445 on hylätty tai aikakatkaistu, on palomuurin tai listenerin ongelma toisella puolella. Selvittämätön nimi on resolverin ongelma. Ja liitos, joka todentaa mutta palauttaa käyttöoikeusvirheitä, ei ole kumpikaan, joten älä avaa verkkoasiaa uudelleen, kun istunto on muodostettu.

Pidä johtopäätös yhtä kapeana kuin todisteet. Kun osoite toimii ja nimi ei, tunneli tekee työnsä ja korjaus kuuluu resolverin järjestykseen, hakudomeeniin tai kontin omaan asetukseen.