OpenVPN-client voor het hele LAN op OpenWrt: een werkende volgorde

Vier onafhankelijke taken zetten het hele LAN van een router achter één tunnel. Het tunnelapparaat heeft een eigenaar nodig, een firewallzone, een vertaaldoel richting de uplink en, als sommige clients buiten de VPN moeten blijven, routering op bronadres. Een tunnel die verbindt terwijl er niets doorheen gaat, mist meestal een van die vier. In afhankelijkheidsvolgorde werken betekent dat een fout aan het einde bij de stap hoort die je zojuist hebt gewijzigd. Elke stap hieronder eindigt met iets wat je kunt waarnemen, en dat houdt de volgende stap weg van giswerk.

Bepaal wat de tunnel deelt

De router die wifi en DHCP uitdeelt, kan de client zelf draaien. Dat zet elk aangesloten apparaat achter de tunnel zonder instelling per apparaat, en dat is de opstelling die de meeste kleine locaties willen. Het is ook de opstelling met de grootste impact als de tunnel wegvalt, omdat elk apparaat tegelijk zijn route verliest. Niets op het LAN houdt een werkende uitweg.

Een tweede router achter de eerste, die de client met een eigen subnet draait, beperkt de tunnel tot zijn eigen apparaten. Het is makkelijker te verwijderen en makkelijker uit te leggen aan wie het erft. De prijs is bereikbaarheid tussen beide kanten zonder een route of een port forward.

Hoe dan ook, maak de LAN-subnetten verschillend. Identieke bereiken laten één kant direct verbonden lijken, en het zwarte gat dat daaruit ontstaat leest urenlang als een VPN-storing.

Geef de tunnel een eigenaar

Declareer de tunnel als netwerkinterface met een naam, een apparaat en geen eigen protocol. Het netwerksysteem maakt en beheert het apparaat dan, en alles stroomafwaarts verwijst naar de interface bij naam, niet bij apparaat. Dat is wat de zone in staat stelt hem te vinden.

Maak hetzelfde apparaat niet op twee plaatsen. Een handgemaakte tunnel naast een gedeclareerde interface levert een apparaat op dat bestaat maar niet in een zone zit, of een dat verdwijnt bij herladen. Beide lijken op een mislukte client, en geen van beide geeft een fout die de echte oorzaak noemt. Kies het declaratieve pad en verwijder het handmatige.

Houd de naam identiek in de netwerk-, firewall- en VPN-configuratie. De zone noemt netwerken bij naam, dus een typefout laat de tunnel buiten elke zone terwijl de interface zelf gezond lijkt. Een gezonde interface zonder beleid is de moeilijkst te herkennen toestand.

Zet hem in een zone en stuur er dan naartoe

Een firewallzone is waar het beleid woont: input, output, forward en masquerade. Een tunnel in geen enkele zone wordt bestuurd door standaardwaarden die je niet hebt gekozen, en dat is zelden wat een routerclient nodig heeft. De blokken hieronder declareren de interface, plaatsen hem in een zone en staan LAN-verkeer naar die zone toe.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

Op releases ouder dan 21.02 wordt dezelfde interfaceregel geschreven als option ifname, dus controleer welke vorm de geïnstalleerde firmware leest voordat je plakt. Het doorstuurblok is de toestemming die LAN-verkeer de tunnel sowieso laat gebruiken. Zonder dat staat het apparaat aan, is de client verbonden en bereikt geen enkele LAN-host de tunnel. Dat is de meest voorkomende melding van verbonden maar geen internet bij routerclients.

Masquerade op de VPN-zone trekt elk LAN-adres samen in het tunneladres van de router voordat het pakket vertrekt. Dat maakt een retourroute naar je subnet aan de andere kant overbodig.

Als de andere kant je LAN al routeert, houdt masquerade uitzetten bronadressen zichtbaar en maakt logs per client zinvol. Kies er één en schrijf op welke, want de twee keuzes leveren later verschillende supportvragen op. Het weghalen van de standaard doorsturing van LAN naar WAN is een aparte beslissing met een eigen gevolg. Haal je die weg, dan gaat de eigen internettoegang van de router mee.

Noem de echte uplink in NAT

Op firmware waar de vertaalregel met de hand is geschreven, is de uitgaande interface het veld dat misgaat. Een regel die vlan2 noemt, doet niets wanneer de sessie op ppp0 eindigt. Een regel zonder enige interface kan verkeer vertalen dat privé had moeten blijven. Geen van beide fouten kondigt zich aan, omdat de tunnel blijft werken.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Vervang ppp0 in die regel door de interface uit ip route of de lijst met actieve interfaces, en kijk dan naar de teller terwijl een LAN-host een pagina laadt. Op een router met één provider is één masquerade-regel voor de uplink meestal genoeg. Een tweede regel voor de tunnelinterface is geen vervanging voor de eerste.

Voeg dan de clientopties toe die bepalen wat de tunnel in gaat. Een redirect-gateway-richtlijn stuurt internetverkeer van de client via de VPN, en zonder die richtlijn draagt de tunnel alleen de routes die de server pusht. Controleer de resulterende routetabel voordat je DNS aanraakt.

Splits de wifi met een tweede tabel

Eén routetabel kan geen twee standaarden bevatten. Een tweede SSID dat de tunnel moet omzeilen heeft daarom een eigen subnet en een eigen tabel nodig. Geef het getunnelde SSID een eigen bereik en routeer daarna alleen dat bereik de tunnel in met een regel die de tabel selecteert.

Beleidsrouteringspakketten op OpenWrt drukken precies die combinatie uit. Met de hand werkt het ook, met een bronregel en een tabel waarvan de standaard naar het tunnelapparaat wijst.

Controleer de splitsing vanaf beide netwerken. Een client op het getunnelde SSID hoort het exitadres van de VPN te tonen, en een client op het gewone SSID dat van de provider. Als beide er hetzelfde uitzien, koppelt de regel aan de verkeerde bron of wordt de tabel nooit geraadpleegd. Test ook na een herverbinding, want een regel die van de interfacenaam afhangt, breekt wanneer het apparaat opnieuw genummerd wordt.

Verdenk de klok en de apparaatvlag

De vlag persist-tun laat het tunnelapparaat over herstarts heen staan. Dat past bij een server en verwart een client wiens toestand vanaf nul opgebouwd moet worden. Haal hem weg tijdens het oplossen van een routerclient, want een apparaat dat een mislukte onderhandeling overleeft, verbergt welke stap echt brak. Zet hem terug zodra de client betrouwbaar verbindt, en niet eerder.

De klok is de andere stille fout. Een router zonder batterijgevoede klok begint bij het epoch, wat betekent dat certificaatcontroles falen tot NTP bijtrekt. Vergelijk de tijdstempels in het log met de echte tijd voordat je een certificaat aanraakt, want een client die een minuut na de start verbindt, wacht meestal op tijdsynchronisatie.