Beperk de OpenVPN-SNAT-regel voordat die nginx breekt

Twee storingen komen steeds van hetzelfde type host. Bij de eerste authenticeren clients en bereiken daarna niets voorbij de tunnel. Bij de tweede komt de VPN omhoog en stopt de eigen website van de server met antwoorden, wat het meest alarmerend is omdat het op bijkomende schade lijkt. Op een containergebaseerde VPS leiden beide meestal terug naar dezelfde korte lijst controles, en de volgorde is belangrijk: eerst het apparaat, dan de vertaling, dan de scope.

Controleer of de container een tun-apparaat kan aanmaken

Niets anders is belangrijk als de tunnelinterface niet kan bestaan. Controleer of /dev/net/tun aanwezig is en of het aanmaken van een testapparaat lukt, want veel providers schakelen tun in containers standaard uit. Geen enkele firewall-inspanning compenseert een apparaat dat nooit is aangemaakt.

Ontbreekt het apparaat, dan kunnen alleen de host of de provider het inschakelen. Een ander pakket is vaak goedkoper dan een open supportthread die een week duurt. Bevestig dit voordat je één regel van het OpenVPN-log leest. Anders breng je de avond door met het bijstellen van regels die nooit een pakket zullen zien.

Bepaal wat MASQUERADE op deze interface doet

Op een gewone virtuele machine is de gebruikelijke uitgaande regel POSTROUTING MASQUERADE uit de hoofdinterface. In een OpenVZ-container is het zichtbare apparaat vaak venet0, een door de host beheerde virtuele interface in plaats van een gerouteerde NIC, en MASQUERADE gedraagt zich daar niet altijd zoals tutorials aannemen.

De werkbare vorm is expliciete vertaling naar het adres dat clients al bereiken, met doorsturen toegestaan in beide richtingen. De pool uit de serverconfiguratie vervangen is net zo belangrijk als het adres vervangen. Lees elke regel voordat je hem plakt.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Zonder de doorstuurstregels gebeurt de vertaling nog steeds en weigert de kernel nog steeds door te sturen. Die combinatie levert de verwarrende toestand op waarin tellers op de NAT-regel stijgen terwijl de client niets ontvangt. De twee FORWARD-regels moeten ook vóór elke brede drop-regel in dezelfde keten staan. Volgorde is onderdeel van de configuratie, geen implementatiedetail.

Beperk de regel tot één pool en één interface

Het tweede symptoom heeft een andere oorzaak: een POSTROUTING-regel zonder bron- en zonder uitvoerbeperking. Zo'n regel herschrijft elk pakket dat de host verlaat.

Diensten die van de oorspronkelijke bron afhankelijk zijn, gedragen zich dan verkeerd. Een webserver achter een lokale proxy kan stoppen met antwoorden, en herstarten verandert niets omdat de regel nog steeds in het pad zit. Ook verkeer dat de host naar zijn eigen openbare adres stuurt, wordt geraakt, waardoor de storing op een DNS- of certificaatprobleem kan lijken in plaats van een firewallprobleem. De regel is vrijwel zeker toegevoegd om het eerste symptoom op te lossen.

De oplossing is de overeenkomst te vernauwen tot de tunnelpool en de uitgaande interface, en dan één regel per pool toe te voegen in plaats van één regel te verbreden om er meerdere te dekken.

Maak de regels persistent en ontdek wie ze nog meer bezit

Handmatig toegevoegde regels verdwijnen bij een herstart, dus sla ze op met iptables-save of beheer ze via netfilter-persistent waar dat geïnstalleerd is. Bevestig dat het herstel loopt voordat OpenVPN start. Herstart dan één keer expres in plaats van het gat tijdens een incident te ontdekken.

Controleer op een containerhost ook dat het persistentiebestand in beschrijfbare containeropslag staat en dat de provider het filteren bij het opstarten niet vervangt. Sommige platforms beheren beleid buiten de container, waar lokale regels ofwel worden genegeerd ofwel botsen met die van de host zelf.

Verifieer met tellers en één vastgelegde flow

Controleer vanaf een verbonden client het openbare adres dat een externe dienst meldt. Komt het overeen met het adres van de server, dan werkt de vertaling; zo niet, dan verlaat het pakket via een ander pad of verlaat het helemaal niet. Test daarna zowel een dienst op de server als een dienst op het openbare internet, omdat die verschillende paden door dezelfde regelset nemen.

Lees op de server de pakkettellers op de NAT- en FORWARD-regels met iptables -t nat -L -v -n en volg één flow in een capture. Als het adres van de client in de capture verschijnt en er geen antwoord volgt, zit het gat op het retourpad of in het filteren van de provider, niet in het clientprofiel. Vergelijk de vastgelegde bron met het adres waar de regel naar vertaalt, want een afwijking betekent dat een andere regel eerst overeenkwam. Eén geobserveerde flow beslist meer dan een pagina configuratie lezen.

Houd de pool, het vertaalde adres en de interfacenaam samen bij in het wijzigingslog. Een regel die voor de ene pool correct is, vertaalt de volgende verkeerd.