Avgrens OpenVPN SNAT-regelen før ho øydelegg nginx

To feil kjem stadig frå same slags vert. I den fyrste autentiserer klientane seg og når deretter ingenting utanfor tunnelen. I den andre kjem VPN-en opp og nettstaden til verten sjølv sluttar å svare, noko som er det mest alarmerande fordi det ser ut som følgjeskadar. På ein containerbasert VPS fører begge vanlegvis tilbake til den same korte lista med kontrollar, og rekkjefølgja er viktig: eininga fyrst, omsetjinga deretter, omfanget til slutt.

Stadfest at containeren kan opprette ei tun-eining

Ingenting anna betyr noko om tunnelgrensesnittet ikkje kan eksistere. Kontroller at /dev/net/tun er til stades og at opprettinga av ei testeining lukkast, fordi mange leverandørar slår av tun i containarar som standard. Ingen firewall-arbeid kompenserer for ei eining som aldri vart oppretta.

Om eininga manglar, kan berre verten eller leverandøren slå ho på. Ein annan plan er ofte billegare enn ein open støttetråd som varer ei veke. Stadfest dette før du les ei einaste linje av OpenVPN-loggen. Elles brukar du kvelden på å finjustere reglar som aldri vil sjå ein pakke.

Avgjer kva MASQUERADE gjer på dette grensesnittet

På ein vanleg virtuell maskin er den vanlege utgangsregelen POSTROUTING MASQUERADE ut av hovudgrensesnittet. I ein OpenVZ-container er den synlege eininga ofte venet0, eit vertsstyrt virtuelt grensesnitt framfor eit ruta nettverkskort, og MASQUERADE oppfører seg ikkje alltid der slik rettleiarar føreset.

Den brukbare forma er eksplisitt omsetjing til adressa klientane allereie når, med vidaresending tillaten i begge retningar. Å byte ut poolen frå serverkonfigurasjonen betyr like mykje som å byte ut adressa. Les kvar linje før du limer ho 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

Utan vidaresendingsreglane skjer omsetjinga framleis, og kjernen nektar framleis å vidaresende. Den kombinasjonen skapar den forvirrande tilstanden der teljarane på NAT-regelen stig medan klienten ikkje mottar noko. Dei to FORWARD-linjene må også stå føre kvar brei drop-regel i same kjede. Rekkjefølgje er ein del av konfigurasjonen, ikkje ein implementasjonsdetalj.

Avgrens regelen til éin pool og eitt grensesnitt

Det andre symptomet har ei anna årsak: ein POSTROUTING-regel utan både kjelde- og utgangsavgrensing. Ein slik regel skriv om kvar pakke som forlèt verten.

Tenester som er avhengige av den opphavlege kjelda, oppfører seg då feil. Ein webserver bak ein lokal proxy kan slutte å svare, og ein omstart endrar ingenting fordi regelen framleis er i vegen. Også trafikken verten sender til si eiga offentlege adresse blir påverka, og difor kan feilen sjå ut som eit DNS- eller sertifikatproblem snarare enn eit firewall-problem. Regelen vart nesten heilt sikkert lagt til for å rette det fyrste symptomet.

Løysinga er å snevre inn treffet til tunnelpoolen og utgangsgrensesnittet, og deretter leggje til éin regel per pool i staden for å utvide ein enkelt regel til å dekkje fleire.

Gjer reglane varige og finn ut kven andre som eig dei

Reglar lagde til for hand forsvinn ved omstart, så lagre dei med iptables-save eller administrer dei via netfilter-persistent der det er installert. Stadfest at gjenopprettinga køyrer før OpenVPN startar. Start deretter ein gong med vilje på nytt i staden for å oppdage holet under ei hending.

På ein containervert må du også stadfeste at varigheitsfila ligg i skrivbar containerlagring og at leverandøren ikkje erstattar filtreringa ved oppstart. Nokre plattformer administrerer policy utanfor containeren, der lokale reglar anten blir ignorerte eller kjempar mot verten sine eigne.

Verifiser med teljarar og éin fanga straum

Frå ein tilkopla klient, kontroller den offentlege adressa ein ekstern teneste rapporterer. Om ho samsvarar med adressa til serveren, verkar omsetjinga; om ikkje, forlèt pakken via ein annan veg eller forlèt han ikkje i det heile. Prøv deretter både ei teneste på serveren og ei på det opne internettet, fordi dei tek ulike vegar gjennom det same regelsettet.

På serveren, les pakketeljarane på NAT- og FORWARD-reglane med iptables -t nat -L -v -n og følg éin straum i eit opptak. Om adressa til klienten viser seg i opptaket og ingen svar følgjer, er holet på returvegen eller i filtreringa til leverandøren, ikkje i klientprofilen. Samanlikn den fanga kjelda med adressa regelen omset til, fordi eit avvik betyr at ein annan regel trefte først. Éin observert straum avgjer meir enn ei side med konfigurasjonslesing.

Hald poolen, den omsette adressa og grensesnittnamnet saman i endringsloggen. Ein regel som er riktig for éin pool, omset den neste feil.