Debian resolvconf ierakstu secība: VPN ierakstu lieciet pirmo

VPN nosaukumu serveris pastāvīgi nonāk zem LAN nosaukumu servera, un /etc/resolv.conf rediģēšana to salabo uz dažām minūtēm. Šis fails tiek ģenerēts, tāpēc labojums nekad nepaliek. Debian resolvconf secības ievade ir /etc/resolvconf/interface-order, un tā kārto ierakstu nosaukumus, nevis DNS adreses. Pirms pieskaraties kaut vienam no abiem failiem, pārliecinieties, kura resolver steks patiešām ir atbildīgs.

Pārliecinieties, ka izvadi pārvalda resolvconf

Sāciet ar jautājumu, kas ierakstīja pašreizējo failu un kas to ierakstīs vēlreiz. Pakotne resolvconf sevi raksturo kā dinamiskas resolver konfigurācijas ietvaru, un resursdators, kas darbojas ar systemd-resolved vai NetworkManager pārvaldītu resolver, no ārpuses var izskatīties līdzīgs, taču izmantot pavisam citu politiku.

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

Ja atrisinātais ceļš neved uz resolvconf izpildes direktoriju, apstājieties šeit: šī rokasgrāmata pieder citam stekam.

Tikai pēc šīs pārbaudes ir vērts uzskaitīt ierakstus, kurus resolvconf pašlaik tur.

Izlasiet ierakstus pirms rakstāt modeļus

interface-order atbilst piegādātāja ierakstu nosaukumiem, nevis adresēm un nevis kodola saskarņu nosaukumiem. Uzskaitiet, kas ir reģistrēts, lai jūsu modeļi atsauktos uz esošiem ierakstiem.

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

Ieraksta nosaukumam parasti ir piedēklis, kas norāda tā piegādātāju, tāpēc tuneļa ieraksts un DHCP ieraksts var dalīt saskarnes prefiksu un tomēr kārtoties atšķirīgi. Nokopējiet precīzos nosaukumus no direktorijas saraksta. Neizseciniet nosaukumu no saskarnes nosaukuma, jo klienta integrācija izlemj, ko reģistrēt. Izdomāts nosaukums nekad nesaskanēs, un ieraksts bez jebkāda kļūdas ziņojuma nonāks visu uztverošajā modelī.

Uzrakstiet secību kā pirmās atbilstības modeļus

Fails ir shell glob modeļu saraksts, viens katrā rindā. Ieraksts ieņem tā pirmā modeļa vietu, kuram tas atbilst, tāpēc plašs modelis virs konkrēta padara konkrēto rindu nesasniedzamu.

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

Konkrēto tuneļa modeli lieciet virs visu uztverošā modeļa un virs fiziskās saskarnes modeļa.

Saglabājiet pārējās rindas, kas failā jau bija. Visas politikas aizstāšana ar piemēru ir veids, kā nesaistīti piegādātāji klusi pārvietojas; nomainiet vienu rindu, ģenerējiet no jauna un salīdziniet. Modeļos nedrīkst būt atstarpes, slīpsvītras vai sākuma punkts un tildīte, un tukšas rindas un komentāri ar resnuzīmi tiek ignorēti.

Ģenerējiet no jauna un pārbaudiet rezultātu

Secība tiek piemērota, kad atjaunināšanas skripti pārbūvē failu. Palaidiet atbalstīto atjaunināšanas ceļu, nevis rediģējiet ģenerēto izvadi, un pēc tam izlasiet, ko resolver patiešām saņēma.

resolvconf -u
cat /etc/resolv.conf

Pārbaudiet divus vaicājumus, nevis vienu: privātu vārdu, kam jāatrisinās caur tuneli, un publisku kontroles vārdu. Ja privātais vārds joprojām neizdodas, kamēr secība izskatās pareiza, problēma ir nosaukumu telpas maršrutēšana, nevis ierakstu prioritāte, un nekāda pārkārtošana to nelabos. Salīdziniet katru atbildi ar serveri, kas to atgrieza, ne tikai ar panākumiem. Nepareiza resolver atbildēts privāts vārds joprojām ir kļūda, un lietotājam tas izskatās kā DNS pārtraukums.

Izņemiet novecojušo ierakstu no aprites, nevis pazeminiet tā pakāpi

Novecojis VPN ieraksts, kas pēc atvienošanas atkal parādās, ir klienta integrācijas dzīves cikla kļūda. Pārvietošana uz saraksta beigām slēpj simptomu un atstāj sarakstā mirušu resolver.

Izņemiet to no aprites caur komponenti, kas to reģistrē, un pēc tam pārliecinieties, ka ierakstu direktorijs to vairs neuzskaita.

Pierakstiet piegādātāja nosaukumu, mainīto modeli un divus vaicājumus, ko veicāt. Nākamajam cilvēkam šie nosaukumi ir vajadzīgāki par stāstu.