VPN-slutpunktsnamn kontra namn på privat tjänst: två ägare

Två namn kan beskriva samma filial och svara på helt olika frågor. vpn.branch.example talar om för en avlägsen peer var VPN-slutpunkten finns, och den måste lösas upp innan någon tunnel existerar. inventory.branch.example talar om för en behörig användare var en privat applikation bor, och det spelar först roll när tunneln är uppe. Underhåll av det ena gör ingenting för det andra.

Namnge båda posterna innan du felsöker någon av dem

Skriv ner båda tillsammans med deras ägare. För slutpunkten, notera vem som uppdaterar den offentliga adressen och hur VPN-klienten förnyar sitt svar. För tjänsten, notera vem som äger den privata adressen, vilken zon som håller posten och vilka resolvers som ska svara för den.

Den korta listan förhindrar den vanligaste feldiagnosen på området: att starta om en fungerande filialtunnel för att reparera en post som lever helt och hållet inuti den. Tunneln är transporten för tjänstenamnet; den är inte dess auktoritet.

När en ändring föreslås, fråga vilken av de två posterna den rör. Om ingen kan svara är ändringen inte redo att planeras.

Slutpunkten måste lösas upp innan någon tunnel existerar

Anta att filialens internetanslutning får en ny offentlig adress. Slutpunktsuppdateraren publicerar den nya adressen, och den avlägsna VPN-implementeringen måste kunna läsa det ändrade svaret. Vilken resolver som än levererar svaret måste vara nåbar utan tunneln, annars jagar klienten ett namn som den bara kan lösa upp efter att ha anslutit till det den inte hittar.

Det beroendet vid start är värt att säga rakt ut, eftersom det lätt uppstår av misstag när alla interna resolvers sitter bakom VPN:en. Behåll en väg före tunneln för slutpunktsuppslaget, och bekräfta klientens återanslutningsbeteende i stället för att anta att ett nytt svar tas upp omedelbart.

Dynamisk DNS har också gränser som postuppdateringen inte kan passera. Att uppdatera en post öppnar ingen brandväggsport, skapar ingen NAT-mappning och bevisar ingen peer-identitet. En publicerad adress med stängd port ger en klient som löser upp korrekt och ändå inte kan ansluta till något.

Slutligen kan en körande klient fortsätta använda en cachad slutpunkt tills den återansluter. Separera publicering, cache och återanslutningspolicy i dina anteckningar, så att en inaktuell peer inte förväxlas med en trasig uppdaterare.

Tjänstenamnet beskriver var applikationen bor

Anta nu att tunneln förblir frisk men att inventarieservern flyttar från 172.26.14.20 till 172.26.14.35. Den offentliga slutpunktsposten påverkas inte, medan den privata tjänsteposten måste ändras. Att använda en adress reserverad för den tjänsten, eller en statisk tilldelning, gör detta ovanligare; en behörig uppdateringsväg hanterar de gånger det är avsiktligt.

Här blandas två uppdateringsmekanismer ihop. RFC 2136 definierar ett protokoll för att lägga till och ta bort DNS-poster i en zon, medan en kommersiell leverantör av dynamisk DNS kan exponera ett helt annat HTTP-API för ett annat syfte. Att använda det ena innebär inte att det andra finns i din miljö. Kontrollera vilken mekanism din zon faktiskt accepterar innan du skriver en uppdaterare mot den.

Ett korrekt privat svar är bara det första villkoret. För att en avlägsen anropare ska kunna använda det behöver klienten en resolver som bär den privata zonen, en policy som tillåter frågor till den resolvern och vidarebefordran för adressen som kommer tillbaka. Ett namn som löses upp till en adress som klienten inte kan nå ger en tidsgräns som ser ut som ett serverfel.

Testa de två vägarna separat

Kontrollera slutpunkten från utsidan av tunneln och tjänsten från insidan, och håll resultaten som två oberoende 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

Om den första frågan misslyckas är problemet offentlig publicering eller upplösningsvägen före tunneln, och ingen intern ändring hjälper. Om den andra returnerar en adress men den tredje inte visar någon rutt genom tunneln är DNS-lagret i ordning och vidarebefordringspolicyn inte det.

Kör paret efter varje adressändring och notera vilken post som flyttades. En överlämning som bara säger ”DNS uppdaterades” lämnar nästa ingenjör att gissa vilken av de två livscyklerna som faktiskt kördes.