Eén LAN-subnet via OpenVPN routeren en de standaardroute behouden

Apparaten die routeren voor een LAN en tegelijk een VPN opbellen, belanden in dezelfde discussie met zichzelf: de tunnel wil de standaardroute bezitten, en het LAN heeft die terug nodig. Wanneer OpenVPN verbindt, kan het een standaardroute via de tunnel installeren of een paar halve standaardroutes, wat goed is voor een laptop en verkeerd voor een gateway waarvan de buren antwoorden vanaf zijn LAN-adres verwachten. Het antwoord is niet de VPN overslaan. Het antwoord is de twee beslissingen verschillende tabellen geven.

Eén standaardroute, twee eigenaren

Doorgestuurd verkeer en lokaal ontstaan verkeer hoeven niet dezelfde weg te volgen. LAN-clients hebben de tunnel alleen nodig voor de bestemmingen die je kiest, terwijl de eigen beheersessies van de host en zijn antwoorden aan die clients de LAN-standaardroute nodig hebben. Beide in de hoofdtabel mengen dwingt één antwoord op twee verschillende vragen af.

OpenVPN heeft precies hiervoor een schakelaar. route-noexec voorkomt dat de client de hoofdtabel überhaupt aanraakt, en de waarden die hij zou hebben gebruikt worden geëxporteerd naar een route-up-script als route_vpn_gateway, dev en de interfaceadressen. Daarna bepaal jij welke tabel welke route krijgt, in code die je later kunt lezen.

Beleidstabel versus de hoofdtabel herschrijven

De aparte tabel is de enige optie die verder schaalt dan één subnet. Geef hem één keer een naam en verwijs daarna met de naam, zodat niemand een nummer hoeft te onthouden:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

De adressen hier zijn plaatsaanduidingen. Vervang het LAN-voorvoegsel, de tunnelgateway en de apparaatnaam uit je eigen uitrol voordat je iets uitvoert.

De regel moet ook bij de host passen

Een regel die alleen bij het LAN-voorvoegsel past, dekt doorgestuurde pakketten. Hij dekt geen verkeer dat de gateway zelf maakt, en ook niet de antwoorden die hij terugstuurt naar LAN-clients, die het LAN-adres van de gateway als bron dragen. Die opzoekingen vallen door naar main en kunnen nog steeds via de tunnel naar buiten.

Voeg een tweede regel toe voor het eigen LAN-adres van de gateway, of verbreed de eerste regel naar een verzameling die beide omvat. De volgorde is belangrijk: zet de meer specifieke regel eerst en controleer het resultaat met een opzoeking die de bron expliciet noemt.

ip route get 203.0.113.9 from 192.168.50.1

Als dat het tunnelapparaat meldt voor een bestemming die lokaal zou moeten blijven, is de regelset fout, ongeacht wat de tabel bevat.

NAT of een route aan de overkant

De VPN-server kent het tunnelsubnet en niets anders. Pakketten die met een LAN-bronadres aankomen hebben geen terugweg tenzij iemand er een voorziet, en er zijn precies twee manieren om dat te doen. Een route voor het LAN-voorvoegsel op de server toevoegen houdt de oorspronkelijke bron van begin tot eind zichtbaar, wat een geauditeerd ontwerp meestal wil. Maskering op de gateway herschrijft de bron naar het tunneladres en vereist geen medewerking van de server.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Kies NAT wanneer je de server niet beheert en er geen routes kunt toevoegen. Kies de route aan de serverkant wanneer logboeken, toegangscontrole of symmetrie van de terugweg belangrijk zijn, want maskering wist het oorspronkelijke adres uit alles wat de andere kant vastlegt.

Hoe dan ook moet doorsturen zijn ingeschakeld, en strikte reverse-path-filtering kan het antwoord laten vallen wanneer main de tunnel voor die bron niet zou hebben gekozen. Controleer de effectieve waarde voordat je de tunnel de schuld geeft.

Laat de splitsing een herverbinding overleven

Handmatig toegevoegde regels en routes verdwijnen wanneer de interface opnieuw wordt gemaakt, en een verouderd tabelitem kan de sessie overleven die het rechtvaardigde. Zet de tabelregel, de tunnelroute en het maskeringsitem in het route-up-script van de client, en leeg de tabel bovenaan het script zodat een oude gateway niet in de nieuwe sessie kan overleven.

Controleer vanaf beide kanten: een opzoeking op de gateway met de LAN-bron, en een echt verzoek van een LAN-client naar een bestemming die door de tunnel moet. Een route die bestaat maar nooit wordt gekozen gedraagt zich precies als geen route, totdat je de tellers leest.