Begrens OpenVPN SNAT-regelen før den ødelegger nginx

To feil kommer stadig fra samme slags vert. I den første autentiserer klientene seg og når deretter ingenting utenfor tunnelen. I den andre kommer VPN-en opp og vertens eget nettsted slutter å svare, noe som er det mest alarmerende fordi det ser ut som følgeskader. På en containerbasert VPS fører begge vanligvis tilbake til den samme korte listen med kontroller, og rekkefølgen er viktig: enheten først, oversettelsen deretter, omfanget til slutt.

Bekreft at containeren kan opprette en tun-enhet

Ingenting annet betyr noe hvis tunnelgrensesnittet ikke kan eksistere. Kontroller at /dev/net/tun er til stede og at opprettelsen av en testenhet lykkes, fordi mange leverandører deaktiverer tun i containere som standard. Ingen firewall-arbeid kompenserer for en enhet som aldri ble opprettet.

Hvis enheten mangler, kan bare verten eller leverandøren aktivere den. En annen plan er ofte billigere enn en åpen støttetråd som varer en uke. Bekreft dette før du leser en eneste linje av OpenVPN-loggen. Ellers bruker du kvelden på å finjustere regler som aldri vil se en pakke.

Bestem hva MASQUERADE gjør på dette grensesnittet

På en vanlig virtuell maskin er den vanlige utgangsregelen POSTROUTING MASQUERADE ut av hovedgrensesnittet. I en OpenVZ-container er den synlige enheten ofte venet0, et vertsstyrt virtuelt grensesnitt fremfor et rutet nettverkskort, og MASQUERADE oppfører seg ikke alltid der slik veiledninger antar.

Den brukbare formen er eksplisitt oversettelse til adressen klientene allerede når, med videresending tillatt i begge retninger. Å erstatte poolen fra serverkonfigurasjonen betyr like mye som å erstatte adressen. Les hver linje før du limer den inn.

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

Uten videresendingsreglene skjer oversettelsen fortsatt, og kjernen nekter fortsatt å videresende. Den kombinasjonen skaper den forvirrende tilstanden der tellerne på NAT-regelen stiger mens klienten ikke mottar noe. De to FORWARD-linjene må også stå foran enhver bred drop-regel i samme kjede. Rekkefølge er en del av konfigurasjonen, ikke en implementeringsdetalj.

Begrens regelen til én pool og ett grensesnitt

Det andre symptomet har en annen årsak: en POSTROUTING-regel uten både kilde- og utgangsbegrensning. En slik regel skriver om hver pakke som forlater verten.

Tjenester som avhenger av den opprinnelige kilden oppfører seg da feil. En webserver bak en lokal proxy kan slutte å svare, og en omstart endrer ingenting fordi regelen fortsatt er i veien. Også trafikken verten sender til sin egen offentlige adresse påvirkes, og derfor kan feilen se ut som et DNS- eller sertifikatproblem snarere enn et firewall-problem. Regelen ble nesten helt sikkert lagt til for å rette det første symptomet.

Løsningen er å snevre inn treffet til tunnelpoolen og utgangsgrensesnittet, og deretter legge til én regel per pool i stedet for å utvide en enkelt regel til å dekke flere.

Gjør reglene varige og finn ut hvem andre som eier dem

Regler lagt til for hånd forsvinner ved omstart, så lagre dem med iptables-save eller administrer dem via netfilter-persistent der det er installert. Bekreft at gjenopprettingen kjører før OpenVPN starter. Start deretter én gang med vilje på nytt i stedet for å oppdage hullet under en hendelse.

På en containervert må du også bekrefte at varighetsfilen ligger i skrivbar containerlagring og at leverandøren ikke erstatter filtreringen ved oppstart. Noen plattformer administrerer policy utenfor containeren, der lokale regler enten ignoreres eller kjemper mot vertens egne.

Verifiser med tellere og én fanget strøm

Fra en tilkoblet klient, kontroller den offentlige adressen en ekstern tjeneste rapporterer. Hvis den samsvarer med serverens adresse, virker oversettelsen; hvis ikke, forlater pakken via en annen vei eller forlater ikke i det hele tatt. Prøv deretter både en tjeneste på serveren og en på det åpne internettet, fordi de tar ulike veier gjennom det samme regelsettet.

På serveren, les pakketellerne på NAT- og FORWARD-reglene med iptables -t nat -L -v -n og følg én strøm i en opptak. Hvis klientens adresse vises i opptaket og ingen svar følger, er hullet på returveien eller i leverandørens filtrering, ikke i klientprofilen. Sammenlign den fangede kilden med adressen regelen oversetter til, fordi et avvik betyr at en annen regel traff først. Én observert strøm avgjør mer enn en side med konfigurasjonslesing.

Hold poolen, den oversatte adressen og grensesnittnavnet sammen i endringsloggen. En regel som er riktig for én pool, oversetter den neste feil.