VPN-ul s-a mutat: de ce clientul tău OpenVPN apelează în continuare IP-ul vechi

Furnizorul ți-a schimbat adresa publică, ai actualizat înregistrarea DNS dinamică, iar clientul tot nu se poate conecta. Din exterior pare că înregistrarea nu s-a propagat. De cele mai multe ori înregistrarea este în regulă și clientul apelează adresa pe care a rezolvat-o înainte de mutare, pentru că un tunel care rulează și un profil salvat au fiecare propria idee despre unde locuiește serverul. Trei straturi trebuie să fie de acord, iar ele se actualizează după calendare diferite.

Uită-te la ce apelează profilul, nu la ce spune DNS

Deschide conexiunea pe care o folosești de fapt și citește linia remote. O adresă numerică acolo nu urmează niciodată o actualizare a numelui de gazdă, oricât de corectă ar deveni înregistrarea.

Apoi verifică dacă profilul pe care l-ai editat este cel pe care clientul l-a încărcat. Profilele importate sunt obișnuite: un administrator poate să fi luat o copie acum câteva luni și să fi păstrat propria versiune, așa că fișierul din folderul de descărcări și intrarea din aplicație pot diferi. Compară punctul final din detaliile de conexiune ale clientului însuși înainte de a depana DNS-ul.

Două fișiere, un punct final — aceasta este constatarea obișnuită aici.

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

Citește următoarea încercare de conectare a clientului

Repornește conexiunea cu jurnalizare detaliată și citește linia în care este numită adresa cu care va contacta. Acea valoare contează, nu cea pe care a rezolvat-o browserul tău.

Cache-ul resolverului poate păstra încă răspunsul anterior, iar unele rețele îl păstrează mai mult decât cere TTL-ul înregistrării. Întreabă resolverul pe care clientul îl folosește de fapt, nu unul public pe care l-ai testat de altundeva.

Dacă jurnalul arată adresa nouă și conexiunea tot eșuează, problema s-a mutat: pachetul merge undeva și nimeni nu răspunde. Este o chestiune de listener, firewall sau redirecționare de port, și se află de partea serverului, nu pe calea de rezolvare a clientului. Ține cele două eșecuri separate, pentru că tratarea unui listener inaccesibil ca problemă DNS te plimbă de două ori prin aceeași buclă.

Știi ce repornire faci

Nu toate repornirile păstrează aceeași stare, de aceea o schimbare de adresă se poate comporta diferit în funcție de modul în care procesul este reciclat. O repornire blândă declanșată de un semnal păstrează mai mult context din sesiunea anterioară, în timp ce o oprire și pornire completă o iau de la configurație. Dacă testezi dacă clientul rezolvă din nou, vrei calea care pornește de la configurație.

Setările de persistență contează și ele, pentru că sunt făcute să păstreze ce a fost autentificat, nu să alerge după adrese noi.

Cel mai curat test este o pornire de la zero din profilul dorit, urmată de o privire la linia de jurnal care numește punctul final. Orice înveți dintr-o sesiune păstrată parțial este o afirmație despre acea sesiune.

Cele patru opțiuni și sarcinile lor separate

remote cu un nume de gazdă este setarea care face posibilă re-rezolvarea; o adresă literală pe acea linie o exclude. resolv-retry controlează ce se întâmplă când o căutare eșuează, iar 2.6 o setează deja implicit la infinit. Adăugarea ei nu schimbă deci nimic și nu programează niciodată o verificare periodică pentru alt răspuns. Cine spune că interoghează adrese noi a confundat recuperarea cu prospețimea.

persist-remote-ip ține de continuitate, nu de prospețime: refolosește punctul final care s-a autentificat ultima dată, de-a lungul repornirilor blânde pe care le suportă. Cât timp testezi o mutare, este opusul a ceea ce vrei. Dezactivează-l pentru test dacă buildul tău îl activează, apoi restaurează-l după ce noul punct final este dovedit. Lăsat activ, o reconectare reușită s-ar putea să nu-ți spună nimic despre DNS.

float acceptă un partener autentificat a cărui adresă s-a schimbat la mijlocul sesiunii, și numai în configurații care acceptă asta. Nu reîmprospătează DNS-ul și nu va urmări singur o schimbare de furnizor. Tratează-l ca funcție de reziliență pentru parteneri care hoinăresc, nu ca mecanism de adrese dinamice pentru servere.

Confirmă noul punct final înainte de a da vina pe client

Din afara rețelei tale, verifică dacă adresa nouă are un listener pe portul configurat și dacă redirecționarea furnizorului indică spre ea. O înregistrare A corectă pentru o mașină fără port deschis produce exact simptomul pe care oamenii îl atribuie cache-ului.

Apoi reconectează-te și verifică două lucruri: clientul s-a autentificat față de certificatul de server așteptat, iar sesiunea ajunge la resursa pe care o aveai în vedere. O schimbare de adresă nu scade cerințele de identitate, iar o conexiune care reușește spre punctul final greșit este mai rea decât una care eșuează. Manualul OpenVPN 2.6 enumeră toate cele patru opțiuni cu domeniul lor propriu, iar acesta este lista de verificare de ținut lângă profil.

Păstrează o cale în afara benzii către server înainte de a reporni tunelul care transportă accesul tău administrativ. Acea singură precauție previne majoritatea incidentelor pe care le produce acest scenariu.