VPN:t flyttade: varför din OpenVPN-klient fortfarande ringer den gamla IP-adressen

Leverantören ändrade din publika adress, du uppdaterade den dynamiska DNS-posten, och klienten kan fortfarande inte ansluta. Utifrån ser det ut som om posten inte har spridits. Oftast är posten i ordning och klienten ringer den adress den löste upp före flytten, eftersom en tunnel som körs och en sparad profil har var sin uppfattning om var servern bor. Tre lager måste stämma överens, och de uppdateras enligt olika scheman.

Titta på vad profilen ringer, inte vad DNS säger

Öppna anslutningen du faktiskt använder och läs remote-raden. En numerisk adress där följer aldrig en uppdatering av värdnamnet, hur korrekt posten än blir.

Kontrollera sedan om profilen du redigerade är den klienten läste in. Importerade profiler är vanliga: en administratör kan ha tagit en kopia för månader sedan och behållit sin egen version, så filen i din nedladdningsmapp och posten i appen kan skilja sig. Jämför slutpunkten i klientens egna anslutningsuppgifter innan du ens börjar felsöka DNS.

Två filer, en slutpunkt — det är det vanliga fyndet här.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Läs klientens nästa anslutningsförsök

Starta om anslutningen med utförlig loggning och läs raden där adressen den ska kontakta namnges. Det värdet är det viktiga, inte det din webbläsare löste upp.

En resolvercache kan fortfarande hålla det tidigare svaret, och vissa nätverk behåller det längre än postens TTL kräver. Fråga resolvern klienten faktiskt använder, inte en offentlig du testade från någon annanstans.

Om loggen visar den nya adressen och anslutningen fortfarande misslyckas har problemet flyttat: paketet går någonstans och ingen svarar. Det är en fråga om lyssnare, brandvägg eller portvidarebefordran, och den ligger på serversidan snarare än i klientens upplösningsväg. Håll de två felen åtskilda, för att behandla en oåtkomlig lyssnare som ett DNS-problem skickar dig två gånger genom samma slinga.

Vet vilken omstart du gör

Inte alla omstarter bevarar samma tillstånd, och därför kan en adressändring bete sig olika beroende på hur processen återvinns. En mjuk omstart utlöst av en signal bevarar mer av den föregående sessionens kontext, medan ett fullt stopp och start börjar om från konfigurationen. Om du testar om klienten löser upp på nytt vill du ha vägen som börjar från konfigurationen.

Inställningar för beständighet spelar också roll, eftersom de är gjorda för att bevara det som autentiserades, inte för att jaga nya adresser.

Det renaste testet är en ny start från den avsedda profilen, följt av en titt på loggraden som namnger slutpunkten. Allt du lär dig av en delvis bevarad session är ett påstående om den sessionen.

De fyra alternativen och deras separata jobb

remote med ett värdnamn är inställningen som gör ny upplösning möjlig över huvud taget; en bokstavlig adress på den raden utesluter det. resolv-retry styr vad som händer när en sökning misslyckas, och 2.6 sätter den redan som standard till oändlig. Att lägga till den ändrar därför ingenting, och den schemalägger aldrig en periodisk kontroll efter ett annat svar. Den som säger att den pollar nya adresser har förväxlat återställning med färskhet.

persist-remote-ip handlar om kontinuitet snarare än färskhet: den återanvänder slutpunkten som autentiserade senast, över de mjuka omstarter den stöder. Medan du testar en flytt är det motsatsen till vad du vill. Inaktivera den för testet om din build aktiverar den, och återställ den när den nya slutpunkten är bevisad. Lämnad på kan en lyckad återanslutning inte berätta något om DNS.

float accepterar en autentiserad peer vars adress ändrades mitt i sessionen, och bara i uppsättningar som stöder det. Den uppdaterar inte DNS och kommer inte att följa en leverantörsändring av sig själv. Behandla den som en robusthetsfunktion för peers som rör sig, inte som en mekanism för dynamiska adresser för servrar.

Bekräfta den nya slutpunkten innan du skyller på klienten

Utanför ditt nätverk, kontrollera att den nya adressen har en lyssnare på den konfigurerade porten och att leverantörens vidarebefordran pekar på den. En korrekt A-post för en maskin utan öppen port ger exakt det symptom folk tillskriver cachen.

Anslut sedan igen och verifiera två saker: klienten autentiserade mot det förväntade servercertifikatet, och sessionen når resursen du hade för avsikt. En adressändring sänker inte identitetskraven, och en anslutning som lyckas till fel slutpunkt är värre än en som misslyckas. OpenVPN 2.6-handboken listar alla fyra alternativen med sin egen omfattning, och det är checklistan som ska ligga vid profilen.

Håll en väg utanför bandet in till servern innan du startar om tunneln som bär din administratörsåtkomst. Den enda försiktighetsåtgärden förhindrar de flesta incidenter som detta scenario skapar.