Kun inkludere eller kun ekskludere: hvilken standard?
Velg standarden før du bygger listen: tunnelér bare det du navngir, eller tunnelér alt og skjær ut unntak. Test deretter appen som ingen hadde lagt inn.
Åpne rutingsdelen i VPN-klienten din, og du ser to ulikt utformede kontroller som ofte bærer samme etikett. Den ene ber deg liste opp destinasjonene som hører hjemme i tunnelen, og alt annet fortsetter å bruke det lokale nettet. Den andre forutsetter at alt tunneleres og spør hva som skal skjæres ut igjen. Begge gir deg en fungerende tunnel ved første test, og begge vedlikeholdes ved å legge til linjer i en liste, og derfor forblir forskjellen usynlig til noen installerer noe nytt.
Valget er en standard, ikke en funksjon. Fastsett den før listen har tjue oppføringer.
Les standarden av klienten, ikke av brosjyren
WireGuard gjør beslutningen uvanlig synlig, fordi AllowedIPs er en inklusjonsliste og ingenting annet. En peer med 0.0.0.0/0, ::/0 tunnelerer alt; en peer med 10.20.0.0/16 tunnelerer bare det. Det finnes ingen eksklusjonssyntaks, så vil du holde et subnett utenfor, må du enten ramse opp alle andre prefikser eller legge til policy-ruting utenfor grensesnittet.
OpenVPN når samme sted fra den andre retningen, med redirect-gateway def1 som installerer en full tunnel og eksplisitte route-direktiver som legger til eller overstyrer bestemte prefikser. Kommersielle klienter skjuler vanligvis begge bak en avkrysningsboks og en destinasjonstabell, så les hvilken av de to tabellen faktisk redigerer før du stoler på etiketten.
Spørsmålet er ikke hva avkrysningsboksen heter. Spørsmålet er hva som skjer med en pakke hvis destinasjon ikke står i noen av de to listene. Svar på det skriftlig, og resten av konfigurasjonen følger av det. Hopper du over spørsmålet, overlater du den første uforklarte feilen til den som tilfeldigvis sitter nærmest klienten den dagen.
Følg en applikasjon som ingen hadde lagt inn
I et design med bare inklusjon går den applikasjonen direkte, på det lokale nettet, med den lokale DNS-en. I et design med bare eksklusjon går den gjennom tunnelen, så langt serveren tillater det, og det er ofte forskjellen mellom et nytt SaaS-verktøy som virker første dag og en sak som sier at VPN-en ødela det.
Ingen av standardene er sikrere i seg selv. Inklusjon begrenser hva tunnelen bærer og gjør det lokale nettet til veien med minst motstand; eksklusjon tar tunnelen som den normale veien og behandler unntak som unntak, noe som ligger nærmere hva de fleste bedriftspolicyer 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 |
Legg merke til hva slags objekt plattformen lister
Androids VpnService.Builder stiller en liste over tillatte og en liste over forbudte applikasjoner til rådighet som to separate modeller, og app-regler velger etter pakke i stedet for etter destinasjon. En nettleser på en slik liste bærer med seg hver destinasjon den åpner, noe som er en annen granularitet enn en rutetabell og ikke kan reparere ett enkelt ødelagt nettsted inne i en fungerende app.
Skrivebordsklienter blander vanligvis begge slag i ett grensesnitt, så sjekk om raden du legger til er en pakke, et vertsnavn eller et prefiks. De feiler på ulike måter og de løses på ulike steder. En vertsnavnrad blir vanligvis en rute pluss et navn, mens en pakkerad blir en policybeslutning inne i klienten. Skriv ned hvilken av de to du la til, for den som feilsøker senere vil anta den andre.
Test feiltilstanden, ikke bare den glade veien
En applikasjon som er utelukket fra tunnelen får ikke automatisk ren direkte tilgang. Hvis klienten i tillegg håndhever en regel som blokkerer uten VPN, kan den utelukkede trafikken bli forkastet helt, noe som ser ut som en ødelagt app snarere enn en rutingsbeslutning. Test det tilfellet med vilje i stedet for å oppdage det gjennom en brukerrapport.
Kontroller deretter DNS og IPv6 som separate punkter. En tunnel som bare bærer IPv4, lar en v6-kapabel applikasjon få en vei utenom, og delt DNS avgjør om interne navn løses opp for trafikk som ikke tunneleres i det hele tatt. Kjør en app fra listen, en app som ikke står på listen, et navneoppslag og én gjenoppkobling, og ta vare på resultatene sammen med konfigurasjonen.
Skriv standarden ned der neste person finner den
Notér den valgte standarden, unntakene og hvem som eier dem på samme sted som klientprofilen, for den neste administratoren legger til en oppføring uten å lese denne begrunnelsen. Notér dato og årsak for hvert unntak, slik at et utdatert unntak for et nettsted som siden er rettet kan fjernes med trygghet. En liste uten årsaker vokser for alltid.
Når noen rapporterer én ødelagt destinasjon, endre unntaket i stedet for grunnlinjen. Å snu standarden for å rette ett enkelt nettsted flytter stille hver applikasjon som ikke står på listen til den andre siden av tunnelen.