Begin van 'n tweede VPN vervang die eerste se toestand
'n Foon laat net een VPN-diens op 'n slag toe; op 'n rekenaar veg verskeie kliënte om dieselfde roetes. Nie een lewer 'n geneste tonnel sonder 'n werklike ontwerp nie.
Twee kliënte, twee ikone wat verbind aandui, en die oortuiging dat verkeer nou deur albei gaan. Vergelyk dié oortuiging met wat elke platform werklik toelaat. 'n Foon het gewoonlik presies een plek vir 'n VPN-diens; 'n rekenaar kan verskeie kliënte laat loop wat om dieselfde roetes en oplosser baklei. Die verskil tussen dié twee situasies verduidelik die meeste berigte oor 'n VPN wat val wanneer 'n ander een begin.
Die ikone beskryf prosesse, nie 'n ketting nie.
Een plek op 'n foon, verskeie eisers op 'n rekenaar
Op Android bied die platform 'n VPN-diensmodel met een aktiewe VPN per gebruikerprofiel, so om 'n tweede een te begin stop die eerste. Dit is die stelsel wat sy eie reël afdwing, nie 'n fout in een van die kliënte nie. Op 'n rekenaar kan verskeie kliënte gelyktydig bly loop, en dan meeding hulle om die roetetabel, beleidsreëls, oplosserkonfigurasie en virtuele interfaces. Albei uitkomste is die platform wat werk soos ontwerp.
Nie een van die uitkomste lewer op sigself 'n geneste tonnel nie. 'n Ketting vereis dat een tonnel die ander se versleutelde pakkette dra, en dit is 'n argitektuur, nie 'n toevalligheid van volgorde nie.
Wat die tweede kliënt oorskryf
Die tweede kliënt installeer tipies 'n standaardroete, voeg sy eie reëls by en stoot sy eie oplosser. Die eerste kan as 'n proses sonder verkeer oorleef, of 'n roete hou wat nie meer wen nie. Domeinspesifieke roetes is die gewone slagoffer, daarom werk sommige bestemmings steeds terwyl ander faal. Die sigbare simptoom is 'n ontkoppeling, en die werklike toestand is 'n gedeeltelike vervanging.
Toetsing van die uitgangs-IP sal dit nie onthul nie. Dit rapporteer een adres vir een bestemming en sê niks oor watter roetes oorskryf is of watter oplosser nou antwoord nie. Om die skade te sien, lees die roetetabel en die oplosser se toestand.
Nesteling is 'n ontwerp, nie 'n klikvolgorde nie
As nesteling die doel is, dokumenteer elke eindpunt se buitenste pad, sy foutbeleid en die gevolge vir die MTU. Besluit wat gebeur wanneer die buitenste tonnel val terwyl die binnerste nog dink dit is verbind. Om kliënte in 'n gelukkige volgorde te begin is nie 'n konfigurasie nie, want die volgende opdatering of herverbinding orden hulle weer. 'n Geneste reëling verg dieselfde sorg as enige ander topologie.
Wanneer een verbinding vir werk is en 'n ander persoonlik, steun op watter isolasie of bestuurde reëling die platform ook al ondersteun. Om die korporatiewe kontroles uit te ruk is nie 'n skeidingsstrategie nie.
Verifieer met die toepassing, nie die ikoon nie
Toets die toepassings wat werklik saak maak, vanuit elke konteks wat jy van plan is om te gebruik, en sluit die oplosser se gedrag en herverbindings in die toets in. 'n Finale uitgangsadres kan nie elke oorskryfde roete identifiseer nie, en 'n groen ikoon kan nie een van hulle identifiseer nie. Teken op wie die verbinding besit en watter kombinasie werklik ondersteun word.
As 'n produk uitdruklik nie naasbestaan met 'n ander ondersteun nie, sal 'n toevallige roete- of toestemmingsverandering nie 'n onderhoubare ontplooiing lewer nie. Dit sal een lewer wat werk tot die volgende opdatering.
Skryf neer watter kliënt die standaardroete besit, watter oplosser antwoord, en wat gebeur wanneer elkeen stop.