Firewall ng VPS: buksan lang ang port ng VPN, pagkatapos patunayan
Isang port ang dapat manatiling pampubliko, kung hindi ay walang kliyenteng makakakonekta. Tanggihan ang iba, ihiwalay ang pagpapasa mula sa input, at mag-iwan ng daraanan ng pagbawi na sinubukan mo nang maaga.
Ang firewall na pinapayagan lamang ang port ng VPN ay hindi isang tuntunin. Ito ay tatlong magkakahiwalay na desisyon na nagkataong tumutukoy sa parehong numero ng port: ang input chain ang nagpapasya kung ano ang makakarating sa lokal na proseso, ang forward chain ang nagpapasya kung ano ang makakadaan sa host sa ngalan ng mga kliyente ng tunnel, at ang NAT table ang muling nagsusulat ng source address palabas. Magkamali ka sa isa at bihirang maging malinis na pagkaantala ang resulta. Makakakuha ka ng host na tumatanggap ng kliyente ngunit walang niloload, o host na mukhang sarado hanggang may magbasa ng pagkakasunod-sunod ng mga chain.
Ang nag-iisang port na hindi maisasara
Kailangang tumanggap ang tagapakinig ng VPN ng koneksyon mula sa mga address na hindi mo mahulaan, kaya ito ay pampublikong serbisyo ayon sa depinisyon. Ito ang tanging pagbubukod na pinagbatayan ng disenyo: isang UDP port para sa OpenVPN, isang UDP port para sa WireGuard, isang TCP port para sa SSL VPN. Lahat ng iba ay nasa likod ng tunnel, ibig sabihin, ang mga serbisyo ng aplikasyon ay dapat magbigkis sa address ng tunnel o sa loopback, hindi sa lahat ng interface.
Ngunit ang pagbigkis ay hindi pagpapatupad. Ang prosesong nakabigkis sa 0.0.0.0 ay maaabot lamang kung pinapayagan ito ng tuntunin, at ang default na patakaran ay ang kapalit para sa trapikong walang tumugmang tuntunin, hindi ang tuntuning namamahala sa port. Ang pagtanggap na inilagay sa itaas ng iyong pagtanggi ay pagtanggap pa rin, at ang paglipat ng serbisyo palayo sa pampublikong address ay hiwalay na pagbuti, hindi kapalit ng chain.
Input, pagpapasa at NAT ay sumasagot sa magkakaibang tanong
Ang input traffic ay para sa host mismo, kaya doon nakatira ang tagapakinig ng VPN at ang administratibong daraanan. Ang forward traffic ay dumadaan sa host, at kailangan ito ng mga kliyente ng tunnel kasama ng net.ipv4.ip_forward=1. Ang klasikong kalahating sirang configuration ay pinapayagan ang palabas na daloy at nakakalimutan ang pabalik na direksyon, kaya natatapos ng kliyente ang handshake at pagkatapos ay walang niloload; ang tuntunin ng conntrack para sa established at related na trapiko ang sumasaklaw sa direksyong iyon.
Ang NAT ang ikatlong tanong. Kung walang muling pagsulat sa postrouting, lumalabas ang mga naipasang packet na may pribadong source ng tunnel at itinatapon sa itaas, dahil walang network sa kabila ng host ang marunong mag-ruta ng pool pabalik. Ang source prefix sa tuntuning iyon ay dapat tumugma sa pool ng VPN, hindi sa sariling address ng host, at ganoon din sa tuntunin ng pagpapasa na nagbabanggit ng subnet ng mga kliyente.
Ang IPv6 ay ikalawang patakaran, hindi huling-isip. Ang host na may mahigpit na IPv4 chain at bukas na patakaran sa ip6tables ay walang isinara; naaabot pa rin ang mga serbisyo sa kabilang pamilya. O kopyahin ang set ng tuntunin gamit ang ip6tables, o sadyang patayin ang IPv6 sa pampublikong interface, at isulat kung alin ang pinili mo.
Batayan na mababasa sa isang pagdaan
Magsimula sa pagtanggi, pagkatapos ay idagdag lamang ang kailangan ng host. Una ang loopback at mga tugon, pagkatapos ang administratibong daraanan, pagkatapos ang tagapakinig ng tunnel, pagkatapos ang patakaran ng pagpapasa para sa mga kliyente:
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADEAng mga pangalan ng interface, port at pool ay mga placeholder; basahin ang mga ito mula sa server sa halip na kopyahin. Ang pag-save ng resulta ay kasinghalaga ng pagsulat nito, dahil ang set ng tuntuning nabubuhay lamang sa memorya ay nawawala sa susunod na reboot at tahimik na muling binubuksan ang host. Gawin itong permanente sa pamamagitan ng mekanismo ng distribusyon, at magtabi ng kopya sa labas ng makina para sa araw na hindi mag-boot ang makina.
Isara ang huling port nang hindi nawawala ang host
May patibong sa disenyo. Kung ang SSH ay umiiral lamang sa pamamagitan ng tunnel, dadalhin ng nabigong serbisyo ng VPN ang SSH, at ang tanging daan pabalik ay maaaring isang console na hindi mo kailanman binuksan. Bago isara ang huling pampublikong port, tiyakin na umiiral ang console na iyon at talagang magagamit mo ito, o panatilihin ang isang makitid na administratibong daraanan na hindi umaasa sa tunnel: SSH mula sa fixed na address, mga key lamang, patay ang authentication sa password.
Ilapat ang pagbabago mula sa session na naitatag na, hindi sa koneksyong sasalaan mo. Mag-iskedyul ng rollback upang mag-expire ang pagkakamali sa halip na maging permanente, halimbawa isang gawain ng systemd-run --on-active=10min na nagbabalik ng nakaraang set ng tuntunin, at panatilihing bukas ang ikalawang session ng SSH habang sinusubukan ang una. Pagkatapos ay tiyakin na talagang nagsisimula ang gawain ng rollback, dahil ang pagbawing hindi nasubukan ay katulad ng walang pagbawi.
Patunayan ang daraanan, hindi ang script
Basahin ang mga na-load na tuntunin, hindi ang file na dapat sanang nag-load sa mga ito. Mula sa awtorisadong panlabas na host, tiyakin na tanging ang nilalayong port ang tumutugon; mula sa loob ng tunnel, tiyakin na naaabot ang mga serbisyong nais mong i-publish. Ang default-deny na patakaran na humaharang din sa trapiko ng tunnel ay mukhang katulad ng gumaganang lockdown hanggang may sumubok na gamitin ito.
iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr showItala ang pinapayagang port, pool ng kliyente, interface ng tunnel, administratibong source at pamamaraan ng console sa tabi ng configuration. Ang susunod na pagbabago sa pool o pangalan ng interface ay dapat tumugma sa filter at sa tuntunin ng NAT, kung hindi ay babalik ang host sa kalahating bukas na kalagayan nang walang makakapansin.
Ang isang ugali ay mas mahalaga kaysa sa set ng tuntunin: pagkatapos ng bawat pagbabago, patunayan ang daraanan ng pagpapasa sa pamamagitan ng kahilingan ng kliyente at ang daraanan ng pagbawi sa pamamagitan ng ikalawang session. Ang lockdown na hindi mo ginamit ay isang palagay lamang.