Afgræns OpenVPN SNAT-reglen, før den ødelægger nginx

To fejl kommer hele tiden fra samme slags vært. I den første autentificerer klienterne og når derefter intet ud over tunnelen. I den anden kommer VPN’et op, og serverens egen hjemmeside holder op med at svare, hvilket er den mest alarmerende, fordi det ligner følgeskader. På en containerbaseret VPS fører begge normalt tilbage til den samme korte liste af kontroller, og rækkefølgen er vigtig: enhed først, oversættelse derefter, afgrænsning til sidst.

Bekræft, at containeren kan oprette en tun-enhed

Intet andet betyder noget, hvis tunnelinterfacet ikke kan eksistere. Kontrollér, at /dev/net/tun findes, og at oprettelsen af en testenhed lykkes, fordi mange udbydere deaktiverer tun i containere som standard. Intet arbejde med firewall kan kompensere for en enhed, der aldrig blev oprettet.

Hvis enheden mangler, kan kun værten eller udbyderen aktivere den. En anden plan er ofte billigere end en åben supporttråd, der varer en uge. Bekræft dette, før du læser en enkelt linje af OpenVPN-loggen. Ellers bruger du aftenen på at finjustere regler, der aldrig vil se en pakke.

Beslut, hvad MASQUERADE gør på dette interface

På en almindelig virtuel maskine er den sædvanlige udgangsregel POSTROUTING MASQUERADE ud af hovedinterfacet. I en OpenVZ-container er den synlige enhed ofte venet0, et værtsstyret virtuelt interface frem for et routet netkort, og MASQUERADE opfører sig ikke altid der, som vejledninger antager.

Den brugbare form er eksplicit oversættelse til den adresse, klienterne allerede når, med videresendelse tilladt i begge retninger. At erstatte poolen fra serverkonfigurationen betyder lige så meget som at erstatte adressen. Læs hver linje, før du indsætter 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

Uden videresendelsesreglerne sker oversættelsen stadig, og kernen nægter stadig at videresende. Den kombination skaber den forvirrende tilstand, hvor tællere på NAT-reglen stiger, mens klienten intet modtager. De to FORWARD-linjer skal også stå før enhver bred drop-regel i samme kæde. Rækkefølge er en del af konfigurationen, ikke en implementeringsdetalje.

Afgræns reglen til én pool og ét interface

Det andet symptom har en anden årsag: en POSTROUTING-regel uden både kilde- og udgangsbegrænsning. En sådan regel omskriver hver pakke, der forlader værten.

Tjenester, der afhænger af den oprindelige kilde, opfører sig derefter forkert. En webserver bag en lokal proxy kan holde op med at svare, og en genstart ændrer intet, fordi reglen stadig er i vejen. Trafik, som værten sender til sin egen offentlige adresse, er også påvirket, og derfor kan fejlen se ud som et DNS- eller certifikatproblem snarere end et firewall-problem. Reglen blev næsten helt sikkert tilføjet for at rette det første symptom.

Løsningen er at indsnævre matchningen til tunnelpoolen og udgangsinterfacet og derefter tilføje én regel for hver pool i stedet for at udvide en enkelt regel til at dække flere.

Gør reglerne vedvarende, og find ud af, hvem der ellers ejer dem

Regler tilføjet i hånden forsvinder ved genstart, så gem dem med iptables-save eller administrer dem via netfilter-persistent, hvor det er installeret. Bekræft, at gendannelsen kører, før OpenVPN starter. Genstart derefter en gang med vilje i stedet for at opdage hullet under en hændelse.

På en containervært skal du også bekræfte, at vedholdenhedsfilen ligger i skrivbar containerlagring, og at udbyderen ikke erstatter filtrering ved opstart. Nogle platforme administrerer politik uden for containeren, hvor lokale regler enten ignoreres eller kæmper med værtens egne.

Verificér med tællere og én optaget strøm

Fra en tilsluttet klient kontrolleres den offentlige adresse, som en ekstern tjeneste rapporterer. Hvis den matcher serverens adresse, virker oversættelsen; hvis ikke, forlader pakken via en anden vej eller forlader slet ikke. Afprøv derefter både en tjeneste på serveren og en på det offentlige internet, fordi de tager forskellige veje gennem det samme regelsæt.

På serveren læses pakketællerne på NAT- og FORWARD-reglerne med iptables -t nat -L -v -n, og én strøm følges i en optagelse. Hvis klientens adresse vises i optagelsen, og der ikke følger et svar, er hullet på returvejen eller i udbyderens filtrering, ikke i klientprofilen. Sammenlign den optagede kilde med den adresse, reglen oversætter til, fordi en uoverensstemmelse betyder, at en anden regel matchede først. Én observeret strøm afgør mere end en side konfigurationslæsning.

Hold poolen, den oversatte adresse og interfacenavnet sammen i ændringsloggen. En regel, der er korrekt for én pool, oversætter den næste forkert.