Hoe je één test-LAN zijn eigen WireGuard-uitgang geeft

Drie ontwerpen lossen hetzelfde labprobleem op: een klein LAN moet via een WireGuard-peer naar buiten terwijl de gateway zelf zijn gewone uplink houdt. De verleidelijke sluiproute is de standaardroute van de router de tunnel in schuiven, maar dat breekt het eigen beheerpad van de doos en alles wat hij doorstuurt. De interessante optie is policy-routing, beperkt tot één interface en één prefix. Kies tussen beide door drie vragen te beantwoorden over de machine die je werkelijk hebt.

Bepaal waar de uitgang woont

Eerste vraag: stuurt deze host ook voor iets anders door? Een toegewijde labgateway kan leven met een doorstuurbeleid dat standaard alles laat vallen. Een router met productietaken kan dat niet, en een concurrerende regelset over een beheerde firewall heen leggen is precies de manier waarop storingen worden ingepland. Tweede: kun je twee beleidsobjecten en hun volgorde over herstarts heen bezitten? Derde: autoriseert de peer die je hebt je tunnelbronadres en biedt hij internetuitgang? Een peer die alleen een privaat netwerk blootlegt is een ander product, en geen enkele lokale routingwijziging lost dat op. Als een antwoord nee is, zet de uitgang dan in een namespace of in een wegwerp virtuele machine.

Een namespace of een VM kost geheugen en geeft je een schone explosieradius. Policy-routing kost twee regels en laat je één doos over om te debuggen.

Kies de uitgang die je bron autoriseert

De meeste fouten in dit lab gebeuren voordat er ook maar één firewallregel bestaat. De operator van de uitgang moet het bronadres accepteren dat je pakketten na de vertaling dragen, en in dit ontwerp is dat het tunneladres en niet het LAN-prefix. Daarom hoort maskering vanaf het begin in het ontwerp en niet als late toevoeging.

Bevestig drie dingen bij de operator: de peer autoriseert je tunneladres, hij stuurt IPv4 door in plaats van bij zichzelf te eindigen, en hij past uitgaande NAT toe. Zonder het eerste komen je pakketten aan en verdwijnen. Zonder het derde gaan ze met een private bron naar buiten en sterven op de volgende hop. Controleer dan dat wg-quick geen eigen standaardroute installeert, wat Table = off voorkomt; die instelling onderdrukt het aanmaken van routes, niet de AllowedIPs-controles van de peer of zijn DNS-afhandeling.

Twee beleidsobjecten doen de sturing

Sturing vraagt een tabel en een regel. De tabel houdt twee routes: het LAN-prefix de LAN-interface uit en een standaard de tunnel uit. De regel stuurt verkeer dat op de LAN-interface aankomt en dat prefix draagt de tabel in. Gebruik de iif-selector naast de bronmatch, want de eigen WireGuard-pakketten van de gateway ontstaan lokaal en matchen nooit een inkomende interface.

De wachter komt vóór de opzoeking, niet erna. Die volgorde is de hele veiligheidseigenschap van het ontwerp.

De wachter is een tweede regel op dezelfde selector met als uitspraak unreachable. Geef hem een hogere numerieke prioriteit zodat de opzoeking nog steeds wint zolang de tunnel omhoog is. Als de tunnelroute verdwijnt, levert de opzoeking niets op en stopt de wachter de zoektocht in plaats van hem door te laten vallen naar de WAN-standaard in de hoofdtabel.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Sluit het terugvalgat voordat je het opent

Installeer eerst de wachter en daarna de opzoeking. Andersom laat een venster van seconden waarin het verkeer van een testclient de uplink kan bereiken.

Het filter maakt het beeld compleet. In de forward-hook accepteer je de richting van LAN naar tunnel voor het testprefix en de gevestigde retourrichting, en laat je al het andere vallen; de NAT voor dat prefix naar de tunnelinterface hoort in postrouting. Juist policy drop op de forward-keten laten staan maakt van een ontbrekende route stilte in plaats van een lek. Reverse-path-filtering vereist losse modus op de tunnelinterface, omdat een publieke bron die gedecapsuleerd aankomt zijn beste omgekeerde route aan de WAN-kant heeft. Linux neemt de hoogste van de waarde all en per interface, dus de tunnelinterface instellen is niet hetzelfde als overal de validatie verzwakken.

Bewijs het met het foutgeval

Stel de kernel een precieze vraag door het bronadres van de client en de interface waarop hij aankomt te noemen. Een opzoeking zonder beide beantwoordt een andere vraag en ziet er in beide gevallen correct uit. Kijk daarna naar de firewalltellers, de overdrachtsstatus van de peer en de dienst van de client zelf.

Test het verwijderen goed. Stop de tunnel terwijl de regel en het filter op hun plaats blijven: de client hoort te stokken en het eigen verkeer van de gateway hoort te blijven werken. Stop daarna de peer zonder de lokale interface aan te raken, en dat is het geval dat ontwerpen vangt die alleen op de aanwezigheid van de route vertrouwen. Herstart ten slotte en controleer de regelvolgorde opnieuw, want een teardown-hook die de wachter verwijdert geeft het hele ontwerp terug aan de hoofdtabel. Noteer het tabelnummer, de prioriteiten en de interfacenamen op het wijzigingsticket, want de volgende persoon die een regel toevoegt is degene die dit breekt.