OpenVPN redirect-gateway: hvad hvert flag gør ved ruterne

Forbind med redirect-gateway i profilen, og din maskines standardrute kan forsvinde, dele sig i to eller blive præcis, hvor den var, afhængigt af flag, som ingen læser to gange. Indstillingen ændrer kun routingtilstanden og intet andet, så det eneste pålidelige bevis på, hvad den gjorde, er den tabel, klienten installerede bagefter. Det følgende er tabellen efter en forbindelse, den rute der holder selve tunnelen i live, og den IPv6-trafik, som direktivet aldrig hævder at dække. Hvert trin er en kommando, du kan køre på klienten, mens tunnelen er oppe.

Hvad hvert flag gør ved standardruten

Uden noget flag fjerner indstillingen den almindelige standardrute og sætter tunnelen i dens sted, så den gamle gateway forsvinder fra tabellen, mens forbindelsen er oppe. Tilføj def1, og den standard bliver stående på listen, mens to smallere ruter gør arbejdet i stedet. Tilføj bypass-dhcp, og DHCP-ruten overlever også, hvilket betyder noget på et netværk, hvor klienten stadig skal nå den lokale DHCP-server. Flaglisten på manualsiden for OpenVPN 2.6 er kort nok til at læse én gang, og hver post ændrer, hvilke ruter der ender i tabellen.

En skubbet indstilling opfører sig på samme måde, når den ankommer, så klientprofilen kan være helt tom, mens tabellen ser fuldt omdirigeret ud. Det er normalt: serveren sendte flagene, klienten anvendte dem, og den lokale fil nævnte aldrig direktivet. Når et push ser ud til ikke at gøre noget, så tjek klientfiltret, der accepterer eller dropper hentede indstillinger, for en droppet indstilling giver ingen fejl i nogen af enderne.

def1 vinder på specificitet uden at røre din standardrute

To halve standardruter dækker tilsammen IPv4-rummet, 0.0.0.0/1 og 128.0.0.0/1. Hver af dem er mere specifik end 0.0.0.0/0, så et opslag foretrækker dem, mens den rigtige standard bliver i tabellen for alt, der beder om det mindst specifikke match.

Læs tabellen i stedet for profilen, for kun tabellen viser, hvilket af de tilfælde du er i. To linjer er nok til at skelne dem:

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

Notér grænsefladen og metrikken på hver linje, ikke kun destinationen. En standard, der peger på tunnelen, og et par halve standardruter, der peger samme sted, beskriver den samme hensigt og fejler forskelligt, når tunnelen falder, fordi fallbacken stadig findes i det ene tilfælde. Skriv begge felter i ændringsnoten. En overlevende fallback er nogle gange det, der holder en fjernsession i live længe nok til at reparere tunnelen, og det er også det, der lækker trafik, når hensigten var en fuld tunnel.

Hold tunnelens endepunkt tilgængeligt

Klienten har brug for en rute til tunnelens fjerne ende, som ikke selv løber gennem tunnelen. OpenVPN installerer den værtsrute, før det ændrer noget andet, og en manuel ruteændring eller en anden VPN-klient kan tage den væk. Symptomet bagefter er en forbindelse, der melder forbundet og derefter ikke sender noget.

Spørg kernen, hvilken grænseflade den ville bruge til endepunktsadressen, mens tunnelen er oppe. Svaret skal navngive den fysiske grænseflade og dens gateway, aldrig tun0:

ip route get 198.51.100.20

Hvis det opslag returnerer tunnel-enheden, bærer tunnelen sin egen transport og bryder sammen, så snart en pakke skal ud. Lokale præfikser, en ekstra adapter og policy routing betyder stadig noget her, og derfor kan en omdirigering, der virker på en ren bærbar, fejle på en vært med en administrationsgrænseflade og to standardruter. Profilen får normalt skylden for det, adresseplanen gjorde.

IPv6-trafik bruger fortsat sin egen tabel

Omdirigering af IPv4 lader IPv6 være, og de to familier ændres af forskellige flag. På en dual-stack-vært med en fungerende v6-standard kan v4-trafik sidde helt inde i tunnelen, mens hver v6-kapabel destination forlader over det fysiske link. En vært, der ser rigtig ud i den ene tabel, lækker i den anden.

Tjek v6-tabellen efter forbindelsen i stedet for at antage, at tunnelen dækkede den. Direktivet bærer adressefamilie-flag netop af denne grund, og en profil, der udelader dem, arver det, platformen gør som standard:

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

Bevis, hvilken grænseflade et program bruger

En forbundet tilstand er ikke en blokering, og en ruteændring er ikke en kill switch. Hvis direkte trafik skal stoppe, når tunnelen fejler, lever den politik i firewallen og kræver sin egen test.

Test den vej, et program faktisk tager, i stedet for den vej, profilen beskriver. Spørg først efter ruten, bind derefter en anmodning til hver grænseflade på skift og sammenlign, hvad den fjerne side rapporterer:

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

Hvis begge anmodninger returnerer den samme adresse, bruger programmet ikke tunnelen, selv om routingtabellen siger, det skal. Hvis kun den tunnelbundne anmodning lykkes, er den fysiske vej filtreret for den destination, og tunnelen gør, hvad du bad om. Skriv flagene, de installerede ruter, endepunktsopslaget og begge udgangsresultater i ændringsprotokollen, så den næste person arver fakta i stedet for et skærmbillede.