Inaktuell DDNS-post eller trasig VPN-slutpunkt: så skiljer du dem åt

Utifrån ser ett inaktuellt värdnamn och en trasig VPN identiska ut. Klienten slår upp ett namn, namnet pekar någonstans, och anslutningen antingen times out eller avvisas. Det ena är ett DNS-uppdateringsproblem, det andra ett autentiserings- eller vidarebefordringsproblem, och skillnaden blir tydlig först när du jämför den publicerade adressen med den adress som din linje faktiskt har.

Två fel som ser likadana ut

Det första felet är att posten fortfarande listar gårdagens WAN-adress. Det andra är att posten är korrekt och tunneln avvisar dig av sina egna skäl. Båda ger samma meddelande i klienten, och frestelsen är att börja återskapa certifikat.

Ordningen spelar roll här. Att kontrollera DNS tar en minut och går att ångra. Att återskapa en CA är inget av det.

Jämför adresserna före allt annat

Fråga nätverkets ägare vilken adress linjen har just nu och fråga sedan DNS vad den publicerar. dig +short vpn.example.com ger svaret som din klient får, och dig @1.1.1.1 vpn.example.com visar om en annan resolver ser något annat. Om de två inte stämmer överens tittar du på cachebeteende och inte på en trasig uppdaterare.

Ett rekursivt svar kan släpa efter en uppdatering med sin TTL, så håll den auktoritativa posten och det som din laptop har cachat i separata lådor.

Vad uppdaterarens uppgift egentligen är

Äldre DDNS-enheter autentiserar ofta med själva kontolösenordet, och därför bryter ett byte av lösenordet dem tyst. De fortsätter att försöka med det gamla värdet och rapporterar inget användbart. No-IP:s vägledning för enhetslösenord dokumenterar just detta kompatibilitetsproblem på äldre hårdvara, och det förnuftiga svaret är en avgränsad uppdateringsuppgift i stället för ett svagare kontolösenord.

Nyare mekanismer utfärdar en separat uppdateringstoken eller nyckel med egen livscykel. Det är värdet du ska rotera in i routern, och det du ska logga i ditt uppgiftsregister. Det är inte heller värdet du ska klistra in i en chattråd medan du felsöker.

Granska uppdaterarens icke-hemliga status: tidpunkt för senaste lyckade, svarskategori och det värdnamn som den anser sig äga. Ett avslag på uppgiften och ett anslutningsfel kräver olika åtgärder.

Vad en DNS-rättelse inte kan göra

Att rätta posten skapar ingen inkommande nåbarhet. Om linjen sitter bakom carrier-grade NAT kommer inget värdnamn att få en inkommande anslutning att fungera. Det öppnar inte heller en brandväggsregel eller vidarebefordrar en port. Och det är aldrig ett skäl att stänga av serververifiering i klienten, vilket är draget folk gör när de bestämmer sig för att certifikatet måste vara problemet.

Omvänt är ett byte av VPN-lösenord ingen rättelse av inaktuell DNS. Det lägger bara till ett andra fel i samma ärende.

Återanslut och bevisa det från början till slut

När den auktoritativa posten är rätt, kan klienten fortfarande hålla en gammal uppslagning. Använd dess stödda återanslutning eller slutpunktsuppdatering och ge den ett ögonblick i stället för att hamra på anslut. Bevisa sedan vägen i fyra steg: slå upp namnet, bekräfta adressen, kontrollera att lyssnaren är nåbar och autentisera. Fyra separata resultat, fyra separata svar.

Håll uppdateraren på rotationschecklistan bredvid VPN-kontot. En avsedd postägare, en giltig uppgift och en observerbar framgång är det som förhindrar nästa version av detta ärende.