Korleis senda ein IPv4-destinasjon utanom ein OpenVPN-tunnel

Dei fleste fulltunnel-oppsett sender kvar pakke gjennom VPN-en, og redirect-gateway er direktivet som gjer det mogleg. Éin enkelt destinasjon kan likevel unntakast. Å leggja til ei vertsrute for den adressa med net_gateway-plasshaldaren fortel klienten å nå henne gjennom den opphavlege gatewayen til maskinen, medan alt anna held fram med å bruka tunnelen.

Lina ser harmlaus ut og er ofte det, men ho avgjer berre eitt spørsmål: kvar pakkane til nøyaktig den IPv4-adressa går. Ho endrar ikkje DNS, IPv6, brannmurpolitikken eller kva prosess som opna sambandet, og kvar av desse kan stille gjera unntaket verknadslaus.

Kva net_gateway eigentleg namngjev

Profiloppføringa for det unntaket er éi line: route 198.51.100.77 255.255.255.255 net_gateway. Den første adressa er ein dokumentasjonsplasshaldar for destinasjonen, maska gjer henne til ei enkeltvertsrute, og den siste tokenet namngjev gateway-plasshaldaren. OpenVPN løyser gateway-plasshaldarar når ho installerer ruter. vpn_gateway tyder tunnelens eigen gateway, den fjerne sida av VPN-sambandet. net_gateway tyder standardgatewayen verten hadde før VPN-en endra noko, som vanlegvis er den lokale rutaren på det fysiske nettet.

Ein tredje plasshaldar, remote_host, viser til adressa til VPN-tenaren, og han finst for at tunnelen skal kunna nå tenaren over den fysiske vegen. Å blanda desse tre er den vanlegaste årsaka til at eit unntak hamnar på feil stad eller ikkje vert installert i det heile.

Verdien vert lesen ved tilkopling, ikkje skriven inn i fila. Viss maskinen flyttar til eit anna nett, endrar gatewayen før VPN-en seg, og ruta følgjer den nye. Det er vanlegvis det du vil, men det tyder òg at åtferda til unntaket avheng av nettet klienten starta frå.

Kvifor ei vertsrute vinn over standardruta til tunnelen

Ruting vert avgjort av det mest spesifikke samsvarande prefikset. redirect-gateway def1 erstattar vanlegvis ikkje standardruta; ho legg til to halvdelar, ei rute for den nedre halvdelen av adresseområdet og ei for den øvre, slik at den opphavlege standardruta vert halden for anna bruk. Desse halvdelane er breiare enn éi adresse.

Ei rute for éi adresse med maske 255.255.255.255 er ei /32, som er så spesifikk som IPv4 kan verta. Når ein pakke til den adressa vert vurdert, passar /32 og vinn uansett kva rute som vart installert først. Det er mekanismen bak unntaket, og han verkar likt på Linux, macOS og Windows så lenge ruta faktisk finst.

Windows legg til ein andre dimensjon. Når to ruter er like spesifikke, vinn den med lågast metrikk, og ein VPN-adapter kan bera ein grensesnittmetrikk som endrar resultatet. Ei /32 er framleis meir spesifikk enn halvdelane, så unntaket held vanlegvis, men ei utdatert rute frå ein tidlegare sesjon kan gje eit forvirrande resultat om ho er like spesifikk.

Kva unntaket ikkje dekkjer

DNS er det første gapet. Klienten kan dytte interne resolverinnstillingar, og operativsystemet vil halde fram med å bruka dei til oppslag. Ein applikasjon som løyser eit namn før han koplar til, kan få ei intern adresse for ei teneste som skal gå direkte, eller ei ekstern adresse som vert løyst rett, men som så snublar over det neste gapet.

IPv6 er den andre. Rutedirektivet handterer berre IPv4. Ein destinasjon med dobbel stakk kan føretrekke IPv6, som følgjer tunnelen eller IPv6-standardruta til verten avhengig av policy, slik at IPv4-unntaket aldri trer i kraft. Du treng ei samsvarande IPv6-rute, eller eit medvite vedtak om å slå av IPv6 for den klienten.

Applikasjonsomfanget er det tredje. Regelen er destinasjonsbasert, så kvar prosess som koplar til den adressa, brukar den direkte vegen, anten det er den du hadde i tankane eller ikkje. Omvendt kan ein nettstad svare frå fleire adresser, så eit unntak for éi /32 unntek ikkje nettstaden. Viss det eigentlege kravet er ruting per applikasjon, er rutetabellen til Community-klienten feil verktøy.

Kontroller unntaket utan å lura deg sjølv

Byrja med den installerte ruta, ikkje med ein nettlesar. På Linux, spør kjernen kva rute og neste hopp han vil bruka for den konkrete adressa; på Windows, les rutetabellen for den /32-en. Stadfest at gatewayen er den fysiske og ikkje tunnelen. Viss oppføringa manglar, vart profilen ikkje brukt, eller klienten hadde ikkje rett til å endra ruter.

Test deretter to destinasjonar. Ein førespurnad til den unntatte adressa skal gå ut gjennom det fysiske grensesnittet, og ein førespurnad til ei intern kontrolladresse skal framleis bruka tunnelen. Å testa berre den unntatte adressa provar ingenting om resten av tunnelen, og å testa ein offentleg nettstad testar adressa den nettstaden vart løyst til, som kanskje ikkje er den i regelen.

Til slutt, kontroller styringane som kan overstyre ruta. Ein kill switch på klientsida eller ei Windows-innstilling block-outside-dns kan forby direkte trafikk, noko som viser seg som eit samband som feilar sjølv om ruta er rett. Ikkje deaktiver desse styringane for å få unntaket til å sjå ut som det verkar; viss policyen forbyr den direkte vegen, er unntaket eit designproblem for den som eig VPN-tenesta.

Kontroller på nytt etter gjenoppkopling eller nettverksbyte, fordi gatewayen før VPN-en og den tilgjengelege vegen er eigenskapar ved augneblinken, ikkje ved profilen.