Limitahan ang SNAT rule ng OpenVPN bago nito sirain ang nginx

Dalawang pagkabigo ang palaging dumarating mula sa parehong uri ng host. Sa una, nagpapatunay ang mga kliyente at pagkatapos ay walang naaabot na anuman lampas sa tunnel. Sa pangalawa, umaangat ang VPN at tumitigil sa pagsagot ang sariling website ng server, na siyang mas nakakaalarma dahil mukhang collateral damage. Sa VPS na nakabatay sa container, kadalasang bumabalik ang dalawa sa parehong maikling listahan ng mga pagsusuri, at mahalaga ang pagkakasunod-sunod: device muna, pagsasalin pangalawa, saklaw pangatlo.

Tiyakin na kayang gumawa ng tun device ang container

Wala nang ibang mahalaga kung hindi maaaring umiral ang tunnel interface. Suriin na naroon ang /dev/net/tun at nagtatagumpay ang paggawa ng test device, dahil maraming provider ang nagpapawalang-bisa ng tun sa loob ng container bilang default. Walang gawaing firewall ang makakabawi sa device na hindi kailanman ginawa.

Kung wala ang device, tanging ang host o provider ang makakapag-enable nito. Kadalasang mas mura ang ibang plano kaysa sa bukas na support thread na tumatagal ng isang linggo. Tiyakin ito bago magbasa ng kahit isang linya ng OpenVPN log. Kung hindi, gugugulin mo ang gabi sa pag-tune ng mga patakarang hindi kailanman makakakita ng packet.

Magpasya kung ano ang ginagawa ng MASQUERADE sa interface na ito

Sa ordinaryong virtual machine, ang karaniwang egress rule ay POSTROUTING MASQUERADE mula sa pangunahing interface. Sa container na OpenVZ, ang nakikitang device ay kadalasang venet0, isang virtual interface na pinamamahalaan ng host at hindi isang routed NIC, at hindi laging kumikilos ang MASQUERADE doon gaya ng inaakala ng mga tutorial.

Ang magagamit na anyo ay tahasang pagsasalin patungo sa address na naaabot na ng mga kliyente, na pinapayagan ang forwarding sa dalawang direksyon. Ang pagpapalit ng pool mula sa configuration ng server ay kasinghalaga ng pagpapalit ng address. Basahin ang bawat linya bago ito i-paste.

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

Kung wala ang mga forwarding rule, nangyayari pa rin ang pagsasalin at tumatanggi pa rin ang kernel na mag-forward. Ang kombinasyong iyon ay lumilikha ng nakakalitong kalagayan kung saan tumataas ang mga counter sa NAT rule habang walang natatanggap ang kliyente. Ang dalawang FORWARD na linya ay dapat ding mauna sa anumang malawak na drop rule sa parehong chain. Bahagi ng configuration ang pagkakasunod-sunod, hindi detalye ng implementasyon.

Limitahan ang patakaran sa isang pool at isang interface

Ang pangalawang sintomas ay may ibang dahilan: isang POSTROUTING rule na walang paghihigpit sa source o sa output. Ang gayong patakaran ay nagre-rewrite ng bawat packet na lumalabas sa host.

Ang mga serbisyong umaasa sa orihinal na source ay nagmimistulang mali. Maaaring tumigil sa pagsagot ang isang web server sa likod ng lokal na proxy, at walang nababago ang pag-restart dahil nasa landas pa rin ang patakaran. Naapektuhan din ang trapikong ipinapadala ng host sa sarili nitong pampublikong address, kaya maaaring magmukhang problema sa DNS o certificate ang pagkabigo kaysa sa firewall. Halos tiyak na idinagdag ang patakaran para ayusin ang unang sintomas.

Ang solusyon ay paghigpitan ang pagtutugma sa tunnel pool at egress interface, pagkatapos magdagdag ng isang patakaran bawat pool sa halip na palawakin ang isang patakaran para masakop ang marami.

Gawing permanente ang mga patakaran at alamin kung sino pa ang nagmamay-ari sa mga ito

Ang mga patakarang idinagdag sa kamay ay nawawala sa reboot, kaya i-save ang mga ito gamit ang iptables-save o pamahalaan ang mga ito sa pamamagitan ng netfilter-persistent kung saan ito naka-install. Tiyakin na tumatakbo ang pag-restore bago magsimula ang OpenVPN. Pagkatapos ay sadyang mag-reboot nang isang beses sa halip na matuklasan ang puwang habang may insidente.

Sa host ng container, tiyakin din na ang persistence file ay nasa nasusulat na container storage at hindi pinapalitan ng provider ang filtering sa boot. Ang ilang platform ay namamahala ng patakaran sa labas ng container, kung saan ang mga lokal na patakaran ay binabalewala o nakikipagbanggaan sa sarili ng host.

I-verify gamit ang mga counter at isang nakuhang daloy

Mula sa konektadong kliyente, suriin ang pampublikong address na iniuulat ng panlabas na serbisyo. Kung tumutugma ito sa address ng server, gumagana ang pagsasalin; kung hindi, lumalabas ang packet sa ibang landas o hindi lumalabas talaga. Pagkatapos ay subukan ang parehong serbisyong naka-host sa server at isa sa pampublikong internet, dahil magkaibang landas ang tinatahak ng mga ito sa parehong set ng patakaran.

Sa server, basahin ang mga counter ng packet sa NAT at FORWARD rules gamit ang iptables -t nat -L -v -n at obserbahan ang isang daloy sa isang capture. Kung lumilitaw ang address ng kliyente sa capture at walang sumusunod na sagot, nasa return path o sa filtering ng provider ang puwang, hindi sa profile ng kliyente. Ihambing ang nakuhang source sa address na isinasalin ng patakaran, dahil ang hindi pagtutugma ay nangangahulugang ibang patakaran ang unang tumugma. Isang naobserbahang daloy ang lumulutas ng higit pa sa isang pahina ng pagbabasa ng configuration.

Panatilihing magkasama ang pool, ang isinaling address at ang pangalan ng interface sa record ng pagbabago. Ang patakarang tama para sa isang pool ay mali ang pagsasalin sa susunod.