Sinisira ng wg-quick ang DNS kapag kumokonekta: basahin ang error sa setup

Tumataas ang tunnel, natatapos ang handshake, at humihinto ang paglutas ng pangalan. Walang nagbago sa peer configuration, dahil kailanman ay hindi naging bahagi ng peer configuration ang linyang DNS. Pag-aari ito ng setup helper, ibig sabihin, nasa mga tool ng resolver ng host ang sira at hindi sa mga key ng WireGuard.

Basahin ang unang mensaheng inilabas ng helper, hindi ang huli, at magiging malinaw ang pagkakaiba ng nawawalang utility at ng server na hindi maabot.

Ang linyang DNS ay tampok ng helper

Inilalarawan ng mga pangunahing field ng configuration ang mga peer, key, at pinapayagang address. Idinadagdag sa itaas ang paglutas ng pangalan ng script na nag-aangat ng interface, at iba't iba ang paraan ng bawat implementasyon. Maaaring pamahalaan ng desktop client ang DNS sa sarili nitong serbisyo, maaaring tumawag ang distribution script ng isa sa ilang resolver utility, at maaaring wala sa dalawa ang gawin ng container. Hindi masasabi ng configuration file kung alin sa mga landas na ito ang gumagana.

Kaya maaaring wasto ang isang configuration file para sa protocol at nabibigo pa rin sa setup: pag-aari ng isang hook na hindi kailanman nakikita ng protocol ang sira.

Ang pagsulat ng pinahabang field sa pangunahing configuration at pag-asang tatanggapin ito ng protocol tool ay lumilikha ng parehong kalituhan mula sa kabilang direksyon. Dalawang magkaibang file ang binabasa ng dalawang parser.

Ang malaman kung alin ang tumatakbo ay ang unang hakbang sa diagnostic, at kadalasan ito ay nakikita sa command na tinipa mo, hindi sa configuration file.

Basahin ang unang error na inilalabas ng helper

Iangat ang interface sa harapan at basahin ang output nang sunod-sunod. Ang nawawalang resolver utility, nabigong hook, at hindi maabot na server ay pinipigil ang parehong command sa magkaibang punto, at may sariling pag-aayos ang bawat isa.

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

Iniuulat ng unang command ang progreso ng setup, ipinapakita ng pangalawa kung aling server ang hinihingi ng interface ngayon, at ipinapakita ng pangatlo kung talagang naaabot ang address ng resolver sa pamamagitan ng tunnel. Ang resolver na naka-configure ngunit walang ruta ay gumagawa ng mga timeout sa halip na mga error sa configuration, kaya magkasama ang dalawang pagsusuri. Ang pagbasa lamang ng status output ay nagbubunga ng tiwala at maling konklusyon.

Kung natapos ang setup at nabibigo pa rin ang paglutas ng pangalan, ihambing ang resolver na inilagay ng helper sa ginamit ng network noon. Kailangan ng pribadong resolver ng ruta sa pamamagitan ng tunnel, at ang configuration na naglilista nito nang hindi sinasaklaw ang prefix nito ay nag-iiwan sa bawat query na naghihintay.

Aling resolver ang talagang mayroon ang host

Madalas na nagpapatakbo ang modernong Linux host ng lokal na stub resolver, kaya ang address na inilalagay ng helper ay ginagamit ng stub na iyon at hindi ng mga application nang direkta. Ang mano-manong pag-edit ng nabuong file ay maaaring mukhang gumagana hanggang sa susunod na muling pagkonekta, kapag muling isinulat ito ng helper.

Gamitin ang sinusuportahang integrasyon para sa distribution at hayaang isang bahagi lamang ang may-ari ng estado ng resolver. Dalawang may-ari ang lumilikha ng parehong karera na gaya ng dalawang may-ari ng address ng interface, at ang sintomas ay host na tama ang paglutas sa loob ng ilang minuto pagkatapos ng bawat pagbabago.

Ang mga panloob na pangalan ay karapat-dapat sa sariling pagsusuri. Maaaring ibalik ng pampublikong resolver ang pangkalahatang pag-browse habang pinababagsak ang bawat pangalan ng kumpanya, na kabaligtaran ng layunin ng tunnel. Tanungin ang nilalayong server tungkol sa panloob na pangalan bago magpasya na naayos na ang DNS.

Ang paglilinis ay kasinghalaga ng setup

Ibaba ang interface at muling suriin ang estado ng resolver. Ang helper na nagbabalik ng dating configuration ay nag-iiwan ng host na magagamit; ang nag-iiwan ng sarili nitong mga server ay lumilikha ng susunod na sira, kadalasan pagkalipas ng mga oras kapag matagal nang wala ang tunnel.

Madaling makita ang lumang estado kapag hinahanap mo ito. Maaaring tumuro ang listahan ng resolver sa isang address sa interface na wala na, at ang search domain ay maaaring mabuhay pa mula sa network na iniwan mo kaninang umaga. Alinman sa dalawa ang gumagawa sa susunod na koneksyon na hindi mahulaan, at wala sa dalawa ang lumalabas sa status output ng tunnel mismo. Tumatagal ng sampung segundo ang pagsusuri at nakakatipid ng isang oras sa susunod na tao.

Ihiwalay ang diagnostic sa pag-aayos. Kung nabibigo ang bawat destinasyon at hindi lamang ang paghahanap ng pangalan, ang mga ruta at pagpapasa ang mga pinaghihinalaan at ang linyang DNS ay isang abala. Ang manwal ng wg-quick ay nagtatala kung aling field ang hinahawakan nito at alin ang pag-aari ng protocol, at ang hangganang iyon ang buong sagot sa karamihan ng mga ulat na ito.