Een masjien, twee take, een firewall: ’n Wi-Fi-opskakel, ’n klein Ethernet-subnet daaronder, en ’n lessenaar-VPN-kliënt wat aanvaar dat alles wat die masjien verlaat plaaslik is. Plaaslik begin programme verlaat die masjien via die plaaslike uitsetpad. Toestelle agter die werkstasie kom by die Ethernet-poort in en het ’n deurvoerbesluit nodig. ’n Uitsluiting wat vir die eerste pad geskryf is, sien nooit die tweede nie, en dit is hoekom ’n blaaier die tonnel omseil terwyl die toestelle dit nie doen nie.

Twee pakketpade, een beleid

OriginPathDecision owner
Application on the workstationOUTPUT then egressThe VPN app's routing policy
Device behind the workstationPREROUTING then FORWARDThe workstation's own forwarding policy

Die eerste ry is wat die meeste split-tunneling-gidse beskryf. Die tweede is ’n router-konfigurasie wat toevallig op dieselfde masjien woon. Om hulle in een verstandelike model te smelt, is die fout; hulle deel ’n kern maar nie ’n beleid nie. Teken albei pade voordat jy enige reël wysig, en die res van die ontwerp volg uit watter pad ontbreek.

Die tabel verduidelik ook hoekom een masjien een toets kan slaag en ’n ander kan faal. ’n Blaaier op die werkstasie bewys die plaaslike pad; ’n skootrekenaar wat in die Ethernet-poort ingeprop is, bewys die deurvoerpad. Valideer ’n verandering met elkeen, anders bly die tweede een ongetoets maak nie saak hoe dikwels die blaaier herlaai word nie.

Wat ’n program-uitsluiting werklik klassifiseer

’n Uitsluiting per program werk gewoonlik deur pakette van ’n proses of ’n gebruiker te merk, en dan gemerkte verkeer buite die tonnel te stuur. Dit is ’n plaaslike-uitset-konstruk. ’n Pakket van ’n stroomaf toestel het geen plaaslike proses nie, so dit pas nooit by die keurder nie, ongeag wat die keurder is.

Ongeag wat die keurder is, die twee lyste is nie dieselfde lys nie, en dit is die hele punt. Die Mullvad Linux-gids beskryf merke wat deur sy firewall en roetebeleid verbruik word, en sy voorbeelde teiken plaaslike uitset; hulle is nie ’n ondersteunde beskrywing van ’n stroomaf router nie. Om hulle te kopieer lewer ’n masjien wat glo dit het ’n uitsluiting terwyl dit alles in die tonnel instuur.

Skryf die deurvoerkontrak

Noem die stroomaf bronvoorvoegsel en die inkomende koppelvlak saam, en beperk dan daardie voorvoegsel by die inkom. Sonder die beperking kan enige toestel wat die poort kan bereik ’n uitgeslote adres opeis en deur die omleiding vertrek. Hanteer dit as twee vrae: mag hierdie hosts hierdie opskakel hoegenaamd gebruik, en mag hulle die werkstasie of die tonnel se private reekse bereik? Dit is bykomende toestemmings, nie neweprodukte van die opskakelkeuse nie.

Laat deurvoer toe, en filter dit dan. Die Linux-poort het deurvoer geaktiveer nodig, reëls wat die beoogde verkeer in albei rigtings toelaat, en óf ’n opstroom-terugroete óf doelbewus beperkte bronvertaling. NAT alleen kies nie die opskakel nie en verleen nie deurgang deur ’n filter nie; dit herskryf net ’n adres ná daardie besluite.

Klassifikasie vir deurvoer moet voor die deurvoerroetebesluit plaasvind, wat die prerouting-stadium beteken eerder as uitset. ’n Reël wat ná die besluit geplaas word, kan die pakket steeds verander, maar dit kan nie verander waarheen die pakket reeds gestuur is nie.

Merkwaardes behoort aan die program wat hulle besit

Merkwaardes, tabelnommers en kettingprioriteite is deel van die VPN-program se beleid, nie tydlose konstantes nie. ’n Duursame netwerk wat daarop staatmaak om ’n reël in ’n tabel in te voeg wat ’n ander program hergenereer, sal by die volgende opdatering breek, gewoonlik tydens ’n herverbinding eerder as op ’n gerieflike tyd.

Om ’n tweede basisketting met ’n aanvaarding-uitspraak by te voeg, oorheers nie noodwendig ’n latere ketting se verwerping nie. Basiskettings het hake en prioriteite, en die eerste uitspraak in die ordening wen; ’n aanvaarding in een ketting kanselleer nie ’n verwerping wat ’n ander ketting eerste bereik nie. Kyk na die volledige reëlstel en die roetebeleidorde, nie na die een teller wat verhoog het nie. ’n Teller bewys dat ’n reël geloop het, nooit dat sy uitspraak die een was wat toegepas is nie.

Integreer, of skuif die subnet

Die twee ontwerpe verskil in wie die omleiding besit. ’n Geïntegreerde ontwerp hou een masjien en een beleid, ten koste daarvan dat dit van die VPN-program se tabelsiklus afhang en van ’n stel merke wat sy dokumentasie mag verander. ’n Toegewyde router vir die stroomaf netwerk verwyder daardie afhanklikheid heeltemal: die subnet het sy eie opskakel, en die werkstasie bly ’n kliënt sonder ’n deurvoerrol.

Kies die tweede wanneer die stroomaf netwerk deur VPN-opdaterings moet bly werk, of wanneer niemand die geïntegreerde beleid ná elke vrystelling kan toets nie. Kies die eerste net wanneer die integrasie gedokumenteer is en iemand dit besit.

Verifieer die grens in vier toestande: gekoppel, heraankoppelend, doelbewus geblokkeer en gestop. Kontroleer naamresolusie en albei adresfamilies onder elkeen, want ’n omleiding wat DNS lek is nie die uitsluiting wat jy ontwerp het nie. Die toets moet die presiese grens bewys, nie net dat een bladsy gelaai het nie.

Verwante artikels