Kun med i tunnelen eller kun udenfor: hvilken standard?
Vælg standarden, før du bygger listen: tunnelér kun det, du navngiver, eller tunnelér alt og skær undtagelser ud. Test derefter den app, som ingen havde skrevet ind.
Åbn routingafsnittet i din VPN-klient, og du ser to forskelligt formede kontroller, som ofte bærer samme etiket. Den ene beder dig liste de destinationer op, der hører i tunnelen, og alt andet bliver ved med at bruge det lokale netværk. Den anden forudsætter, at alt tunneleres, og spørger, hvad der skal skæres ud igen. Begge giver dig en fungerende tunnel ved første test, og begge vedligeholdes ved at tilføje linjer til en liste, og derfor forbliver forskellen usynlig, indtil nogen installerer noget nyt.
Valget er en standard, ikke en funktion. Fastlæg den, før listen har tyve poster.
Læs standarden på klienten, ikke i brochuren
WireGuard gør beslutningen usædvanlig synlig, fordi AllowedIPs er en inklusionsliste og intet andet. En peer med 0.0.0.0/0, ::/0 tunnelerer alt; en peer med 10.20.0.0/16 tunnelerer kun det. Der findes ingen udelukkelsessyntaks, så vil du have et subnet udeladt, må du enten opliste alle andre præfikser eller tilføje policy routing uden for interfacet.
OpenVPN når samme sted fra den anden retning, med redirect-gateway def1 der installerer en fuld tunnel og eksplicitte route-direktiver der tilføjer eller tilsidesætter bestemte præfikser. Kommercielle klienter skjuler normalt begge bag et afkrydsningsfelt og en destinationstabel, så læs hvilken af de to tabellen faktisk redigerer, før du stoler på etiketten.
Spørgsmålet er ikke, hvad afkrydsningsfeltet hedder. Spørgsmålet er, hvad der sker med en pakke, hvis destination ikke står på nogen af de to lister. Svar på det på skrift, og resten af konfigurationen følger af det. Springer du spørgsmålet over, overlader du den første uforklarede fejl til den person, der den dag sidder tættest på klienten.
Følg en applikation, som ingen havde skrevet ind
I et design med kun inklusion går den applikation direkte, på det lokale netværk, med den lokale DNS. I et design med kun udelukkelse går den gennem tunnelen, så vidt serveren tillader det, og det er ofte forskellen på et nyt SaaS-værktøj, der virker på første dag, og en sag der siger, at VPN'en ødelagde det.
Ingen af standarderne er mere sikker i sig selv. Inklusion indsnævrer, hvad tunnelen bærer, og gør det lokale netværk til vejen med mindst modstand; udelukkelse tager tunnelen som den normale vej og behandler undtagelser som undtagelser, hvilket er tættere på hvad de fleste virksomhedspolitikker egentlig mener.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
Læg mærke til, hvilken slags objekt platformen lister
Androids VpnService.Builder stiller en liste over tilladte og en liste over forbudte applikationer til rådighed som to separate modeller, og app-regler vælger efter pakke i stedet for efter destination. En browser på en sådan liste tager hver destination med, som den åbner, hvilket er en anden granularitet end en routingtabel og ikke kan reparere et enkelt ødelagt websted inde i en fungerende app.
Desktopklienter blander normalt begge slags i én grænseflade, så undersøg, om den række, du tilføjer, er en pakke, et værtsnavn eller et præfiks. De fejler på forskellige måder, og de løses forskellige steder. En værtsnavnrække bliver normalt en rute plus et navn, mens en pakkerække bliver en politikbeslutning inde i klienten. Skriv ned, hvilken af de to du tilføjede, for den person, der fejlretter senere, vil antage den anden.
Test fejltilstanden, ikke kun det glade forløb
En applikation, der er udelukket fra tunnelen, får ikke automatisk ren direkte adgang. Hvis klienten samtidig håndhæver en regel om at blokere uden VPN, kan den udelukkede trafik blive kasseret helt, hvilket ligner en ødelagt app snarere end en routingbeslutning. Test det tilfælde bevidst i stedet for at opdage det gennem en brugerrapport.
Kontrollér derefter DNS og IPv6 som separate punkter. En tunnel, der kun bærer IPv4, efterlader en v6-kapabel applikation en vej uden om, og split-DNS afgør, om interne navne opløses for trafik, der slet ikke tunneleres. Kør en app fra listen, en app der ikke står på listen, et navneopslag og én genopkobling, og gem resultaterne sammen med konfigurationen.
Skriv standarden ned, hvor den næste person finder den
Notér den valgte standard, undtagelserne og hvem der ejer dem samme sted som klientprofilen, for den næste administrator tilføjer en post uden at læse denne begrundelse. Notér dato og årsag for hver undtagelse, så en forældet undtagelse for et websted, der siden er rettet, kan fjernes med tillid. En liste uden begrundelser vokser for evigt.
Når nogen rapporterer én ødelagt destination, så ændr undtagelsen i stedet for grundlinjen. At vende standarden for at rette et enkelt websted flytter stille hver applikation, der ikke står på listen, til den anden side af tunnelen.