OpenVPN redirect-gateway: kva kvar flagge gjer med rutene

Kopla til med redirect-gateway i profilen, og standardruta på maskinen kan forsvinne, dela seg i to eller bli nøyaktig der ho var, avhengig av flagg som ingen les to gonger. Valet endrar berre rutertilstanden og ingenting anna, så det einaste pålitelege beviset på kva det gjorde, er tabellen klienten installerte etterpå. Det som følgjer, er tabellen etter ei tilkopling, ruta som held sjølve tunnelen i live, og IPv6-trafikken som direktivet aldri hevdar å dekkje. Kvart steg er ein kommando du kan køyre på klienten medan tunnelen er oppe.

Kva kvar flagge gjer med standardruta

Utan noko flagg fjernar valet den vanlege standardruta og set tunnelen i hennar stad, så den gamle gatewayen forsvinn frå tabellen medan tilkoplinga er oppe. Legg til def1, og den standarden blir ståande på lista, medan to smalare ruter gjer jobben i staden. Legg til bypass-dhcp, og DHCP-ruta overlever òg, noko som tel på eit nettverk der klienten framleis må nå den lokale DHCP-tenaren. Flaglista på manualsida for OpenVPN 2.6 er kort nok til å lesast éin gong, og kvar oppføring endrar kva ruter som endar i tabellen.

Eit skyvd val oppfører seg på same måte når det kjem, så klientprofilen kan vere heilt tom medan tabellen ser fullstendig omdirigert ut. Det er normalt: tenaren sende flagga, klienten brukte dei, og den lokale fila nemnde aldri direktivet. Når eit push ser ut til å ikkje gjere noko, sjekk klientfilteret som godtek eller droppar henta val, for eit droppa val gir inga feil i nokon av endane.

def1 vinn på spesifisitet utan å røre standardruta di

To halve standardruter dekkjer til saman IPv4-rommet, 0.0.0.0/1 og 128.0.0.0/1. Kvar av dei er meir spesifikk enn 0.0.0.0/0, så eit oppslag føretrekkjer dei medan den ekte standarden blir i tabellen for alt som ber om det minst spesifikke treffet.

Les tabellen i staden for profilen, for berre tabellen viser kva av desse tilfella du er i. To linjer er nok til å skilje dei:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Legg merke til grensesnittet og metrikken på kvar linje, ikkje berre destinasjonen. Ein standard som peikar på tunnelen, og eit par halve standardruter som peikar på tunnelen, skildrar same føremål og feilar ulikt når tunnelen fell, fordi reservevegen framleis finst i det eine tilfellet. Skriv begge felta i endringsnotatet. Ein overlevande reserveveg er stundom det som held ein fjernsøkt i live lenge nok til å reparere tunnelen, og det er òg det som lek trafikk når føremålet var ein full tunnel.

Hald endepunktet til tunnelen tilgjengeleg

Klienten treng ei rute til den fjerne enden av tunnelen som ikkje sjølv går gjennom tunnelen. OpenVPN installerer den vertsruta før det endrar noko anna, og ei manuell ruteendring eller ein annan VPN-klient kan ta ho bort. Symptomet etterpå er ei tilkopling som melder at ho er tilkopla og deretter ikkje slepp noko gjennom.

Spør kjernen kva grensesnitt han ville brukt for endepunktsadressa medan tunnelen er oppe. Svaret må namngje det fysiske grensesnittet og gatewayen, aldri tun0:

ip route get 198.51.100.20

Viss det oppslaget returnerer tunneleininga, ber tunnelen sin eigen transport og vil kollapse så snart ein pakke må ut. Lokale prefiks, ein ekstra adapter og policy-ruting tel framleis her, og difor kan ei omdirigering som verkar på ein rein berbar maskin feile på ein vert med eit administrasjonsgrensesnitt og to standardruter. Profilen får vanlegvis skulda for det adresseplanen gjorde.

IPv6-trafikk held fram med å bruke sin eigen tabell

Omdirigering av IPv4 lèt IPv6 vere i fred, og dei to familiane blir endra av ulike flagg. På ein dual-stack-vert med ein fungerande v6-standard kan v4-trafikk sitje heilt inne i tunnelen medan kvar v6-kapabel destinasjon forlèt over den fysiske lenkja. Ein vert som ser rett ut i den eine tabellen, lek i den andre.

Sjekk v6-tabellen etter tilkoplinga i staden for å anta at tunnelen dekte han. Direktivet ber adressefamilie-flagg nettopp av denne grunnen, og ein profil som utelèt dei, arvar det plattformen gjer som standard:

ip -6 route show default
ip -6 route get 2001:db8::10

Prov kva grensesnitt eit program brukar

Ein tilkopla tilstand er ikkje ei blokkering, og ei ruteendring er ikkje ein kill switch. Viss direkte trafikk må stoppe når tunnelen feilar, lever den politikken i brannmuren og treng sin eigen test.

Test vegen eit program faktisk tek, i staden for vegen profilen skildrar. Spør først etter ruta, bind deretter ein førespurnad til kvart grensesnitt etter tur og samanlikn kva den fjerne sida rapporterer:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Viss begge førespurnadene returnerer same adresse, brukar programmet ikkje tunnelen sjølv om rutetabellen seier det burde. Viss berre den tunnelbundne førespurnaden lukkast, er den fysiske vegen filtrert for den destinasjonen, og tunnelen gjer det du bad om. Skriv flagga, dei installerte rutene, endepunktsøket og begge utgangsresultata i endringsprotokollen, slik at neste person arvar fakta i staden for eit skjermbilete.