Pornirea unui al doilea VPN înlocuiește starea primului

Doi clienți, două pictograme conectate și convingerea că traficul trece acum prin amândouă. Comparați această convingere cu ceea ce permite fiecare platformă în realitate. Un telefon are de obicei exact un singur slot pentru un serviciu VPN; un desktop poate rula mai mulți clienți care se luptă pentru aceleași rute și același resolver. Diferența dintre aceste două situații explică majoritatea rapoartelor despre un VPN care cade când pornește altul.

Pictogramele descriu procese, nu un lanț.

Un slot pe telefon, mai mulți pretendenți pe desktop

Pe Android, platforma oferă un model de serviciu VPN cu un singur VPN activ pe profil de utilizator, așa că pornirea unui al doilea îl oprește pe primul. Este sistemul care își aplică propria regulă, nu o eroare în vreunul dintre clienți. Pe un desktop, mai mulți clienți pot rula simultan, iar apoi concurează pentru tabelul de rutare, regulile de politică, configurația resolverului și interfețele virtuale. Ambele rezultate sunt platforma funcționând conform proiectării.

Niciunul dintre rezultate nu produce de unul singur un tunel imbricat. Un lanț cere ca un tunel să transporte pachetele criptate ale celuilalt, iar aceasta este arhitectură, nu o coincidență a ordinii.

Ce suprascrie al doilea client

Al doilea client instalează de obicei o rută implicită, își adaugă propriile reguli și își impune propriul resolver. Primul poate supraviețui ca proces fără trafic sau poate păstra o rută care nu mai câștigă. Rutele specifice domeniului sunt victima obișnuită, motiv pentru care unele destinații continuă să funcționeze în timp ce altele eșuează. Simptomul vizibil este o deconectare, iar starea reală este o înlocuire parțială.

O verificare a IP-ului de ieșire nu va dezvălui acest lucru. Raportează o adresă pentru o destinație și nu spune nimic despre ce rute au fost suprascrise sau care resolver răspunde acum. Pentru a vedea daunele, citiți tabelul de rutare și starea resolverului.

Imbricarea este un design, nu o ordine de clicuri

Dacă intenția este imbricarea, documentați calea exterioară a fiecărui punct final, politica sa de eșec și consecințele pentru MTU. Decideți ce se întâmplă când tunelul exterior cade în timp ce cel interior încă mai crede că este conectat. Pornirea clienților într-o ordine norocoasă nu este o configurație, pentru că următoarea actualizare sau reconectare le reordonează. Un aranjament imbricat necesită aceeași grijă ca orice altă topologie.

Când o conexiune este pentru muncă și alta este personală, sprijiniți-vă pe orice izolare sau aranjament gestionat pe care platforma îl acceptă. Scoaterea controalelor corporative nu este o strategie de separare.

Verificați cu aplicația, nu cu pictograma

Exersați aplicațiile care contează cu adevărat, din fiecare context pe care intenționați să îl utilizați, și includeți comportamentul resolverului și reconectările în test. O adresă de ieșire finală nu poate identifica fiecare rută suprascrisă, iar o pictogramă verde nu poate identifica niciuna dintre ele. Notați cine deține conexiunea și ce combinație este de fapt acceptată.

Dacă un produs nu acceptă explicit coexistența cu altul, o schimbare aleatorie de rută sau de permisiune nu va produce o implementare ușor de întreținut. Va produce una care funcționează până la următoarea actualizare.

Notați ce client deține ruta implicită, ce resolver răspunde și ce se întâmplă când fiecare dintre ei se oprește.