Limigu la OpenVPN SNAT-regulon antaŭ ol ĝi rompos nginx

Du fiaskoj daŭre alvenas de la sama speco de gastiganto. En la unua, klientoj aŭtentiĝas kaj poste atingas nenion preter la tunelo. En la dua, la VPN ekfunkcias kaj la propra retejo de la servilo ĉesas respondi, kio estas la pli alarmiga ĉar ĝi aspektas kiel flanka damaĝo. Sur container-bazita VPS ambaŭ kutime reiras al la sama mallonga listo de kontroloj, kaj la ordo gravas: unue la aparato, due la traduko, trie la amplekso.

Konfirmu, ke la container povas krei tun-aparaton

Nenio alia gravas se la tunela interfaco ne povas ekzisti. Kontrolu, ke /dev/net/tun ĉeestas kaj ke kreado de testa aparato sukcesas, ĉar multaj provizantoj defaŭlte malŝaltas tun en container’oj. Neniu kvanto de firewall-laboro kompensas aparaton, kiu neniam estis kreita.

Se la aparato mankas, nur la gastiganto aŭ la provizanto povas ebligi ĝin. Alia plano ofte malpli kostas ol malfermita subtena fadeno, kiu daŭras semajnon. Konfirmu tion antaŭ ol legi eĉ unu linion de la OpenVPN-protokolo. Alie vi pasigos la vesperon agordante regulojn, kiuj neniam vidos paketon.

Decidu, kion MASQUERADE faras sur ĉi tiu interfaco

Sur ordinara virtuala maŝino la kutima elira regulo estas POSTROUTING MASQUERADE el la ĉefa interfaco. En OpenVZ-container la videbla aparato ofte estas venet0, gastiganto-administrata virtuala interfaco anstataŭ enkursigita retkarto, kaj MASQUERADE ne ĉiam kondutas tie kiel lerniloj supozas.

La farebla formo estas eksplicita traduko al la adreso, kiun klientoj jam atingas, kun plusendo permesita en ambaŭ direktoj. Anstataŭigi la pool el la servila agordo same gravas kiel anstataŭigi la adreson. Legu ĉiun linion antaŭ ol enmeti ĝin.

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

Sen la plusendaj reguloj la traduko ankoraŭ okazas kaj la kerno ankoraŭ rifuzas plusendi. Tiu kombinaĵo kreas la konfuzan staton, en kiu la nombriloj sur la NAT-regulo supreniras dum la kliento ricevas nenion. La du FORWARD-linioj ankaŭ devas stari antaŭ iu ajn larĝa drop-regulo en la sama ĉeno. Ordo estas parto de la agordo, ne detalo de efektivigo.

Limigu la regulon al unu pool kaj unu interfaco

La dua simptomo havas alian kaŭzon: POSTROUTING-regulo sen limigo de fonto nek de eligo. Tia regulo reskribas ĉiun paketon, kiu forlasas la gastiganton.

Servoj, kiuj dependas de la originala fonto, tiam malbone kondutas. Reteja servilo malantaŭ loka prokuro povas ĉesi respondi, kaj restartigi ĝin nenion ŝanĝas ĉar la regulo ankoraŭ estas en la vojo. Ankaŭ la trafiko, kiun la gastiganto sendas al sia propra publika adreso, estas tuŝita, kaj tial la fiasko povas aspekti kiel problemo de DNS aŭ atestilo anstataŭ de firewall. La regulo preskaŭ certe estis aldonita por ripari la unuan simptomon.

La solvo estas mallarĝigi la kongruon al la tunela pool kaj la elira interfaco, poste aldoni unu regulon por pool anstataŭ larĝigi unu regulon por kovri plurajn.

Daŭrigu la regulojn kaj malkovru, kiu alia posedas ilin

Mane aldonitaj reguloj malaperas ĉe restartigo, do konservu ilin per iptables-save aŭ administru ilin per netfilter-persistent kie ĝi estas instalita. Konfirmu, ke la restarigo kuras antaŭ ol OpenVPN ekas. Poste restartigu unufoje intence anstataŭ malkovri la breĉon dum okazaĵo.

Sur container-gastiganto ankaŭ konfirmu, ke la daŭreca dosiero loĝas en skribebla container-stokado kaj ke la provizanto ne anstataŭigas filtradon ĉe ŝargo. Iuj platformoj administras politikon ekster la container, kie lokaj reguloj aŭ estas ignorataj aŭ luktas kun la propraj de la gastiganto.

Kontrolu per nombriloj kaj unu kaptita fluo

De konektita kliento, kontrolu la publikan adreson, kiun raportas ekstera servo. Se ĝi kongruas kun la adreso de la servilo, la traduko funkcias; se ne, la paketo forlasas per alia vojo aŭ tute ne forlasas. Poste provu kaj servon gastigatan sur la servilo kaj unu en la publika interreto, ĉar ili prenas malsamajn vojojn tra la sama aro da reguloj.

Sur la servilo, legu la pakaĵnombrilojn sur la NAT kaj FORWARD reguloj per iptables -t nat -L -v -n kaj observu unu fluon en kaptaĵo. Se la adreso de la kliento aperas en la kaptaĵo kaj neniu respondo sekvas, la breĉo estas sur la revena vojo aŭ en filtrado de la provizanto, ne en la klienta profilo. Komparu la kaptitan fonton kun la adreso, al kiu la regulo tradukas, ĉar malkongruo signifas, ke alia regulo kongruis unue. Unu observata fluo solvas pli ol paĝo da agorda legado.

Tenu la pool, la tradukitan adreson kaj la interfacan nomon kune en la ŝanĝa registro. Regulo ĝusta por unu pool malĝuste tradukas la sekvan.