Bridged OpenVPN-clients hebben geen internet? Controleer de NAT-regel

De bridgeserver draait, de masquerade-regel staat er, en toch blijft de browser op de client draaien. Alles ziet eruit alsof het zou moeten werken, en daarom gaat het eerste uur naar het controleren van de tunnel en de inloggegevens. Dan lees je de teller op de NAT-regel en zie je een nul die niet is opgeschoven. Een regel die nooit een pakket heeft geteld, heeft er nooit een gematcht, en op een bridgeserver is de reden structureel: clientverkeer verlaat het systeem via het virtuele tap-apparaat, terwijl de regel de fysieke kaart noemt die je uit een oudere handleiding hebt gekopieerd.

De teller is het bewijs, niet de tabelregel

Regels die bestaan en regels die matchen zijn verschillende dingen, en de teller is wat ze scheidt. Toon de NAT-tabel met uitgebreide tellers en lees de getallen naast elke regel voordat je iets verandert. Een teller die op nul blijft staan terwijl het verkeer stroomt, betekent dat de regel is overgeslagen, hoe logisch de adressen er ook uitzien. Een teller die oploopt terwijl de verbinding nog steeds mislukt, stuurt je ergens anders heen: forwarding, de terugweg of de andere kant.

iptables -t nat -L POSTROUTING -v -n

Lees eerst de teller naast de interfacematch. Als het bronbereik klopt en de uitgangszijde niet, is de oplossing een woord in de regel in plaats van een compleet nieuwe regel.

Zoek de naam die de kernel daadwerkelijk vastlegt

Bepaal de naam van het tunnelapparaat voordat je de regel schrijft, met de interfacelijst in plaats van je geheugen. Op een bridge-opstelling met OpenVPN is het apparaat meestal een tap-interface die door de server is aangemaakt, en de naam ervan hoort bij je lokale configuratie, niet bij een universele constante. Controleer dat het bestaat terwijl de tunnel actief is, want een apparaat dat pas verschijnt nadat een client verbinding maakt, laat een eerdere test op een regelprobleem lijken.

ip -brief link

Schrijf de naam op. Elk later commando in deze diagnose verwijst ernaar, en een typefout hier levert precies dezelfde nulteller op als de oorspronkelijke fout.

Herschrijf de regel tegen het tunnelapparaat

Richt de regel op het tunnelapparaat en houd het clientbereik als matchvoorwaarde, zodat die het tunnelverkeer dekt en de eigen verbindingen van de host met rust laat. Vervang bereik en apparaatnaam door je eigen waarden, want beide hieronder zijn voorbeelden en geen van beide is overdraagbaar tussen installaties.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

Controleer daarna de twee andere voorwaarden die hetzelfde symptoom verbergt. Controleer of forwarding is ingeschakeld, en zo niet, schakel het dan in de configuratie van de distributie zelf in en niet met een echo die bij een herstart verdwijnt. Lees ook de tellers van de forward-keten, en als die het tunnelverkeer laat vallen, sta dat interface dan expliciet toe en laat het ketenbeleid met rust.

De forward-keten met tellers lezen kost een commando en sluit de helft van de resterende mogelijkheden uit voordat je een andere regel aanraakt.

Waarom de fysieke kaart nooit matcht

Een bridge is een softwareswitch die is samengesteld uit het tap-apparaat en een fysieke interface. Het clientframe komt die switch binnen en verlaat hem richting het fysieke netwerk als lid van de bridge in plaats van als een pakket op de kaart. De kernel schrijft het pakket daarom toe aan de bridge en zijn poort, en daarom duikt de kaart die je in gedachten had nooit op in de match. Aan de fysieke interface is niets kapot; hij is simpelweg niet het apparaat waaraan de kernel dat pakket toeschrijft.

Het vervolgprobleem dat mensen daarna tegenkomen komt uit dezelfde structuur: frame filtering op een bridge is een aparte voorziening naast IP-filtering. Als de eis een beperking op frameniveau is, hoort die bij bridge filtering, niet bij een regel in de IP-tabel.

Bewijs het van begin tot eind en maak het daarna blijvend

Start een client en ping iets op het LAN van de server; dat pad oefent forwarding zonder enige vertaling. Vraag daarna iets openbaars aan, zodat de masquerade-regel gebruikt moet worden, en lees de teller nog eens: hij hoort te bewegen voor deze test en niet voor de vorige. Een capture op het tunnelapparaat laat zowel zien waar het frame verschijnt als welk adres het draagt.

Laatste stap: zet de regels die werken in de configuratie die een herstart leest, en noteer de apparaatnaam die de bridge van deze host werkelijk gebruikt. Alles wat met de hand is getypt, is na een herstart weg, en dezelfde storing komt terug zonder dat er nog iets is dat hem verklaart.

Als de teller na het herschrijven nog steeds niet beweegt, vergelijk dan het bronbereik in de regel met het adres dat de client werkelijk heeft gekregen, want een bridgeserver kan adressen uitdelen uit een bereik dat je niet bedoelde.