route-gateway is niet redirect-gateway: wat er werkelijk verandert

Je tunnel komt op, het privé-subnet antwoordt, en gewoon browsen verdwijnt nog steeds in de VPN, ook al heeft iemand de gateway-regel uit het profiel verwijderd. Die combinatie is de vingerafdruk van de verkeerde richtlijn die is bewerkt. Wat werd verwijderd, gaf de client een volgende hop voor routes die hij installeert; wat bleef vasthouden, kwam van elders en werd door de server gepusht. Dekking en volgende hop zijn aparte taken, en slechts één ervan bepaalt of openbare bestemmingen de tunnel gebruiken.

De regel die je verwijderde was een volgende hop, geen beleidsschakelaar

Elke route die de client installeert heeft een gateway-adres nodig om naar te wijzen, en de gateway-richtlijn is waar dat adres vandaan komt wanneer een route er zelf geen noemt. Verwijder die en die routes hebben niets om aan vast te hangen, dus ze worden ofwel niet geïnstalleerd of belanden op een pad dat nergens heen leidt. Het privé-subnet is precies wat zo'n route droeg.

Ondertussen heeft het gedrag dat overleefde een andere auteur: een omleidingsoptie in het gepushte blok, die gewoon uitgaand verkeer volgens zijn vlaggen de tunnel in schuift. Het verwijderen van de gateway schakelt die optie niet uit en verzwakt hem niet. Het resultaat is het slechtste van beide toestanden, met openbaar verkeer nog steeds gevangen en de privébestemming die de tunnel rechtvaardigde nu onbereikbaar. Daarom verandert de tweede bewerking, in dezelfde geest gedaan, ook niets.

Vier hendels, vier verschillende taken

Vier richtlijnen worden in deze discussie door elkaar geciteerd, en slechts één ervan beheert de dekking, namelijk welke bestemmingen überhaupt door de tunnel gaan. Een tweede stelt de volgende hop in die routes gebruiken, een derde installeert één prefix, en een vierde gooit alles weg wat de server pushte, inclusief de privéroutes die de uitrol nodig heeft. De tabel sorteert ze naar wat een beheerder probeert te veranderen en niet naar naam, omdat juist de namen de verwarring veroorzaken. Behandel ze als vier afzonderlijke beslissingen en kies degene die je echt wilt terugdraaien.

In de praktijk komen alle vier vaak in één gepusht blok, regel na regel, waardoor ze op delen van één instelling lijken. Dat zijn ze niet, en de OpenVPN-referentie documenteert ze juist daarom als afzonderlijke mechanismen. Uitzoeken welke beslissing je terugdraait is het werk; de bewerking is één regel.

Filter de gepushte regel, behoud de volgende hop

Als de dekking waar je bezwaar tegen maakt als gepushte optie binnenkomt, is het smalle antwoord die optie bij naam negeren en de rest van het gepushte blok ongemoeid laten. Als filter geschreven ziet het eruit als de regel hieronder, en het hoort in het profiel van de betrokken client, niet in de serverconfiguratie.

pull-filter ignore "redirect-gateway"

Smallheid is het punt. Omdat het filter een tekstprefix vergelijkt, past een korter patroon ook op de volgende-hop-richtlijn, wat precies de informatie afpelt waarvan de privéroutes afhangen en de oorspronkelijke fout in een nieuw jasje herhaalt. Een filter werkt ook alleen op gepushte opties, dus het raakt nooit een gelijkwaardige regel die lokaal is geschreven of door een netwerkbeheerder is opgelegd. Maak daarna opnieuw verbinding, want een actieve sessie herwaardeert niet wat de server pushte.

Lees de opzoeking, niet de tabel

Vraag na het herladen van het profiel aan de kernel waar twee bestemmingen werkelijk heen zouden gaan: één binnen het privéprefix en één op het openbare internet. Een volledige dump van de hoofdtabel is moeilijker te lezen en makkelijker verkeerd te lezen, omdat een route kan bestaan en toch verliezen van een specifiekere overeenkomst. Bij policy-routing horen ook de regel, de tabel en het bronadres bij de controle.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

De def1-variant verdient bekendheid, omdat hij het oude standaarditem zichtbaar laat terwijl een paar half-standaarden de opzoeking winnen. Een regel 0.0.0.0/0 in de uitvoer bewijst dus op zichzelf niets. De opzoeking beantwoordt de vraag die de lijst alleen lijkt te beantwoorden.

DNS, IPv6 en de privéroute moeten nog steeds werken

Eén IPv4-omleiding weigeren zegt niets over de resolver, dus een gepushte DNS-optie kan vragen naar de tunnel blijven sturen terwijl de routes er correct uitzien. Een IPv6-standaard kan hetzelfde doen voor een adresfamilie die de IPv4-controle nooit heeft aangeraakt. Beide vragen een expliciete beslissing in plaats van een aanname. Bevestig daarna dat de privédienst nog antwoordt, want een gesplitste tunnel die zijn privéroute kwijt is, is geen gesplitste tunnel, maar een kapotte.

Eén breder gereedschap verdient een waarschuwing: route-nopull gooit elke gepushte route en elke gepushte DNS-optie weg, wat de volledige tunnel zeker stopt en net zo zeker de privéroutes breekt waarvan de uitrol afhangt, dus het is een veel grotere hamer dan een naamfilter dat op één optie is gericht. Controleer na elke wijziging de privébestemming, een openbare bestemming en de resolver, en beschouw een voltooide handdruk als bewijs van niets anders dan de handdruk.