Å starte en ny VPN erstatter den førstes tilstand

To klienter, to ikoner som viser tilkobling, og en tro på at trafikken nå går gjennom begge. Sammenlign den troen med hva hver plattform faktisk tillater. En telefon har vanligvis nøyaktig én plass til en VPN-tjeneste; en datamaskin kan kjøre flere klienter som kjemper om de samme rutene og den samme resolveren. Forskjellen mellom disse to situasjonene forklarer de fleste rapportene om en VPN som faller når en annen starter.

Ikonene beskriver prosesser, ikke en kjede.

Én plass på en telefon, flere kandidater på en datamaskin

På Android tilbyr plattformen en VPN-tjenestemodell med én aktiv VPN per brukerprofil, så når man starter en annen, stopper den første. Det er systemet som håndhever sin egen regel, ikke en feil i noen av klientene. På en datamaskin kan flere klienter kjøre samtidig, og da konkurrerer de om rutetabellen, policyregler, resolverkonfigurasjon og virtuelle grensesnitt. Begge utfallene er plattformen som arbeider som designet.

Ingen av utfallene lager en nestet tunnel i seg selv. En kjede krever at én tunnel bærer den andres krypterte pakker, og det er arkitektur, ikke en tilfeldighet i rekkefølgen.

Hva den andre klienten overskriver

Den andre klienten installerer vanligvis en standardrute, legger til sine egne regler og skyver sin egen resolver. Den første kan overleve som en prosess uten trafikk, eller beholde en rute som ikke lenger vinner. Domenespesifikke ruter er det vanlige offeret, og derfor fortsetter noen destinasjoner å virke mens andre feiler. Det synlige symptomet er en frakobling, og den faktiske tilstanden er en delvis erstatning.

En sjekk av utgangs-IP vil ikke avsløre dette. Den rapporterer én adresse for én destinasjon og sier ingenting om hvilke ruter som ble overskrevet eller hvilken resolver som nå svarer. For å se skaden, les rutetabellen og resolverens tilstand.

Nesting er en design, ikke en rekkefølge av klikk

Hvis nesting er hensikten, dokumenter hvert endepunkts ytre vei, dets feilpolicy og MTU-konsekvensene. Bestem hva som skjer når den ytre tunnelen faller mens den indre fortsatt tror den er tilkoblet. Å starte klienter i en heldig rekkefølge er ikke en konfigurasjon, fordi neste oppdatering eller gjenoppkobling omorganiserer dem. Et nestet arrangement krever samme omhu som enhver annen topologi.

Når én tilkobling er for arbeid og en annen er personlig, len deg på den isolasjonen eller administrerte ordningen plattformen støtter. Å rive ut bedriftskontrollene er ikke en separasjonsstrategi.

Verifiser med applikasjonen, ikke ikonet

Test applikasjonene som faktisk betyr noe, fra hver kontekst du har tenkt å bruke, og inkluder resolveratferd og gjenoppkoblinger i testen. En endelig utgangsadresse kan ikke identifisere hver overskrevet rute, og et grønt ikon kan ikke identifisere noen av dem. Noter hvem som eier tilkoblingen og hvilken kombinasjon som faktisk støttes.

Hvis et produkt uttrykkelig ikke støtter sameksistens med et annet, vil en tilfeldig rute- eller tillatelsesendring ikke gi en vedlikeholdbar utrulling. Den vil gi en som virker til neste oppdatering.

Skriv ned hvilken klient som eier standardruten, hvilken resolver som svarer, og hva som skjer når hver av dem stopper.