Varför DNS slutar fungera efter att OpenVPN ansluter på Windows

Resolveraren svarar fortfarande på ping medan port 53 inte leder någonstans. Kontrollera om block-outside-dns filtrerar och ordna sedan en resolver som tunneln kan nå.

En ping till kontorets resolver får fortfarande svar efter att "OpenVPN" ansluter, och ändå misslyckas varje namnsökning. Adressen går att nå medan porten inte gör det, en kombination som blir begriplig när man vet att Windows kan filtrera DNS per adapter. Med block-outside-dns i profilen är det filtret den första misstänkta, och rutttabellen är fel plats att leta på. De två testerna nedan skiljer lagren på sekunder.

Nåbar adress, död port

En lyckad ping bevisar att värden kör och att en väg finns. Den säger inget om tillstånd att nå port 53, eftersom filtret i fråga arbetar på ett annat lager och hänger på adaptern. Därför kan samma maskin svara på ICMP och avvisa varje fråga som skickas till samma adress. Kör båda testerna i samma session innan du ändrar någon konfiguration.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Paret är diagnosen. Vanlig trafik till subnätet fortsätter medan namnmatchningen dör, och folk drar slutsatsen att servern är trasig eller att DNS aldrig skickades. Båda förklaringarna är dyra att följa upp, och bevisen pekar mot något snävare. Bekräfta paret innan du rör en inställning.

Valet är en regel i filtreringsplattformen

OpenVPN-referensen beskriver block-outside-dns som en begränsning i Windows Filtering Platform som hindrar program från att nå DNS på adaptrar utanför tunneln. Den täcker TCP och UDP port 53. Eftersom filtret bor i WFP och inte i den vanliga regellistan i brandväggen ändrar en tillåtelseregel på annat håll inte nödvändigtvis resultatet. Därför fortsätter det vanliga rådet att tillåta DNS att misslyckas.

Inställningen kan komma från den importerade profilen eller från servern, och filen du senast redigerade "är inte bevis för vad klienten laddade". Läs den effektiva konfigurationen och anslutningsloggen tillsammans. Valet är också Windows-specifikt, och att behandla det som portabelt ger råd som inte gäller.

Leta efter klientkomponenten som äger begränsningen i stället för att lägga till fler regler. Ägaren är det som faktiskt kan ta bort den.

Ett filter är inte en resolver

Att blockera trafik utanför tunneln installerar inte en fungerande resolver inuti den. Valet tar bort en väg och lämnar tunnelns DNS-konfiguration till den som satte upp profilen. En profil som aldrig skickade någon resolver har nu ingen alls.

Gå igenom tre kontroller i ordning. Först, vilken resolver det misslyckade programmet faktiskt använder. Sedan, om klienten har tillämpat VPN-DNS-inställningarna. Till sist, vilket gränssnitt som bär trafiken till den resolvern.

  1. Resolver i bruk: jämför Resolve-DnsName -Server <resolver-ip> <name> med de DNS-servrar som ipconfig /all listar.
  2. VPN-DNS tillämpat: granska tunneladapterns DNS-poster i samma utdata från ipconfig /all.
  3. Gränssnitt som används: Find-NetRoute -RemoteIPAddress <resolver-ip> namnger det utgående gränssnittet för den destinationen.

En LAN-resolver blir onåbar av design under den här policyn, även medan annan LAN-trafik fungerar. Det är valet som gör sitt jobb. Om designen behöver VPN-DNS, rätta till resolverregistreringen och tunnelvägen; om delad DNS med lokala undantag krävs måste konfigurationens ägare uttrycka dessa undantag på ett stödd sätt.

Vad valet inte täcker

Port 53 är inte hela namnmatchningen. DNS over HTTPS och DNS over TLS använder andra transportvägar, och vissa program kör sin egen resolverlogik oavsett systeminställningar. En webbläsare kan därför matcha namn medan kommandoraden inte kan.

Behandla den skillnaden som diagnostik och inte som en motsägelse. Jämför de två innan du avgör att systemets resolver är trasig.

Håll slutsatsen snäv när du skriver den. Det här valet begränsar en transport på en plattform, och resten av matchningsvägen är en egen designfråga med sin egen ägare.

Kontrollera tillståndet före och efter frånkoppling

Kör samma sökning under anslutningen och igen efter att den ägande klienten kopplar från. Den första bör misslyckas för en extern resolver medan tunneln är uppe, och den andra bör lyckas när filtret är borttaget. Om det fortfarande misslyckas efter frånkopplingen rensades inte filtret.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Att starta om klienttjänsten eller maskinen rensar oftast ett gammalt filter. Det bekräftar diagnosen utan att bevisa en bestående lösning. Skriv ned vad du såg, för ett filter som överlever en frånkoppling gör det igen, och anteckningen är det som motiverar en felrapport.

Först efter dessa kontroller är det rimligt att byta resolver eller bygga om brandväggspolicyn. Båda är större ändringar än bevisen stöder.

Relaterade artiklar