Waarom een OpenVPN-clientblokkeerregel nooit FORWARD raakt

Twee clients op dezelfde OpenVPN-server kunnen elkaar bereiken, zelfs nadat je een DROP-regel voor hun pool hebt toegevoegd. De regel staat in de FORWARD-keten, het verkeer stroomt duidelijk, en de teller van die regel blijft op nul. De natuurlijke conclusie is dat de firewall kapot is. Vaker is het pakket helemaal nooit in de keten gekomen.

Er zijn twee paden die een peer-pakket door een OpenVPN-server kan nemen, en die worden bepaald door de configuratie, niet door de firewall. Weten welk pad in gebruik is, vertelt je of een hostregel überhaupt op de juiste plek staat.

Twee paden die een peer-pakket kan nemen

Als de optie voor interne doorsturing uit staat, komt een pakket van client A aan op de tunnelinterface met een bestemming binnen het aan client B toegewezen adres. De routetabel van de server stuurt het terug via dezelfde tunnelinterface, omdat de server de route naar B's adres bezit. Dat is een in-en-uit-stroom door de host, en het IPv4-doorstuurpad beoordeelt die.

Als de optie voor interne doorsturing aan staat, koppelt het serverproces het pakket aan een verbonden client en schrijft het direct terug naar die client. Het pakket wordt binnen de daemon afgehandeld en komt nooit meer in het tunnelapparaat, dus het doorstuurpad van de host wordt volledig overgeslagen. De OpenVPN 2.6-handleiding beschrijft deze optie als interne client-naar-client-doorsturing, en dat is precies waarom een firewallregel op de host die niet kan zien.

Er bestaat een derde variant in installaties die het datakanaal naar een kernelmodule overhevelen. De doorstuur beslissing en de versleuteling verlaten de gebruikersruimte, en of netfilter de stroom ziet hangt af van hoe het overbrengpad is gebouwd. Ga er nooit van uit dat een oude regelset zich op een overgebrachte server hetzelfde gedraagt als op een in de gebruikersruimte. Bevestig de modus uit de draaiende configuratie, niet uit de pakketversie.

Wanneer de teller nooit beweegt

Een nulteller betekent dat het pakket die regel op dat punt niet raakte, en daar zijn meerdere redenen voor. De eerste is de omweg hierboven: het verkeer bereikte de keten nooit. De tweede is een mismatch in interface, richting, bron of bestemming, wat gebruikelijk is wanneer de pool opnieuw is genummerd en de regel nog steeds de oude prefix noemt.

De derde is positie. Een regel eerder in de keten kan de stroom accepteren voordat jouw DROP wordt beoordeeld, en een regel later kan degene zijn die het resultaat werkelijk bepaalt. Lees de keten in volgorde met zichtbare tellers, en controleer dan welke regel oploopt wanneer je de test herhaalt.

Voer één gecontroleerde uitwisseling uit tussen twee clients van wie je de echte adressen hebt bevestigd uit de eigen toestand van de server, niet uit een lease die je je herinnert. Beweegt de relevante teller nog steeds niet, verdenk dan het pad voordat je de match herschrijft. Beweegt hij wel maar slaagt de verbinding nog, dan wordt de drop later overschreven en is de volgorde het probleem. Dat antwoord bepaalt of de reparatie een regelwijziging of een topologiewijziging is, dus haal het voordat je iets bewerkt.

Een grens kiezen die kan filteren

Als het beleid in de firewall van de host moet wonen, zet het verkeer dan waar de firewall het kan zien. Interne doorsturing uitschakelen is de ondersteunde manier om peer-verkeer door de tunnelinterface en het doorstuurpad te laten gaan, tegen de prijs dat elk peer-pakket door de stack van de host gaat.

Match daarna de stroom precies. Verkeer komt aan op de tunnelinterface en vertrekt via de tunnelinterface, in beide richtingen, dus regels die alleen naar de fysieke interface kijken zullen niet matchen. Adresgebaseerde regels hebben de huidige pool nodig, en ze moeten rekening houden met de retourrichting net als met de heenrichting.

Veel installaties zijn beter gediend met filteren op client- of groepsniveau, waar de identiteit bekend is en het beleid de gebruiker volgt in plaats van een adres dat bij herverbinden verandert. Dat is een ander mechanisme dan een keten op de host, en de twee moeten niet zonder duidelijke reden worden gemengd.

Neem een regelset van een oude topologie niet ongewijzigd mee door een migratie. Adrespoelen, interfacenamen en doorstuurmodi beïnvloeden allemaal of een regel matcht, en een gekopieerde regel die vroeger werkte is het meest misleidende soort bewijs. Begin bij de stroom die je wilt toestaan en schrijf de regel die daarbij past.

Isolatie testen in plaats van een regel vertrouwen

Test het verboden geval en het toegestane geval in dezelfde run. Start een nieuwe verbinding van de ene client naar de andere en bevestig dat die faalt, bevestig daarna dat een verbinding die toegestaan zou moeten zijn nog werkt. Als alleen het eerste wordt getest, lijkt een firewall die alles blokkeert op een succes.

Herhaal dit na het herladen van de serverconfiguratie en nadat een client opnieuw verbindt, omdat interne doorsturing en pooltoewijzingen runtime-toestand zijn. Controleer tellers in beide richtingen, want een regel die één richting matcht en het antwoord niet levert gedeeltelijke isolatie op die in een snelle test moeilijk te merken is.

Isolatie is het waargenomen resultaat op de grens die de stroom werkelijk draagt. Een DROP-regel ergens in de host is geen bewijs; een mislukte verbinding plus een bewogen teller op de regel die dat veroorzaakte is dat wel.