Begränsa OpenVPN SNAT-regeln innan den krossar nginx

Två fel kommer ständigt från samma typ av värd. I det första autentiserar klienterna sig och når sedan ingenting utanför tunneln. I det andra kommer VPN:en upp och värdens egen webbplats slutar svara, vilket är det mest alarmerande eftersom det ser ut som följdskador. På en containerbaserad VPS leder båda oftast tillbaka till samma korta lista med kontroller, och ordningen spelar roll: enheten först, översättningen sedan, omfånget sist.

Bekräfta att containern kan skapa en tun-enhet

Ingenting annat spelar roll om tunnelgränssnittet inte kan existera. Kontrollera att /dev/net/tun finns och att skapandet av en testenhet lyckas, eftersom många leverantörer inaktiverar tun i containrar som standard. Inget firewall-arbete kompenserar en enhet som aldrig skapades.

Om enheten saknas kan bara värden eller leverantören aktivera den. En annan plan är ofta billigare än en öppen supporttråd som varar en vecka. Bekräfta detta innan du läser en enda rad i OpenVPN-loggen. Annars tillbringar du kvällen med att finjustera regler som aldrig kommer att se ett paket.

Bestäm vad MASQUERADE gör på det här gränssnittet

På en vanlig virtuell maskin är den vanliga utgående regeln POSTROUTING MASQUERADE ut ur huvudgränssnittet. I en OpenVZ-container är den synliga enheten ofta venet0, ett värdstyrt virtuellt gränssnitt snarare än ett routat nätverkskort, och MASQUERADE beter sig inte alltid där som guider antar.

Den användbara formen är explicit översättning till adressen som klienterna redan når, med vidarebefordran tillåten i båda riktningarna. Att byta ut poolen från serverkonfigurationen spelar lika stor roll som att byta ut adressen. Läs varje rad innan du klistrar in den.

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

Utan vidarebefordringsreglerna sker översättningen ändå och kärnan vägrar ändå att vidarebefordra. Den kombinationen skapar det förvirrande tillstånd där räknarna på NAT-regeln stiger medan klienten inte får något. De två FORWARD-raderna måste också stå före varje bred drop-regel i samma kedja. Ordningen är en del av konfigurationen, inte en implementeringsdetalj.

Begränsa regeln till en pool och ett gränssnitt

Det andra symptomet har en annan orsak: en POSTROUTING-regel utan både käll- och utbegränsning. En sådan regel skriver om varje paket som lämnar värden.

Tjänster som är beroende av den ursprungliga källan beter sig då fel. En webbserver bakom en lokal proxy kan sluta svara, och en omstart ändrar ingenting eftersom regeln fortfarande är i vägen. Även trafiken som värden skickar till sin egen offentliga adress påverkas, och därför kan felet se ut som ett DNS- eller certifikatproblem i stället för ett firewall-problem. Regeln lades nästan säkert till för att åtgärda det första symptomet.

Lösningen är att snäva in matchningen till tunnelpoolen och det utgående gränssnittet och sedan lägga till en regel per pool i stället för att bredda en enda regel till att omfatta flera.

Gör reglerna beständiga och ta reda på vem mer som äger dem

Regler som lagts till för hand försvinner vid omstart, så spara dem med iptables-save eller hantera dem via netfilter-persistent där det är installerat. Bekräfta att återställningen körs innan OpenVPN startar. Starta sedan om en gång med avsikt i stället för att upptäcka luckan under en incident.

På en containervärd, bekräfta också att beständighetsfilen ligger i skrivbar containerlagring och att leverantören inte ersätter filtreringen vid uppstart. Vissa plattformar hanterar policy utanför containern, där lokala regler antingen ignoreras eller krockar med värdens egna.

Verifiera med räknare och ett fångat flöde

Från en ansluten klient, kontrollera den offentliga adress som en extern tjänst rapporterar. Om den matchar serverns adress fungerar översättningen; om inte lämnar paketet via en annan väg eller lämnar inte alls. Testa sedan både en tjänst på servern och en på det öppna internet, eftersom de tar olika vägar genom samma regeluppsättning.

På servern, läs paketräknarna på NAT- och FORWARD-reglerna med iptables -t nat -L -v -n och följ ett flöde i en fångst. Om klientens adress dyker upp i fångsten och inget svar följer, sitter luckan på returvägen eller i leverantörens filtrering, inte i klientprofilen. Jämför den fångade källan med adressen som regeln översätter till, eftersom en avvikelse betyder att en annan regel matchade först. Ett observerat flöde avgör mer än en sida konfigurationsläsning.

Håll poolen, den översatta adressen och gränssnittsnamnet tillsammans i ändringsloggen. En regel som är korrekt för en pool översätter nästa fel.