iptables: hayaang maabot ng mga kliyenteng VPN ang isang host lamang

Dalawang tiket sa suporta na mukhang walang kaugnayan ay may isang dahilan pala. Sa una, gusto ng administrator na tumanggap ang server ng koneksyon mula sa tunnel lamang; sa pangalawa, dapat maabot ng mga user ng VPN ang isang panloob na host at wala nang iba. Pareho ang mga patakarang ito sa FORWARD, at pareho silang karaniwang sinusubukan sa INPUT. Ang resulta ay mukhang firewall at kumikilos na parang pansamantalang pantakip.

Aling chain ang sumasagot sa tanong mo

Ang mga packet na ipinapadala ng kliyenteng VPN sa isang host sa LAN, o patuloy sa internet, ay ipinapasa ng kernel at sinusuri sa FORWARD. Ang INPUT at OUTPUT ay nakakakita lamang ng trapikong nagtatapos sa server mismo o nagmumula rito. Kaya ang pagtanggi sa lahat ng hindi dumarating sa tun0 ay nagpoprotekta sa sariling mga tagapakinig ng server, at tatapusin din nito ang iyong sesyon ng SSH maliban kung papayagan muna ang mga naitatag na daloy. Wala itong binabago sa kung saan pinapayagang pumunta ang mga kliyente.

Pangalanan muna ang tanong: sino ang makakaabot sa server, o saan makakapunta ang mga kliyente. Karamihan ng network ay nangangailangan ng dalawang sagot, sa magkaibang chain.

Una ang estado, pagkatapos ang pahintulot, pagkatapos ang pagtanggi

Gumagana lamang ang listahan ng pinapayagan kung ang partikular na pahintulot ay nasa itaas ng pangkalahatang pagtanggi at kung ang trapikong pabalik ay pinapayagan sa itaas ng dalawa. Ipasok ang mga tuntunin sa malinaw na posisyon, pagkatapos i-dump ang chain gamit ang iptables -S FORWARD upang makita ang pagkakasunod-sunod sa halip na ipagpalagay.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Dalawang detalye ang nagpapasya kung makakaligtas ito sa pakikipagtagpo sa tunay na trapiko. Kung walang tuntunin ng estado, ang mga sagot sa mga koneksyong pinayagan mo lang ay sinusuri mismo laban sa pagtanggi at itinatapon. Ang tuntuning LOG na walang hangganan ay maaaring punuin ang maliit na partisyon sa unang pag-scan, kaya magdagdag ng -m limit --limit 10/min bago magpatuloy sa pag-log. Ang REJECT ay agad na nagbabalik ng error, na mas magiliw habang inaayos mo ang listahan; ang DROP ay tahimik na nagtatapon, kaya bawat pagkakamali ay lumilitaw na timeout. Pumili ng isa nang sadya at isulat ang pinili sa talaan ng pagbabago.

Dapat gumagana na ang pagpapasa at NAT

Hindi mapapatunayan ng pag-filter na may landas. Tiyakin muna na ang kernel ay nagpapasa talaga, at gawing permanente ang setting na iyon sa halip na isang beses na utos sa shell. Ang filter ay ang huling sapin, hindi ang una.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Kung saan nararapat ang maskarada ay depende sa kung saan lumalabas ang mga kliyente. Kung lumalabas sila patungo sa malayong network sa pamamagitan ng tunnel, ang tuntuning NAT ay inilalagay sa interface na iyon at hindi sa interface ng WAN. Pagkatapos tingnan ang mga counter: kung hindi gumagalaw ang counter ng POSTROUTING habang tumataas ang bilang ng pagtanggap sa FORWARD, sira ang daan pabalik at maayos ang filter. Ang pagbasang iyon ay nagtitipid ng isang hapon sa muling pagsulat ng mga tuntuning hindi naman kailanman naging problema.

Ang block ng mail ay nasa katabing chain

Ang pagharang sa port 25 sa INPUT ay humihinto lamang sa mail na nakasentro sa server ng VPN. Ang kompromisong kliyente na nagpapadala ng mail sa tunnel ay ipinapasa, kaya dapat nasa FORWARD ang block sa tabi ng 465 at 587. Kung ang isang aplikasyon ay lehitimong nagpapasa ng mail, ilagay ang destinasyon at port nito sa itaas ng tuntuning iyon.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Hayaang tumakbo ang counter ng pagtanggi nang isang linggo bago higpitan ang anupaman. Ang bilang na humihinto sa pag-akyat ay ang lehitimong daloy na sinira mo lang.

Basahin itong muli, pagkatapos patunayan mula sa isang kliyente

Basahin ang set ng tuntunin ayon sa iniuulat ng kernel, hindi ayon sa isinulat ng iyong script. Magsimula sa iptables -S FORWARD, pagkatapos ang talahanayan ng NAT gamit ang iptables -t nat -L POSTROUTING -n -v, pagkatapos ang entry ng conntrack para sa daloy na sinusuri mo. Panatilihin ang utos ng rollback o naka-iskedyul na paglilinis habang tumatagal ang gawain. Kailangan ng bawat tawag ang -w, kung hindi ay magbabanggaan ang dalawang administrator sa kandado ng xtables. Wala sa mga ito ang opsyonal sa loob ng window ng pagbabago.

Tapusin sa pamamagitan ng pagsubok mula sa kliyenteng nasa loob ng pool at mula sa isang nasa labas nito. Ang tuntuning gumagana lamang mula sa makina kung saan mo ito tinaip ay hindi patakaran.