Hoe om een enkele IPv4-bestemming buite 'n OpenVPN-tonnel te stuur

Die meeste volledige tonnelopstellings stuur elke pakkie deur die VPN, en redirect-gateway is die opdrag wat dit bewerkstellig. 'n Enkele bestemming kan steeds vrygestel word. Deur 'n gasheerroete vir daardie adres met die net_gateway-plekhouer by te voeg, sê dit vir die kliënt om dit deur die masjien se oorspronklike gateway te bereik, terwyl alles anders die tonnel bly gebruik.

Die reël lyk onskadelik en is dikwels so, maar dit beslis net een vraag: waarheen pakkies vir daardie presiese IPv4-adres gaan. Dit verander nie DNS, IPv6, brandmuurbeleid of watter proses die verbinding oopgemaak het nie, en elkeen daarvan kan die uitsondering stilweg verydel.

Wat net_gateway eintlik benoem

Die profielinskrywing vir daardie uitsondering is een reël: route 198.51.100.77 255.255.255.255 net_gateway. Die eerste adres is 'n dokumentasie-plekhouer vir die bestemming, die masker maak dit 'n enkelgasheerroete, en die laaste teken benoem die gateway-plekhouer. OpenVPN los gateway-plekhouers op wanneer dit roetes installeer. vpn_gateway beteken die tonnel se eie gateway, die verre kant van die VPN-skakel. net_gateway beteken die verstekgateway wat die gasheer gehad het voordat die VPN enigiets verander het, wat gewoonlik die plaaslike router op die fisiese netwerk is.

'n Derde plekhouer, remote_host, verwys na die VPN-bediener se adres, en dit bestaan sodat die tonnel die bediener oor die fisiese pad kan bereik. Om hierdie drie te verwar is die mees algemene rede waarom 'n uitsondering na die verkeerde plek gaan, of glad nie installeer nie.

Die waarde word by verbindingstyd gelees, nie in die lêer geskryf nie. As die masjien na 'n ander netwerk beweeg, verander die pre-VPN-gateway en die roete volg die nuwe een. Dit is gewoonlik wat jy wil hê, maar dit beteken ook dat die uitsondering se gedrag afhang van die netwerk waarvan die kliënt begin het.

Waarom 'n gasheerroete die tonnelverstek wen

Roetering word deur die mees spesifieke ooreenstemmende voorvoegsel beslis. redirect-gateway def1 vervang nie normaalweg die verstekroete nie; dit voeg twee helftes by, 'n roete vir die onderste helfte van die adresruimte en een vir die boonste helfte, sodat die oorspronklike verstekroete vir ander gebruik bewaar bly. Daardie helftes is breër as 'n enkele adres.

'n Roete vir een adres met 'n 255.255.255.255-masker is 'n /32, wat so spesifiek is as wat IPv4 kan raak. Wanneer 'n pakkie vir daardie adres geëvalueer word, pas die /32 en wen ongeag watter roete eerste geïnstalleer is. Dit is die meganisme agter die uitsondering, en dit werk dieselfde op Linux, macOS en Windows solank die roete werklik teenwoordig is.

Windows voeg 'n tweede dimensie by. Wanneer twee roetes ewe spesifiek is, wen die een met die laer metriek, en 'n VPN-adapter kan 'n koppelvlakmetriek dra wat die uitkoms verander. 'n /32 is steeds meer spesifiek as die helftes, so die uitsondering hou gewoonlik, maar 'n verouderde roete van 'n vroeër sessie kan 'n verwarrende resultaat lewer as dit ewe spesifiek is.

Wat die uitsondering nie dek nie

DNS is die eerste gaping. Die kliënt kan interne oplosserinstellings stoot, en die bedryfstelsel sal dit vir opsoek bly gebruik. 'n Toepassing wat 'n naam oplos voordat dit verbind, kan 'n interne adres ontvang vir 'n diens wat veronderstel is om direk te gaan, of 'n eksterne adres wat korrek oplos maar dan oor die volgende gaping struikel.

IPv6 is die tweede. Die roete-opdrag hanteer net IPv4. 'n Dubbelstapelbestemming kan IPv6 verkies, wat die tonnel of die gasheer se IPv6-verstekroete volg na gelang van beleid, so die IPv4-uitsondering kom nooit in werking nie. Jy het 'n bypassende IPv6-roete nodig, of 'n doelbewuste besluit om IPv6 vir daardie kliënt te deaktiveer.

Toepassingsomvang is die derde. Die reël is bestemmingsgebaseer, so elke proses wat aan daardie adres verbind, gebruik die direkte pad, of dit die een is wat jy in gedagte gehad het of nie. Omgekeerd kan 'n webwerf van verskeie adresse antwoord, so om een /32 uit te sluit sluit nie die werf uit nie. As die werklike vereiste per-toepassing-roetering is, is die Community-kliënt se roetetabel die verkeerde instrument.

Om die uitsondering te kontrolleer sonder om jouself te fop

Begin met die geïnstalleerde roete, nie met 'n blaaier nie. Op Linux, vra die kern watter roete en volgende hop dit vir die spesifieke adres sal gebruik; op Windows, lees die roetetabel vir daardie /32. Bevestig die gateway is die fisiese een en nie die tonnel nie. As die inskrywing ontbreek, is die profiel nie toegepas nie of die kliënt het nie die voorreg gehad om roetes te verander nie.

Toets dan twee bestemmings. 'n Versoek aan die uitgeslote adres moet deur die fisiese koppelvlak verlaat, en 'n versoek aan 'n kontrole-interne adres moet steeds die tonnel gebruik. Om net die uitgeslote adres te toets bewys niks oor die res van die tonnel nie, en om 'n openbare webwerf te toets toets watter adres daardie werf ook al opgelos het, wat dalk nie die een in die reël is nie.

Kontroleer laastens die beheermaatreëls wat die roete kan oorheers. 'n Kliëntkant-doodskakelaar of 'n Windows block-outside-dns-instelling kan direkte verkeer verbied, wat wys as 'n verbinding wat misluk al is die roete korrek. Moenie daardie beheermaatreëls deaktiveer om die uitsondering te laat werk nie; as die beleid die direkte pad verbied, is die uitsondering 'n ontwerpprobleem vir wie ook al die VPN-diens besit.

Kontroleer weer ná herverbinding of netwerkwisseling, want die pre-VPN-gateway en die beskikbare pad is eienskappe van die oomblik, nie van die profiel nie.