Apribokite OpenVPN SNAT taisyklę, kol ji nesugadino nginx

Du gedimai nuolat ateina iš to paties tipo hosto. Pirmuoju atveju klientai autentifikuojami ir tada nieko nepasiekia už tunelio. Antruoju atveju VPN pakyla ir pati serverio svetainė nustoja atsakinėti, o tai kelia didesnį nerimą, nes atrodo kaip šalutinė žala. Konteineriniame VPS abu paprastai sugrįžta prie to paties trumpo patikrų sąrašo, ir tvarka svarbi: pirmiausia įrenginys, antra vertimas, trečia apimtis.

Įsitikinkite, kad konteineris gali sukurti tun įrenginį

Niekas kitas nesvarbu, jei tunelio sąsaja negali egzistuoti. Patikrinkite, ar /dev/net/tun yra ir ar bandomojo įrenginio sukūrimas pavyksta, nes daugelis tiekėjų pagal nutylėjimą išjungia tun konteineriuose. Joks firewall darbas nekompensuoja įrenginio, kuris niekada nebuvo sukurtas.

Jei įrenginio nėra, jį įjungti gali tik hostas arba tiekėjas. Kitas planas dažnai pigesnis nei savaitę trunkanti atvira palaikymo tema. Patvirtinkite tai prieš perskaitydami nors vieną OpenVPN žurnalo eilutę. Priešingu atveju vakarą praleisite derindami taisykles, kurios niekada nepamatys paketo.

Nuspręskite, ką MASQUERADE daro šioje sąsajoje

Įprastoje virtualioje mašinoje įprasta išėjimo taisyklė yra POSTROUTING MASQUERADE iš pagrindinės sąsajos. OpenVZ konteineryje matomas įrenginys dažnai yra venet0, hosto valdoma virtuali sąsaja, o ne maršrutizuota tinklo kortelė, ir MASQUERADE ten ne visada elgiasi taip, kaip daro prielaidą mokymai.

Veikianti forma yra aiškus vertimas į adresą, kurį klientai jau pasiekia, leidžiant persiuntimą abiem kryptimis. Pool pakeitimas serverio konfigūracijoje yra toks pat svarbus kaip adreso pakeitimas. Perskaitykite kiekvieną eilutę prieš įklijuodami.

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

Be persiuntimo taisyklių vertimas vis tiek vyksta, o branduolys vis tiek atsisako persiųsti. Šis derinys sukuria painią būseną, kai NAT taisyklės skaitikliai auga, o klientas nieko negauna. Abi FORWARD eilutės taip pat turi stovėti prieš bet kurią plačią drop taisyklę toje pačioje grandinėje. Tvarka yra konfigūracijos dalis, o ne įgyvendinimo detalė.

Apribokite taisyklę vienu pool ir viena sąsaja

Antrasis simptomas turi kitą priežastį: POSTROUTING taisyklė be šaltinio ir be išėjimo apribojimo. Tokia taisyklė perrašo kiekvieną paketą, išeinantį iš hosto.

Paslaugos, priklausančios nuo pradinio šaltinio, tada elgiasi netinkamai. Web serveris už vietinio proxy gali nustoti atsakinėti, ir jo paleidimas iš naujo nieko nekeičia, nes taisyklė vis dar yra kelyje. Nukenčia ir srautas, kurį hostas siunčia savo viešuoju adresu, todėl gedimas gali atrodyti kaip DNS arba sertifikato problema, o ne firewall. Taisyklė beveik neabejotinai buvo pridėta pirmajam simptomui ištaisyti.

Sprendimas yra susiaurinti atitikimą iki tunelio pool ir išėjimo sąsajos, o tada pridėti po vieną taisyklę kiekvienam pool, o ne išplėsti vieną taisyklę keliems.

Padarykite taisykles ilgaamžes ir išsiaiškinkite, kas dar jas valdo

Rankiniu būdu pridėtos taisyklės dingsta po perkrovimo, todėl išsaugokite jas su iptables-save arba valdykite per netfilter-persistent ten, kur jis įdiegtas. Patvirtinkite, kad atkūrimas vykdomas prieš OpenVPN paleidimą. Tada vieną kartą tyčia perkraukite, užuot aptikę spragą incidento metu.

Konteinerių hoste taip pat patvirtinkite, kad ilgaamžiškumo failas yra rašomame konteinerio saugykloje ir kad tiekėjas nepakeičia filtravimo paleidimo metu. Kai kurios platformos valdo politiką už konteinerio ribų, kur vietinės taisyklės arba ignoruojamos, arba konfliktuoja su paties hosto taisyklėmis.

Patikrinkite skaitikliais ir vienu užfiksuotu srautu

Iš prisijungusio kliento patikrinkite viešąjį adresą, kurį praneša išorinė paslauga. Jei jis sutampa su serverio adresu, vertimas veikia; jei ne, paketas išeina kitu keliu arba visai neišeina. Tada išbandykite ir serverio talpinamą paslaugą, ir tą, kuri yra viešajame internete, nes jos eina skirtingais keliais per tą patį taisyklių rinkinį.

Serveryje skaitykite paketų skaitiklius NAT ir FORWARD taisyklėse su iptables -t nat -L -v -n ir stebėkite vieną srautą fiksavime. Jei kliento adresas atsiranda fiksavime ir atsakymas neseka, spraga yra grįžimo kelyje arba tiekėjo filtravime, o ne kliento profilyje. Palyginkite užfiksuotą šaltinį su adresu, į kurį taisyklė verčia, nes neatitikimas reiškia, kad pirmiau atitiko kita taisyklė. Vienas stebėtas srautas išsprendžia daugiau nei puslapis konfigūracijos skaitymo.

Laikykite pool, išverstą adresą ir sąsajos pavadinimą kartu pakeitimų įraše. Taisyklė, teisinga vienam pool, neteisingai verčia kitą.