Gelditu bi Linux zerbitzuren arteko lehia /etc/resolv.conf fitxategiagatik

DNS etengabe itzultzen da aurreko egoerara, VPN birkonexioak zure konponketa desegiten du, eta taldeko norbaitek fitxategia blokeatzea proposatzen du azkenean. Segida hori sintoma da, ez konponbidea: bi osagaik uste dute /etc/resolv.conf haiena dela, eta azken idazten duena gailentzen da. Fitxategia blokeatzeak ez du jabetza-gatazka konpontzen, ezkutatu besterik ez du egiten, eta horrek benetan nahi zenuen osagaia hausten du. Egin beheko lau egiaztapenak ordenan, eta zuzendu antolaketa hura duen mailan, ez fitxategian.

Egiaztapena 1: esteka sinbolikoa al da, eta zertara

Hasi fitxategiarekin bertatik, editatu nahi duzun bidea agian ez baita fitxategia ere. Resolver baten exekuzio-direktorioan sartzen den esteka sinboliko batek erabat bestelako portaera du bezero-script batek berridazten duen fitxategi arrunt batek baino:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

systemd-resolved-en stub bide baterako esteka batek esan nahi du fitxategiaren edukia sortzen dela, eta eskuzko edizioa hurrengo gertaeran gainidatziko dela. nameserver lerroak dituen fitxategi arrunta konektatzean exekutatzen den bezeroak edo DHCP kakoak idazten du normalean. Biak dira zilegi; garrantzitsua da aldatu aurretik zein duzun jakitea.

Egiaztapena 2: zein daemon ari da exekutatzen

Ezagutu zer dagoen benetan aktibo, ez zer dagoen instalatuta. Banaketa moderno batean resolver batzuk egon daitezke, eta loopback interfazean 53 portua duena da erantzuten duena:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

Egoera-irteerak esteka bakoitzeko DNS zerbitzariak eta bideratze-domeinuak aipatzen ditu, eta hori da split DNSerako behar duzun mapa. Barne-izenek barne-zerbitzari batera joan behar badute eta gainerako guztiak publiko batera, politika hori esteka bakoitzeko domeinuetan bizi da, eta fitxategiko nameserver zerrenda estatiko batean zapaltzeak isil-isilik galtzen du bereizketa hori.

NetworkManager-en konfigurazioak berak erabakitzen du zein backend erabiltzen duen. Konfigurazio-fitxategi nagusiko dns= ezarpenak bere resolver internoaren, dnsmasqen, systemd-resolveden eta none-ren artean aukeratzen du, eta banaketak zure ordez aukeratu dezake. Irakurri ezarpen hori ostalari honetan “DNS konpontzeak” zer esan nahi duen erabaki aurretik.

Egiaztapena 3: zer idazteko baimena du VPN bezeroak

Hemen bizi ohi da gatazka. Resolver fitxategia zuzenean berridazten duen VPN bezero batek hura ere mantentzen duen edozein zerbitzurekin borrokatuko da, eta galtzailea lehen exekutatzen dena da. Azken OpenVPN bertsioek DNS ezarpenak systemd-resolvedi eman diezazkiokete fitxategia berridatzi beharrean, eta hori da nahi duzun jokabide kooperatiboa; script zaharrek eta eskuz idatzitako kakuek askotan laguntzaile zaharkitu bat deitzen dute edo fitxategia besterik gabe gainidazten dute.

WireGuarden egoera antzekoa da formaz: interfazearen konfigurazioak berak ez du DNSa kudeatzen, inguruko tresnek egiten dute, resolver laguntzaile baten edo resolved integrazioaren bidez. Bi laguntzaile horietako bi instalatuta badaude, biak saiatuko dira beren mundu-ikuspegia konektatzean ezartzen.

Irakurri bezeroaren up eta down kakoak asmatu beharrean. /etc/openvpn/up.sh edo baliokide den direktorio bateko shell lerro batzuek bestela ausazkoa dirudien jokabidea azaltzen dute, eta hantxe jar dezakezu bezeroa lehiatu beharrean elkarlanean aritzeko.

Egiaztapena 4: konpondu jabearenean, ez fitxategian

Jabea dakizunean, konfiguratu DNS jabe horrek onartzen duen interfazearen bidez. systemd-resolvedentzat esteka bakoitzeko ezarpenak eta bideratze-domeinuak esan nahi du fitxategi estatikoaren ordez; NetworkManagerrentzat konexio-profilaren DNS ezarpenak eta aukeratutako backenda; resolvconf integrazioa duen banaketa baterako, laguntzaile horren bidez idaztea.

Ez egin fitxategia aldaezin. Aldaezintasun atributuak DHCP berritze legitimoak eta VPN eguneratzeak gelditzen ditu, borrokan ari zinenekin batera, eta sistema konfiguraziotik inork azaldu ezin duen hutsegite bat sortzen duen egoeran uzten du hurrengo pakete-eguneratzean edo birkonexioan. Jabetza-gatazka ezkutatzen du, eta horixe zen konpontzen saiatzen zinen gauza.

Bi osagai benetan elkarrekin bizi behar direnean, eman lan desberdinak. Utzi sare-kudeatzaileari interfaze-mailako konfigurazioa izatea, utzi VPN bezeroari esteka bakoitzeko DNSa eta domeinuak integrazio beraren bidez ekartzen, eta kendu fitxategia zuzenean idazten duen hirugarren scripta. systemd-resolveden dokumentazioak onartzen dituen moduak eta bakoitzak /etc/resolv.conf zer erakusten duen azaltzen du. Aukeratu gorde behar duzun politikaren kopuruari dagokion modua. Split DNS garrantzitsua bada, stub antolamenduak esteka bakoitzeko domeinuekin mantentzen du, eta upstream zerbitzariak fitxategira kopiatzen dituen moduak isil-isilik zapaltzen du.

Egiaztatu birkonexioaren ondoren, ez edizioaren ondoren

Zure aldaketaren ondoren berehala zuzena dirudien fitxategiak ez du ezer frogatzen, hurrengo gertaera oraindik gertatu ez delako. Abiarazi lehen hura hausten zuen segida: jaitsi eta igo tunela, berritu DHCP maiztasuna edo aldatu interfazea, eta irakurri berriro balio berberak.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

Ondoren berretsi garrantzitsua den bereizketa: barne-izena barne-zerbitzariaren bidez ebazten da, eta izen publikoa oraindik funtzionatzen du. Dena barne-zerbitzarira bidaltzen duen konfigurazioak ondo dirudi norbaitek tunelaren bidez internetera iritsi nahi duen arte, eta dena publikora bidaltzen duen konfigurazioak barne-izenak ihes egiten uzten ditu.

Idatzi jabea, backenda eta esteka sinbolikoaren modua inplementazio-oharretan. Paragrafo bakar horrek etorkizuneko pakete-eguneratze bat gertakaritik berrikuspen-elementu bihurtzen du, eta hurrengo pertsonari chattr komandoarekin gatazka bera berriro aurkitzea eragozten dio.