VPN-endepunktnavn kontra privat tjenestenavn: to ejere

To navne kan beskrive samme filial og svare på helt forskellige spørgsmål. vpn.branch.example fortæller en fjern peer, hvor VPN-endepunktet findes, og det skal slås op, før der findes nogen tunnel. inventory.branch.example fortæller en autoriseret bruger, hvor en privat applikation bor, og det betyder først noget, når tunnelen er oppe. Vedligeholdelse af det ene gør intet for det andet.

Navngiv de to poster, før du fejlfinder nogen af dem

Skriv begge ned sammen med deres ejere. For endepunktet skal du notere, hvem der opdaterer den offentlige adresse, og hvordan VPN-klienten fornyer sit svar. For tjenesten skal du notere, hvem der ejer den private adresse, hvilken zone der holder posten, og hvilke resolvere der skal svare for den.

Den korte liste forhindrer den mest almindelige fejldiagnose på området: at genstarte en fungerende filialtunnel for at reparere en post, der udelukkende lever inde i den. Tunnelen er transporten for tjenestenavnet; den er ikke autoriteten for det.

Når en ændring foreslås, så spørg, hvilken af de to poster den berører. Kan ingen svare, er ændringen ikke klar til planlægning.

Endepunktet skal slås op, før der findes nogen tunnel

Antag, at filialens internetforbindelse får en ny offentlig adresse. Endepunktsopdateringen offentliggør den nye adresse, og den fjernede VPN-implementering skal kunne læse det ændrede svar. Hvilken resolver der end leverer svaret, skal den være tilgængelig uden tunnelen, ellers jager klienten et navn, den først kan slå op, efter den har forbundet til det, den ikke kan finde.

Den bootstrap-afhængighed er værd at sige ligeud, fordi den let opstår ved et uheld, når alle interne resolvere ligger bag VPN’en. Hold en sti før tunnelen til endepunktopslaget, og bekræft klientens genopkoblingsadfærd i stedet for at antage, at et nyt svar samles op med det samme.

Dynamisk DNS har også grænser, som postopdateringen ikke kan krydse. Opdatering af en post åbner ingen firewallport, skaber ingen NAT-mapping og beviser ingen peer-identitet. En offentliggjort adresse med lukket port giver en klient, der slår korrekt op og stadig ikke kan forbinde til noget.

Endelig kan en kørende klient fortsætte med at bruge et cachet endepunkt, indtil den genopkobler. Adskil offentliggørelse, cache og genopkoblingspolitik i dine noter, så en forældet peer ikke forveksles med en defekt opdatering.

Tjenestenavnet beskriver, hvor applikationen bor

Antag nu, at tunnelen forbliver sund, men at inventarserveren flytter fra 172.26.14.20 til 172.26.14.35. Den offentlige endepunktspost er upåvirket, mens den private tjenestepost skal ændres. Brug af en adresse reserveret til den tjeneste eller en statisk tildeling gør dette sjældnere; en autoriseret opdateringssti håndterer de gange, hvor det er hensigten.

To opdateringsmekanismer sammenblandes her. RFC 2136 definerer en protokol til at tilføje og slette DNS-poster i en zone, mens en kommerciel udbyder af dynamisk DNS kan udstille en helt anden HTTP-API til et andet formål. Brug af den ene betyder ikke, at den anden findes i dit miljø. Tjek, hvilken mekanisme din zone faktisk accepterer, før du skriver en opdatering imod den.

Et korrekt privat svar er kun den første betingelse. For at en fjern kalder kan bruge det, har klienten brug for en resolver, der fører den private zone, en politik der tillader forespørgsler til den resolver, og videresendelse for den adresse, der kommer tilbage. Et navn, der slår op i en adresse, klienten ikke kan nå, giver en timeout, der ligner en serverfejl.

Test de to stier hver for sig

Tjek endepunktet udefra tunnelen og tjenesten indefra, og hold resultaterne som to uafhængige 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 forespørgsel fejler, er problemet offentliggørelse eller opløsningsstien før tunnelen, og ingen intern ændring hjælper. Hvis den anden returnerer en adresse, men den tredje ikke viser nogen rute gennem tunnelen, er DNS-laget i orden, og videresendelsespolitikken er det ikke.

Kør parret efter hver adresseændring, og noter, hvilken post der flyttede sig. En overdragelse, der kun siger »DNS blev opdateret«, efterlader den næste ingeniør til at gætte, hvilken af de to livscyklusser der faktisk kørte.