OpenVPN skickar DNS, men din resolver kanske aldrig ser det

Klientloggen visar den skickade DNS-servern, tunneln är ansluten och ett internt namn löses fortfarande inte. Ingenting är trasigt i själva skickandet. Alternativet kom fram och operativsystemets resolver använde det aldrig, eftersom OpenVPN på de flesta Unix-klienter levererar värdet och lämnar programmet till plattformen.

Symptomet: loggen visar DNS och namnen misslyckas fortfarande

OpenVPN dhcp-option bär DNS- och domäninformation, och klienten registrerar vad den tog emot. I vissa implementationer tillämpar klienten inställningarna internt; i andra exporterar den dem till ett integrationsskript eller en nätverkstjänst. Loggraden beskriver bara första halvan av historien. Andra halvan sker någonstans där klienten inte har kontroll. Det är där felet oftast bor.

Därför förekommer en ansluten tunnel och ett misslyckat internt namn så ofta tillsammans. Värdet finns, konsumenten saknas eller är felkonfigurerad, och resolvern fortsätter tyst att använda den offentliga server den använde före anslutningen.

Mottaget är inte tillämpat

En klient kan logga ett skickat DNS-värde medan systemets resolver fortfarande ägs av en annan tjänst. En webbläsare kan också ha sin egen policy för krypterad DNS som kringgår systemets resolver helt, vilket ger den minnesvärda situationen där en applikation löser interna namn och en annan inte.

Kontrollera implementationens stödda integration i stället för att anta att varje Unix-klient skriver om samma fil. Det antagandet är anledningen till att människor redigerar en resolverkonfiguration som ingenting läser.

Hitta resolverens ägare per plattform

På Windows kan namnupplösningspolicy-tabellen skicka specifika suffix till specifika servrar, och VPN-klienten kan installera regler där. Kontrollera policyn, inte bara adapterns DNS-lista. På Linux kan NetworkManager eller systemd-resolved äga konfigurationen, och vilken av dem som äger den avgör vad en återanslutning bevarar.

Läs det effektiva tillståndet med verktyget som faktiskt svarar på frågor: resolvectl query internal.example.net på en systemd-resolved-värd, eller plattformens motsvarighet. Jämför sedan svaret med den DNS-server som klientloggen påstår sig ha skickat.

Undvik att köra flera tjänster som skriver över resolverinställningar utan samordning. Två ägare ger ett resultat som verkar intermittent, och varje återanslutning tycks reparera eller förstöra det slumpmässigt.

Skript och foreign_option

OpenVPN exporterar skickade alternativ till skript via variabler som heter foreign_option_N, och ett skript kan översätta dem till resolverkommandon. Den ordningen är en stödd integration, inte automatiskt beteende, och den måste installeras och anropas på klienten.

Om du förlitar dig på ett skript, logga dess körning och utgångsstatus. Ett skript som körs men misslyckas tyst lämnar samma symptom som inget skript, och det är svårare att lägga märke till eftersom konfigurationen ser komplett ut. Kontrollera skriptets utdata, inte skriptfilen. En fil som finns är inte ett skript som har kört.

Testa namnet, inte loggen

Fråga klienten efter ett endast internt värdnamn efter anslutning, fråga sedan efter ett publikt namn och kontrollera sedan vilken server som svarade. I en fungerande uppsättning kommer de två svaren från olika ställen, och båda bör stämma med designen.

Om namnet löses men tjänsten misslyckas, gå vidare till routing och applikationsåtkomst i stället för att ändra DNS igen. OpenVPN-handboken dokumenterar dhcp-option och skriptmiljön; använd den för att bekräfta vad din klient förväntas tillämpa innan du redigerar ännu en resolverfil.