Din VPN-domän i dnsmasq är inte en zonöverföring

Du letar efter företagszonen i klientens dnsmasq-konfiguration, hittar den inte och drar slutsatsen att VPN:en misslyckades med att pusha sin domän. Det som pushades är en routingledtråd, inte en zon. Klienten registrerar domänen och resolvern som ska svara för den, och den hanterade backenden gör det till villkorlig vidarebefordran. Att titta på fel ställe ger en självsäker och helt felaktig diagnos.

Det klienten accepterade är inte det gatewayen erbjöd

En gateway kan erbjuda en resolver, en domän och den rutt som behövs för att nå den resolvern, och klienten kan acceptera alla tre eller ingen av dem. En importerad profil, ett hjälpskript eller en policy som ignorerar pushade alternativ kan lämna den accepterade mängden tom medan serversidan ser korrekt ut. Börja med klientens registrerade tillstånd i stället för serverns konfiguration, eftersom det tillståndet är vad resolvern faktiskt tar emot. Saknas den accepterade domänen spelar inget längre fram någon roll. Kontrollera anslutningens DNS-egenskaper innan du undersöker någon cache.

Den skillnaden förklarar de flesta rapporter om en domän som aldrig kom fram. Den erbjöds och den tillämpades inte.

Två slags domänposter

En anslutning kan bära vanliga sökdomäner och endast-rutt-domäner, och den andra sorten börjar med en tilde. En sökdomän både dirigerar frågor och låter korta namn expandera, vilket är bekvämt på en arbetsstation och överraskande på en server. En endast-rutt-domän säger att frågor för det suffixet ska gå till specifika servrar utan att ändra hur korta namn löses upp. Att skriva samma domän på båda sätten är inte redundans, eftersom de två posterna gör olika saker.

För ett privat namnutrymme är endast-rutt-formen oftast den du vill ha. Den håller företagssuffixet pekat mot företagsresolvern och lämnar allt annat i fred.

localhost i resolv.conf är inte en bugg

När en lokal cachelösare används pekar systemfilen på loopback-adressen och inget annat. Den posten identifierar den lokala lyssnaren, inte de uppströms servrar som hanteraren gav den. Företagsadressen saknas med rätta i filen.

Att byta ut den posten mot en offentlig resolver är den klassiska felrättningen. Den återställer offentlig namnmatchning och kastar bort den villkorliga policyn i samma ändring.

Blanda inte ihop backendsarna

En hanterad dnsmasq-instans och en systemresolver är olika program med olika konfiguration och olika statusvyer. Ett statuskommando för den ena rapporterar inget användbart om den andra.

Ta reda på vilken backend hanteraren är konfigurerad att använda och läs sedan den backendens genererade konfiguration i stället för en distributionsövergripande fil som råkar finnas. Hanteraren skriver sin egen instanskonfiguration och stöder anpassade alternativ för den instansen, så att redigera en orelaterad global fil ändrar inget och ser ut som en ändring utan effekt. Att starta en andra daemon på port 53 är värre än värdelöst, för nu är två program oense om vem som äger porten. Fastställ ägaren först och redigera sedan där ägaren läser.

Testa namnutrymmet, inte bara svaret

Fråga efter ett tillåtet privat namn och ett offentligt kontrollnamn via programmets normala väg. En direkt fråga mot företagsservern bevisar att posten finns; den bevisar inte att klienten valde den servern. Den andra frågan är den som testar policyn.

Upprepa sedan efter en återanslutning och efter en frånkoppling. Associationen bör följa anslutningens livscykel, och de privata namnen bör sluta lösas när tunneln är borta i stället för att falla tillbaka på en offentlig resolver som svarar för samma suffix. Om de faller tillbaka har du hittat en läcka, vilket är en annan defekt än en trasig uppslagning. Skriv ned vilken backend som kördes, vilka domäner som tillämpades och vad varje fråga returnerade.