Nedstrøms undernet kontra desktop-VPN: udeluk transit, ikke apps
En omgåelse pr. applikation klassificerer kun lokale udgange. Enheder bag arbejdsstationen har brug for deres egen politik for indgående trafik, videresendelse og returvej.
Én maskine, to opgaver, én firewall: et Wi-Fi-uplink, et lille Ethernet-undernet bag det og en desktop-VPN-klient, der antager, at alt, hvad der forlader maskinen, er lokalt. Lokalt startede programmer forlader via den lokale udgangsvej. Enheder bag arbejdsstationen ankommer på Ethernet-porten og har brug for en videresendelsesbeslutning. En undtagelse skrevet til den første vej ser aldrig den anden, og derfor omgår en browser tunnelen, mens enhederne ikke gør.
To pakkeveje, én politik
| Origin | Path | Decision owner |
|---|---|---|
| Application on the workstation | OUTPUT then egress | The VPN app's routing policy |
| Device behind the workstation | PREROUTING then FORWARD | The workstation's own forwarding policy |
Den første række er det, de fleste split-tunneling-guides beskriver. Den anden er en routerkonfiguration, der tilfældigvis ligger på samme maskine. At smelte dem sammen til én mental model er fejlen; de deler en kerne, men ikke en politik. Tegn begge veje, før du redigerer nogen regel, og resten af designet følger af, hvilken vej der mangler.
Tabellen forklarer også, hvorfor én maskine kan bestå én test og fejle en anden. En browser på arbejdsstationen beviser den lokale vej; en bærbar computer tilsluttet Ethernet-porten beviser videresendelsesvejen. Validér en ændring med hver af dem, ellers forbliver den anden utestet, uanset hvor mange gange browseren opdateres.
Hvad en applikationsundtagelse egentlig klassificerer
En undtagelse pr. applikation fungerer normalt ved at markere pakker fra en proces eller en bruger og derefter rute markeret trafik uden om tunnelen. Det er en lokal udgangskonstruktion. En pakke fra en nedstrøms enhed har ingen lokal proces, så den matcher aldrig selektoren, uanset hvad selektoren er.
Uanset hvad selektoren er, er de to lister ikke den samme liste, og det er hele pointen. Mullvads Linux-guide beskriver mærker, som dens firewall og rutepolitik forbruger, og dens eksempler rammer lokal udgang; de er ikke en understøttet beskrivelse af en nedstrøms router. Kopiering af dem giver en maskine, der tror, den har en undtagelse, mens den videresender alt ind i tunnelen.
Skriv transitkontrakten
Navngiv nedstrøms kilde-præfiks og indgangsgrænsefladen sammen, og begræns derefter dette præfiks ved indgangen. Uden begrænsningen kan enhver enhed, der kan nå porten, gøre krav på en undtaget adresse og forlade via omgåelsen. Behandl det som to spørgsmål: må disse værter overhovedet bruge dette uplink, og må de nå arbejdsstationen eller tunnelens private områder? Det er ekstra tilladelser, ikke bivirkninger af uplink-valget.
Tillad videresendelse, og filtrér den derefter. Linux-gatewayen har brug for aktiveret videresendelse, regler der tillader den tilsigtede trafik i begge retninger og enten en opstrøms returrute eller bevidst afgrænset kildeoversættelse. NAT alene vælger ikke uplinket og giver ikke passage gennem et filter; det omskriver kun en adresse efter disse beslutninger.
Klassificering til transit skal ske før beslutningen om videresendelsesruten, hvilket betyder prerouting-stadiet frem for output. En regel placeret efter beslutningen kan stadig ændre pakken, men den kan ikke ændre, hvor pakken allerede er sendt hen.
Mærker tilhører det program, der ejer dem
Mærkeværdier, tabelnumre og kædeprioriteter er en del af VPN-programmets politik, ikke tidløse konstanter. Et holdbart netværk, der afhænger af at indsætte en regel i en tabel, som et andet program genskaber, brækker ved næste opdatering, normalt under en genopkobling og ikke på et belejligt tidspunkt.
At tilføje en anden basiskæde med en accept-afgørelse tilsidesætter ikke nødvendigvis en senere kædes drop. Basiskæder har kroge og prioriteter, og den første afgørelse i rækkefølgen vinder; en accept i én kæde annullerer ikke et drop, som en anden kæde når først. Se på det komplette regelsæt og rutepolitikkens rækkefølge, ikke på den ene tæller, der blev forøget. En tæller beviser, at en regel kørte, aldrig at dens afgørelse var den anvendte.
Integrér, eller flyt undernettet
De to designs adskiller sig i, hvem der ejer omgåelsen. Et integreret design holder én maskine og én politik på bekostning af afhængighed af VPN-programmets tabellivscyklus og af et sæt mærker, som dets dokumentation kan ændre. En dedikeret router til nedstrømsnetværket fjerner den afhængighed helt: undernettet har sit eget uplink, og arbejdsstationen forbliver en klient uden videresendelsesrolle.
Vælg den anden, når nedstrømsnetværket skal blive ved med at virke gennem VPN-opdateringer, eller når ingen kan teste den integrerede politik efter hver udgivelse. Vælg den første kun, når integrationen er dokumenteret, og nogen ejer den.
Verificér grænsen i fire tilstande: forbundet, genopkobling, bevidst blokeret og stoppet. Kontrollér navneopløsning og begge adressefamilier under hver af dem, fordi en omgåelse, der lækker DNS, ikke er den undtagelse, du designede. Testen skal bevise den præcise grænse, ikke bare at én side blev indlæst.