OpenVPN redirect-gateway: hva hvert flag gjør med rutene

Koble til med redirect-gateway i profilen, og standardruten på maskinen kan forsvinne, dele seg i to eller bli nøyaktig der den var, avhengig av flagg som ingen leser to ganger. Valget endrer bare rutertilstanden og ingenting annet, så det eneste pålitelige beviset på hva det gjorde, er tabellen klienten installerte etterpå. Det som følger, er tabellen etter en tilkobling, ruten som holder selve tunnelen i live, og IPv6-trafikken som direktivet aldri hevder å dekke. Hvert steg er en kommando du kan kjøre på klienten mens tunnelen er oppe.

Hva hvert flagg gjør med standardruten

Uten noe flagg fjerner valget den vanlige standardruten og setter tunnelen i dens sted, så den gamle gatewayen forsvinner fra tabellen mens tilkoblingen er oppe. Legg til def1, og den standarden blir stående på listen, mens to smalere ruter gjør jobben i stedet. Legg til bypass-dhcp, og DHCP-ruten overlever også, noe som betyr noe på et nettverk der klienten fortsatt må nå den lokale DHCP-serveren. Flaglisten på manualsiden for OpenVPN 2.6 er kort nok til å leses én gang, og hver oppføring endrer hvilke ruter som ender i tabellen.

Et skubbet valg oppfører seg på samme måte når det ankommer, så klientprofilen kan være helt tom mens tabellen ser fullstendig omdirigert ut. Det er normalt: serveren sendte flaggene, klienten brukte dem, og den lokale filen nevnte aldri direktivet. Når et push ser ut til å ikke gjøre noe, sjekk klientfilteret som godtar eller dropper hentede valg, for et droppet valg gir ingen feil i noen av endene.

def1 vinner på spesifisitet uten å røre standardruten din

To halve standardruter dekker til sammen IPv4-rommet, 0.0.0.0/1 og 128.0.0.0/1. Hver av dem er mer spesifikk enn 0.0.0.0/0, så et oppslag foretrekker dem mens den ekte standarden blir i tabellen for alt som ber om det minst spesifikke treffet.

Les tabellen i stedet for profilen, for bare tabellen viser hvilket av disse tilfellene du er i. To linjer er nok til å skille dem:

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å hver linje, ikke bare destinasjonen. En standard som peker på tunnelen, og et par halve standardruter som peker på tunnelen, beskriver samme hensikt og feiler ulikt når tunnelen faller, fordi reserveveien fortsatt finnes i det ene tilfellet. Skriv begge feltene i endringsnotatet. En overlevende reservevei er noen ganger det som holder en fjernsøkt i live lenge nok til å reparere tunnelen, og det er også det som lekker trafikk når hensikten var en full tunnel.

Hold tunnelens endepunkt tilgjengelig

Klienten trenger en rute til den fjerne enden av tunnelen som ikke selv går gjennom tunnelen. OpenVPN installerer den vertsruten før det endrer noe annet, og en manuell ruteendring eller en annen VPN-klient kan ta den bort. Symptomet etterpå er en tilkobling som melder at den er tilkoblet og deretter ikke slipper noe gjennom.

Spør kjernen hvilket grensesnitt den ville brukt for endepunktsadressen mens tunnelen er oppe. Svaret må navngi det fysiske grensesnittet og gatewayen, aldri tun0:

ip route get 198.51.100.20

Hvis det oppslaget returnerer tunellenheten, bærer tunnelen sin egen transport og vil kollapse så snart en pakke må ut. Lokale prefikser, en ekstra adapter og policy-ruting betyr fortsatt noe her, og derfor kan en omdirigering som virker på en ren bærbar maskin feile på en vert med et administrasjonsgrensesnitt og to standardruter. Profilen får vanligvis skylden for det adresseplanen gjorde.

IPv6-trafikk bruker fortsatt sin egen tabell

Omdirigering av IPv4 lar IPv6 være i fred, og de to familiene endres av ulike flagg. På en dual-stack-vert med en fungerende v6-standard kan v4-trafikk sitte helt inne i tunnelen mens hver v6-kapabel destinasjon forlater over den fysiske lenken. En vert som ser riktig ut i den ene tabellen, lekker i den andre.

Sjekk v6-tabellen etter tilkoblingen i stedet for å anta at tunnelen dekket den. Direktivet bærer adressefamilie-flagg nettopp av denne grunn, og en profil som utelater dem, arver det plattformen gjør som standard:

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

Bevis hvilket grensesnitt et program bruker

En tilkoblet tilstand er ikke en blokkering, og en ruteendring er ikke en kill switch. Hvis direkte trafikk må stoppe når tunnelen feiler, lever den politikken i brannmuren og trenger sin egen test.

Test veien et program faktisk tar, i stedet for veien profilen beskriver. Spør først etter ruten, bind deretter en forespørsel til hvert grensesnitt etter tur og sammenlign hva den fjerne siden rapporterer:

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

Hvis begge forespørslene returnerer samme adresse, bruker programmet ikke tunnelen selv om rutetabellen sier det burde. Hvis bare den tunnelbundne forespørselen lykkes, er den fysiske veien filtrert for den destinasjonen, og tunnelen gjør det du ba om. Skriv flaggene, de installerte rutene, endepunktsøket og begge utgangsresultatene i endringsprotokollen, slik at neste person arver fakta i stedet for et skjermbilde.