Adresa peerului s-a schimbat la mijlocul sesiunii: ce face float în OpenVPN

Laptopul trece de la Wi-Fi-ul biroului la hotspotul unui telefon, tunelul rezistă încă câteva secunde, apoi traficul se oprește în timp ce interfața continuă să susțină că este conectată. Pe server, lista de stare arată în continuare vechea adresă publică. Aceasta este situația pentru care există float și totodată situația în care oamenii se așteaptă la mult mai mult decât face. Înțelegerea corectă a graniței transformă o blocare derutantă fie într-o modificare de configurare de o linie, fie într-o cu totul altă investigație.

Ce relaxează float și ce nu relaxează niciodată

De obicei o sesiune continuă să vorbească cu adresa și portul exterioare cu care a început, iar pachetele care sosesc de oriunde altundeva sunt ignorate. Opțiunea float elimină această legare strictă după ce peerul s-a dovedit deja, astfel încât o mapare de sursă schimbată poate continua aceeași sesiune în loc să fie aruncată. Nimic din verificările criptografice nu se schimbă: cheile, certificatele și orice protecție HMAC rămân exact așa cum au fost configurate.

Este o decizie pentru fiecare pachet, nu o politică despre cine se poate conecta. O mașină necunoscută care trimite un pachet de la o adresă nouă nu a dovedit nimic, iar pachetul ei este aruncat ca orice alt trafic neautentificat. Numai traficul care trece de autentificarea proprie a sesiunii poate muta adresa peerului înregistrată, și de aceea este sigur să lăsați float activat în medii în care clienții se deplasează.

Nu spune nimic nici despre tunelul interior. O adresă exterioară mutată nu realocă o adresă de tunel, nu schimbă pool-ul și nu îi dă peerului acces la ceva nou. În interiorul tunelului, aceeași identitate și aceleași rute împinse se aplică înainte și după mutare. O deplasare nu renegociază nici canalul de date, așa că cifrul și cheile negociate continuă.

Pachetul care mută o sesiune trebuie să se autentifice

Porniți o sesiune în modul obișnuit către capătul îndepărtat configurat, iar float se ocupă de ce se întâmplă când maparea se schimbă. Un operator mobil care renumerotează la mijlocul fluxului, o poartă NAT care își rescrie maparea de port sau un laptop care schimbă legătura superioară produc toate aceeași formă: pachete autentificate dintr-un tuplu nou, care ajung într-o sesiune ce încă mai crede în cel vechi.

Când vi se cere să spuneți dacă float funcționează, dovada utilă este o strângere de mână finalizată urmată de o schimbare de sursă acceptată, nu o linie de jurnal doar despre adresă. Corelați adresele exterioare veche și nouă cu sesiunea care a rămas în viață, apoi confirmați că traficul a continuat într-adevăr prin tunel.

Dacă sesiunea moare în loc să se mute, pachetul sosit de la adresa nouă probabil a eșuat autentificarea sau nu a ajuns deloc. Ambele cazuri arată identic din partea clientului. Pe server, o captură pe interfața publică vă spune care dintre ele este cazul înainte de a atinge orice configurație.

Descoperirea este un mecanism complet separat

float nu rezolvă nume pe un temporizator și nu urmărește o înregistrare DNS dinamică. Dacă numele de gazdă al serverului începe să se rezolve către o adresă nouă, un client inactiv nu are niciun motiv să observe acest lucru și niciun pachet de la noul punct terminal pe care să îl autentifice. Acea problemă aparține logicii de reconectare, comportamentului de reîncercare al clientului însuși și DNS-ului, nu lui float.

Adăugarea opțiunii încă o dată nu poate compensa lipsa unei rute către adresa nouă. Nu ajută nici când peerul tace, pentru că un peer tăcut nu trimite niciodată pachetul autentificat care ar muta ceva.

Firewall-ul de dedesubt are și el un cuvânt. O regulă care permite doar vechiul punct terminal exterior blochează adresa schimbată înainte ca OpenVPN să o vadă măcar, iar nicio configurație din partea clientului nu remediază asta. Revedeți ciclul de viață al adreselor permise ca o sarcină separată; lărgirea regulii la orice sursă schimbă o problemă mică pe una mare.

Când NetworkManager deține profilul

Un profil din linia de comandă și o conexiune importată sunt configurații separate, iar editarea uneia nu o atinge pe cealaltă. Înainte de a presupune că opțiunea nu este acceptată, stabiliți ce tip de plugin folosește de fapt profilul salvat și unde îi trăiesc valorile. UUID-ul profilului este identificatorul care contează când inspectați sau modificați ceva.

Inspectați conexiunea salvată, nu fișierul de import original. O linie care supraviețuiește într-un fișier .ovpn nu dovedește nimic dacă managerul activ nu a aplicat-o niciodată, iar un editor fără casetă de bifare pentru o anumită opțiune nu dovedește nici el nimic despre capacitățile protocolului.

Nu peticiți un plugin împachetat ca să adăugați comportamentul, mai ales nu cu un diff scris pentru o versiune istorică a unei componente nelegate. Dacă integrarea instalată chiar nu poate exprima setarea, pasul corect este un profil acceptat sau o altă cale de client aprobată de cel care deține implementarea.

Dovediți tranziția în loc să o presupuneți

Rulați testul așa cum se produce defecțiunea. Conectați-vă, verificați traficul prin tunel, forțați schimbarea adresei exterioare și apoi verificați trei lucruri: sesiunea există încă, adresa peerului înregistrată s-a mutat și o cerere reală ajunge încă la destinație. Orice lucru mai puțin decât toate trei este un răspuns parțial.

Păstrați accesul de recuperare disponibil în timp ce testați, pentru că experimentele de roaming au obiceiul de a lăsa mașina de la care lucrați blocată. O consolă serială sau o rută în afara benzii transformă un test eșuat într-o recuperare de cinci minute în loc de o vizită la fața locului.

În final, descrieți doar cazul pe care l-ați exersat. O schimbare reușită de adresă în timpul unei sesiuni nu este dovada că migrările DNS, o altă implementare de client sau un profil reconstruit se vor comporta la fel. Documentația link-options precizează domeniul opțiunii; jurnalul de test ar trebui să spună ce parte din acel domeniu ați acoperit efectiv.