Piirake OpenVPN SNAT reegel enne, kui see nginx’i rikub

Sama tüüpi hostilt saabub kaks tõrget. Esimeses autentivad kliendid ja ei jõua seejärel tunnelist kaugemale. Teises tõuseb VPN ja serveri enda veebileht lakkab vastamast, mis on murettekitavam, sest näeb välja nagu kõrvalkahju. Konteineripõhisel VPS-il taanduvad mõlemad tavaliselt samale lühikesele kontrollide loendile ja järjekord on oluline: kõigepealt seade, teiseks tõlge, kolmandaks ulatus.

Veenduge, et konteiner suudab luua tun-seadme

Miski muu ei loe, kui tunneliliidest ei saa olemas olla. Kontrollige, et /dev/net/tun on olemas ja et testseadme loomine õnnestub, sest paljud pakkujad keelavad konteinerites tun-i vaikimisi. Miski firewall-töö ei korva seadet, mida kunagi ei loodud.

Kui seade puudub, saavad selle lubada ainult host või pakkuja. Teine plaan on sageli odavam kui nädala kestev avatud tugilõim. Kinnitage seda enne, kui loete ühtki OpenVPN-i logirida. Muidu veedate õhtu reegleid häälestades, mis ei näe kunagi ühtki paketti.

Otsustage, mida MASQUERADE sellel liidesel teeb

Tavalisel virtuaalmasinal on tavaline väljundreegel POSTROUTING MASQUERADE pealiidesest. OpenVZ konteineris on nähtav seade sageli venet0, hosti hallatav virtuaalne liides, mitte marsruuditud võrgukaart, ja MASQUERADE ei käitu seal alati nii, nagu õpetused eeldavad.

Toimiv vorm on selgesõnaline tõlge aadressile, milleni kliendid juba jõuavad, kusjuures edastamine on lubatud mõlemas suunas. Serveri konfiguratsioonist pooli asendamine loeb sama palju kui aadressi asendamine. Lugege iga rida enne kleepimist.

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

Ilma edastusreegliteta toimub tõlge endiselt ja kernel keeldub endiselt edastamast. See kombinatsioon tekitab segadust tekitava oleku, kus NAT-reegli loendurid kasvavad, samal ajal kui klient ei saa midagi. Kaks FORWARD-rida peavad samuti asuma enne mis tahes laia drop-reeglit samas ahelas. Järjekord on konfiguratsiooni osa, mitte teostuse detail.

Piirake reegel ühe pooli ja ühe liidesega

Teisel sümptoomil on teine põhjus: POSTROUTING reegel, millel pole ei allika- ega väljundipiirangut. Selline reegel kirjutab ümber iga hostist väljuva paketi.

Teenused, mis sõltuvad algsest allikast, käituvad seejärel valesti. Kohaliku puhverserveri taga olev veebiserver võib lõpetada vastamise ja selle taaskäivitamine ei muuda midagi, sest reegel on endiselt teel. Mõjutatud on ka liiklus, mille host saadab omaenda avalikku aadressi, mistõttu tõrge võib näida DNS-i või sertifikaadi probleemina, mitte firewalli omandina. Reegel lisati peaaegu kindlasti esimese sümptoomi parandamiseks.

Lahendus on kitsendada vastavus tunnelipoolile ja väljundliidesele ning seejärel lisada üks reegel iga pooli kohta, selle asemel et üht reeglit mitme katmiseks laiendada.

Muutke reeglid püsivaks ja tehke kindlaks, kes veel neid omab

Käsitsi lisatud reeglid kaovad taaskäivitamisel, seega salvestage need iptables-save abil või haldake neid netfilter-persistent kaudu seal, kus see on paigaldatud. Kinnitage, et taastamine jookseb enne OpenVPN-i käivitumist. Seejärel käivitage üks kord meelega uuesti, selle asemel et avastada lünk intsidendi ajal.

Konteinerihostil kinnitage ka, et püsivusfail asub kirjutatavas konteineri salvestusruumis ja et pakkuja ei asenda filtreerimist alglaadimisel. Mõned platvormid haldavad poliitikat väljaspool konteinerit, kus kohalikke reegleid kas eiratakse või need võitlevad hosti enda reeglitega.

Kontrollige loenduritega ja ühe jäädvustatud vooluga

Ühendatud kliendist kontrollige avalikku aadressi, mida väline teenus teatab. Kui see kattub serveri aadressiga, tõlge töötab; kui mitte, väljub pakett teist teed või ei välju üldse. Seejärel proovige nii serveril majutatud teenust kui ka teenust avalikus internetis, sest need läbivad sama reeglistikku eri teid mööda.

Serveris lugege paketiloendureid NAT- ja FORWARD-reeglitel iptables -t nat -L -v -n abil ja jälgige üht voolu jäädvustuses. Kui kliendi aadress ilmub jäädvustusse ja vastust ei järgne, on lünk tagasiteel või pakkuja filtreerimises, mitte kliendiprofiilis. Võrrelge jäädvustatud allikat aadressiga, millele reegel tõlgib, sest lahknevus tähendab, et enne sobis mõni teine reegel. Üks vaadeldud vool lahendab rohkem kui lehekülg konfiguratsiooni lugemist.

Hoidke pool, tõlgitud aadress ja liidese nimi muudatuste kirjes koos. Ühe pooli jaoks õige reegel tõlgib järgmise valesti.