De tunnel staat, dus waarom faalt de privénaam nog steeds?

Alles aan de verbinding ziet er goed uit: de tunnel staat en de console toont het privé-eindpunt, maar elk verzoek faalt op naamresolutie. De natuurlijke stap is de tunnel de schuld geven, die meestal onschuldig blijkt. De query gaat naar een server die niets van de privézone weet. Geen routewijziging zal dat antwoord veranderen, want het probleem is wie er gevraagd is.

Welke resolver bereikte de query?

Zoek de resolver die aan elke verbinding hangt voordat je überhaupt naar de tunnel kijkt. Linux toont servers per verbinding via de resolver-statusopdracht, en macOS toont scoped resolvers in zijn DNS-configuratiedump. Komt het antwoord nog van de thuisrouter, dan is de tunnelverbinding nooit geraadpleegd.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Hier worden twee fasen verward: een server die een resolveradres pusht, en een client die het op de actieve verbinding installeert. Een profiel kan de optie bevatten en een log kan tonen dat die aankomt, terwijl het besturingssysteem de oude server blijft gebruiken. Vergelijk het log met wat de verbinding meldt, en vertrouw de verbinding.

Gebruik een adres waarop het cloudnetwerk echt antwoordt

Cloudnetwerken antwoorden privénamen meestal via een gereserveerd adres dat twee plaatsen boven de basis van het bereik ligt, dus een netwerk dat bij 10.0.0.0 begint, antwoordt op 10.0.0.2. Sommige providers publiceren ook een link-lokale resolver die werkt zonder het bereik te kennen, wat helpt wanneer iemand anders het netwerk heeft gebouwd. Vraag het kandidaatadres rechtstreeks voordat je het naar iemand pusht. Een adres dat geen resolver is, lijkt precies op een firewall-drop, omdat de query simpelweg nooit een antwoord krijgt.

Als de directe query van binnen het netwerk antwoordt maar niet via de tunnel, is de resolver in orde en de route tussen de twee punten niet. Dat resultaat verplaatst het onderzoek naar routes, doorsturen en toegangsregels in plaats van het clientprofiel.

Een tunnel draagt de naamruimte niet

Pakketten gaan erdoor; namen niet. Elke kant moet weten welke naamruimte bij de andere hoort, en dat is een apart object dat eigendom is van wie de zone heeft. De gebruikelijke vorm is een doorsturing voor één naamruimte, gericht op een resolver die via de tunnel bereikbaar is.

In de praktijk heeft elke richting zijn eigen regel nodig, omdat de kant die de zone bezit de query moet doorsturen. Beide richtingen vereisen dat de bron van de query wordt gerouteerd en toegestaan, en de antwoordende kant moet antwoorden via de tunnel terugsturen in plaats van naar het internet. Houd de doorsturing smal, zodat alleen de privénaamruimte van de verbinding afhangt. Elke query erdoor sturen maakt van een kleine afhankelijkheid een totale storing op het moment dat de tunnel valt.

Loop de grenzen in volgorde langs

Test de resolver die op de actieve verbinding is geïnstalleerd, dan een directe query naar die resolver, dan dezelfde query vanaf de andere kant, en ten slotte de applicatie die dezelfde naam gebruikt. Elke stap isoleert één grens, dus een fout zegt waar je moet kijken in plaats van het onderzoek opnieuw te beginnen. Een antwoord dat werkt terwijl de applicatie faalt, wijst op certificaatvertrouwen of een API-beleid in plaats van DNS. Die fouten zijn echt, en geen resolverwijziging zal ze herstellen.

Schrijf op welke stap faalde. Die ene regel is wat de volgende persoon nodig heeft, en het opschrijven kost tien seconden.

Houd de keten waar de volgende persoon hem kan vinden

Leg de gepushte resolver, de doorstuurregel, de toegestane querybron en het antwoordende eindpunt op één plek vast. Als de privénaam weer faalt, laat het record zien of de tunnel verschoof, het resolveradres veranderde of een regel werd versmald. Zonder dat begint elk incident bij nul en eindigt het met dezelfde drie gissingen.

Houd het record kort genoeg om nauwkeurig te blijven: vier regels, een datum en de naam van wie elk deel bezit. Een verouderd record is erger dan geen, want het lijkt gezaghebbend terwijl het fout is.