VPN-endepunktnavn kontra navn på privat tjeneste: to eiere

To navn kan beskrive samme filial og svare på helt forskjellige spørsmål. vpn.branch.example forteller en ekstern peer hvor VPN-endepunktet finnes, og det må slås opp før noen tunnel eksisterer. inventory.branch.example forteller en autorisert bruker hvor en privat applikasjon bor, og det har først betydning når tunnelen er oppe. Vedlikehold av det ene gjør ingenting for det andre.

Navngi de to oppføringene før du feilsøker noen av dem

Skriv ned begge sammen med eierne deres. For endepunktet, noter hvem som oppdaterer den offentlige adressen og hvordan VPN-klienten fornyer svaret sitt. For tjenesten, noter hvem som eier den private adressen, hvilken sone som holder oppføringen og hvilke resolvere som skal svare for den.

Den korte listen forhindrer den vanligste feildiagnosen på området: å starte en fungerende filialtunnel på nytt for å reparere en oppføring som utelukkende lever inne i den. Tunnelen er transporten for tjenestenavnet; den er ikke autoriteten for det.

Når en endring foreslås, spør hvilken av de to oppføringene den berører. Hvis ingen kan svare, er endringen ikke klar til planlegging.

Endepunktet må slås opp før noen tunnel eksisterer

Anta at filialens internettforbindelse får en ny offentlig adresse. Endepunktsoppdatereren publiserer den nye adressen, og den eksterne VPN-implementasjonen må kunne lese det endrede svaret. Hvilken resolver som enn leverer svaret, må den være tilgjengelig uten tunnelen, ellers jager klienten et navn den bare kan slå opp etter å ha koblet til det den ikke finner.

Den oppstartsavhengigheten er verdt å si rett ut, fordi den lett oppstår ved et uhell når alle interne resolvere sitter bak VPN-en. Hold en sti før tunnelen for endepunktoppslaget, og bekreft klientens gjenoppkoblingsatferd i stedet for å anta at et nytt svar plukkes opp med en gang.

Dynamisk DNS har også grenser som oppføringsoppdateringen ikke kan krysse. Oppdatering av en oppføring åpner ingen brannmurport, lager ingen NAT-mapping og beviser ingen peer-identitet. En publisert adresse med lukket port gir en klient som slår opp riktig og fortsatt ikke kan koble til noe.

Til slutt kan en kjørende klient fortsette å bruke et bufret endepunkt til den kobler til på nytt. Skill publisering, buffer og gjenoppkoblingspolicy i notatene dine, slik at en utdatert peer ikke forveksles med en defekt oppdaterer.

Tjenestenavnet beskriver hvor applikasjonen bor

Anta nå at tunnelen forblir sunn, men at inventarserveren flytter fra 172.26.14.20 til 172.26.14.35. Den offentlige endepunktoppføringen er upåvirket, mens den private tjenesteoppføringen må endres. Bruk av en adresse reservert for den tjenesten, eller en statisk tildeling, gjør dette sjeldnere; en autorisert oppdateringssti håndterer gangene det er meningen.

To oppdateringsmekanismer blandes sammen her. RFC 2136 definerer en protokoll for å legge til og slette DNS-oppføringer i en sone, mens en kommersiell leverandør av dynamisk DNS kan eksponere et helt annet HTTP-API for et annet formål. Bruk av det ene betyr ikke at det andre finnes i miljøet ditt. Sjekk hvilken mekanisme sonen din faktisk godtar før du skriver en oppdaterer mot den.

Et korrekt privat svar er bare den første betingelsen. For at en ekstern kaller skal kunne bruke det, trenger klienten en resolver som fører den private sonen, en policy som tillater spørringer til den resolveren, og videresending for adressen som kommer tilbake. Et navn som slår opp til en adresse klienten ikke kan nå, gir en tidsavbrudd som ser ut som en serverfeil.

Test de to stiene hver for seg

Sjekk endepunktet fra utsiden av tunnelen og tjenesten fra innsiden, og hold resultatene som to uavhengige fakta:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Hvis den første spørringen feiler, er problemet offentlig publisering eller oppslagsstien før tunnelen, og ingen intern endring vil hjelpe. Hvis den andre returnerer en adresse men den tredje ikke viser noen rute gjennom tunnelen, er DNS-laget i orden og videresendingspolicyen er det ikke.

Kjør paret etter hver adresseendring, og noter hvilken oppføring som flyttet seg. En overlevering som bare sier «DNS ble oppdatert», lar den neste ingeniøren gjette hvilken av de to livssyklusene som faktisk kjørte.