Debian-resolvconf-rekordorde: plaas die VPN-rekord eerste
Die VPN se naambediener beland steeds onder die LAN-naambediener omdat resolvconf rekordname sorteer. Wysig interface-order, genereer weer en verifieer twee opsoeke.
Die VPN se naambediener beland steeds onder die LAN-naambediener, en om /etc/resolv.conf te wysig, maak dit vir 'n paar minute reg. Daardie lêer word gegenereer, so die regstelling oorleef nooit. Op Debian se resolvconf is die ordeningsinvoer /etc/resolvconf/interface-order, en dit sorteer rekordname eerder as DNS-adresse. Bevestig watter resolver-stapel werklik in beheer is voordat jy enige van die twee lêers aanraak.
Bevestig dat resolvconf die uitset besit
Begin deur te vra wat die huidige lêer geskryf het en wat dit weer sal skryf. Die resolvconf-pakket beskryf homself as 'n raamwerk vir dinamiese resolver-konfigurasie, en 'n gasheer wat systemd-resolved of 'n NetworkManager-bestuurde resolver gebruik, kan van buite soortgelyk lyk terwyl dit 'n heeltemal ander beleid gebruik.
readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1
As die opgeloste pad nie na resolvconf se looptydgids lei nie, stop hier: hierdie handleiding hoort by 'n ander stapel.
Eers ná daardie kontrole is dit die moeite werd om die rekords te lys wat resolvconf tans hou.
Lees die rekords voordat jy patrone skryf
interface-order pas by die name van verskafferrekords, nie adresse of kernkoppelvlakname nie. Lys wat geregistreer is, sodat jou patrone na bestaande inskrywings verwys.
ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order
'n Rekordnaam dra gewoonlik 'n agtervoegsel wat sy verskaffer aandui, so 'n tonnelrekord en 'n DHCP-rekord kan dieselfde koppelvlakvoorvoegsel deel en tog anders sorteer. Kopieer die presiese name uit die gidslys. Moenie 'n naam uit die koppelvlaknaam aflei nie, want die kliëntintegrasie besluit wat dit registreer. 'n Naam wat jy uitdink, sal nooit pas nie, en die rekord sal na die vang-alles-patroon val sonder enige foutboodskap.
Skryf die orde as eerste-pas-patrone
Die lêer is 'n lys shell-globpatrone, een per lyn. 'n Rekord neem die posisie van die eerste patroon wat dit pas, so 'n breë patroon bo 'n spesifieke een maak die spesifieke lyn onbereikbaar.
# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*
Plaas die spesifieke tonnelpatroon bo die vang-alles en bo die fisiese koppelvlakpatroon.
Behou die ander lyne wat die lêer reeds gehad het. Om die hele beleid met 'n voorbeeld te vervang, is hoe onverwante verskaffers stilweg skuif; verander een lyn, genereer weer en vergelyk. Patrone kan nie witruimte, skuinsstrepe of 'n voorste punt of tilde bevat nie, en leë lyne en hash-kommentaar word geïgnoreer.
Genereer weer en verifieer die resultaat
Die orde geld wanneer die opdateringskripte die lêer herbou. Aktiveer die ondersteunde opdateringspad eerder as om die gegenereerde uitset te wysig, en lees dan wat die resolver werklik ontvang het.
resolvconf -u
cat /etc/resolv.conf
Verifieer twee opsoeke, nie een nie: 'n private naam wat deur die tonnel behoort op te los, en 'n publieke kontrolenaam. As die private naam steeds misluk terwyl die orde korrek lyk, is die probleem naamruimte-roetering eerder as rekordprioriteit, en geen herrangskikking sal dit regmaak nie. Vergelyk elke antwoord met die bediener wat dit teruggegee het, nie net met sukses nie. 'n Private naam wat deur die verkeerde resolver beantwoord word, is steeds 'n mislukking, en vir die gebruiker lyk dit soos 'n DNS-onderbreking.
Trek die verouderde rekord terug in plaas daarvan om dit te demoveer
'n Verouderde VPN-rekord wat ná ontkoppeling bly terugkeer, is 'n lewensiklusfout in die kliëntintegrasie. Om dit na die onderkant te skuif, verberg die simptoom en los 'n dooie resolver in die lys.
Trek dit terug deur die komponent wat dit registreer, en bevestig dan dat die rekordgids dit nie meer lys nie.
Teken die verskaffernaam, die patroon wat jy verander het en die twee opsoeke wat jy gedoen het, aan. Die volgende persoon het daardie name meer nodig as die storie.