Limitahan ang isang OpenVPN Gateway sa Isang LAN gamit ang mga Tuntunin ng UFW

Magpasya sa permiso bago mo buksan ang isang file ng firewall: ang mga awtentikadong kliyente ay maaaring magbukas ng mga koneksyon patungo sa isang partikular na subnet, at dapat tanggihan ng gateway ang bawat iba pang daanan ng transit kahit na mag-install ang kliyente ng karagdagang mga ruta. Ang pangungusap na iyon ang disenyo, at bawat tuntunin sa ibaba ay umiiral upang ipatupad ito. Anumang mas malawak, tulad ng buong pribadong espasyo ng address, paglabas sa internet sa tunnel o trapikong peer-to-peer, ay ibang disenyo na nangangailangan ng sariling desisyon. Ang mga tuntunin ay sadyang nakakabagot rin, dahil ang matalinong firewall ay ang hindi kayang i-audit ng kahit sino mamaya.

Isulat muna ang topolohiya at ang permiso

Gumagamit ang halimbawa ng Community OpenVPN server na may TUN device sa user space na tinatawag na tun0, pool ng kliyente 10.77.0.0/24, at isang nakakabit na subnet 192.168.60.0/24 sa lan0. Gumagana na ang pagpapasa ng IPv4 at mayroon na ring ruta pabalik sa pool ang LAN, kaya wala rito ang umaasa sa pagsasalin sa pagitan ng dalawa.

Ang UFW ang may-ari ng firewall sa host na ito, at walang set ng tuntunin ng container o hiwalay na talahanayan ng nftables ang maaaring maglagay ng mas maagang landas ng pagtanggap. Ang shortcut ng pagbaba ng daloy na lumalampas sa filter ay gagawing palamuti lamang ang mga kadena ng bantay, kaya tiyakin na wala sa mga ito ang aktibo. Iwanang naka-disable ang sariling client-to-client na pagpapasa ng OpenVPN, dahil ang trapikong peer-to-peer na hindi kailanman tumatawid sa filter ng operating system ay hindi kayang limitahan nito. Ang panlabas na tagapakinig at ang mga tuntunin sa administrasyon ay mananatili kung ano sila, dahil pinamamahalaan ng pagbabagong ito ang na-decrypt na trapiko ng tunnel sa halip na palitan ang firewall.

Ilagay ang mga bantay bago ang maagang pagtanggap ng UFW

Ang permiso sa ruta na sinusundan ng pagtanggi ay hindi sapat para sa mahigpit na hangganan. Ang mga stock na before na tuntunin ay tumatanggap ng naitatag na trapiko at ilang ICMP bago pa man isaalang-alang ang anumang tuntunin ng gumagamit, kaya ang daloy na pinayagan noong nakaraang linggo ay maaaring manatiling labas ng bagong paghihigpit sa destinasyon dahil may estado pa rin ito. Mag-backup ng mga file ng UFW at panatilihing bukas ang isang console sa labas ng banda bago mag-edit.

Sa seksyon na *filter ng file na /etc/ufw/before.rules, magpahayag ng dalawang kadena sa tabi ng mga umiiral na deklarasyon at bago ang anumang linya ng tuntunin.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Kaagad pagkatapos ng mga deklarasyon, at bago ang mga permiso sa input at pagpapasa, tumalon sa mga ito at tukuyin kung ano ang pinapayagan nila.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Panatilihin ang natitirang bahagi ng seksyon at ang linya nito na COMMIT. Ang pag-paste ng pangalawang talahanayan ng filter o pagbura ng mga walang kaugnayang tuntunin ang paraan ng pagiging outage ng isang pagbabago sa firewall, at ang file ay isang reboot lang ang layo mula sa pagiging tanging kopyang mahalaga.

Basahin kung ano ang pinapayagan at tinatanggihan ng bawat bantay

Ang unang kadena ay nagpapatuloy sa pagproseso lamang kapag ang pinagmulan ay nasa pool, ang destinasyon ay ang nag-iisang subnet, ang interface ng labasan ay ang LAN at ang packet ay naglalakbay sa orihinal na direksyon ng daloy nito. Ang lahat ng iba pang dumarating mula sa tunnel ay itinatapon, kasama ang pinagmulang labas ng pool at anumang destinasyon na lampas sa pinapayagang subnet.

Ang packet na peer-to-peer ay pumapasok at lumalabas sa tun0, kaya nabigo ito sa pagsubok ng interface ng LAN bago pa man maabot ang isang pagsusuri ng destinasyon. Nabibigo rin sa pagsubok ng direksyon ng sagot ang mga bagong koneksyon mula sa LAN patungo sa mga kliyente, na nagsasara ng baligtad na landas ng callback bilang default.

Ang target na RETURN ay nagpapanatili sa ordinaryong patakaran ng UFW na gumagana. Ang mga kadenang ito ay nag-filter, at ang permiso sa rutang idaragdag mo pagkatapos ay nagpapasya pa rin kung tatanggapin ang isang nakaligtas na packet. Ang paghihiwalay na iyon ang nagpapahintulot sa iyo na baguhin sa ibang pagkakataon ang pinapayagang subnet sa isang lugar lamang. Kung direktang tinanggap ng mga bantay ang mga packet, ang bawat tuntunin sa hinaharap ay kailangang idagdag nang dalawang beses.

Pahintulutan ang subnet at isara ang mga pintuan sa gilid

I-preview muna ang permiso sa ruta, pagkatapos ay alisin ang watawat ng preview upang ilapat ito: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Pagkatapos, suriin ang pagkakasunod-sunod ng mga tuntunin ng gumagamit, dahil ang mas maagang pagtanggi ay nananalo pa rin sa mas huling permiso. Ang permiso para sa buong subnet ay maling hugis din kapag tanging ang HTTPS port ng isang host ang dapat maabot.

Pansinin ang ginagawa ng pagtatapon ng input: hindi maabot ng mga kliyente ng tunnel ang anumang serbisyo sa gateway mismo, kasama ang isang tagapakinig ng DNS na nakatali sa address nito sa LAN. Ang pagho-host ng DNS doon ay nangangailangan ng sadyang pagbubukod bago ang pagtatapon at isang binagong kontrata ng permiso. Kung pinamamahalaan ng UFW ang IPv6, magdagdag ng katugmang pagtatapon para sa tun0 sa before6.rules din, dahil walang sinasabi ang listahan ng destinasyong IPv4 tungkol sa mga packet na IPv6.

Tiyakin ang na-load na patakaran, hindi ang preview

I-preview ang muling pag-load, ilapat ito sa isang maintenance window, at basahin ang live na set ng tuntunin.

sudo ufw --dry-run reload
sudo ufw show raw

Tiyakin na lumilitaw ang mga bantay ng tunnel bago ang mga default na permiso sa estado at ICMP. Ang simpleng ufw status ay hindi nagpapakita ng mga before na tuntuning na-edit sa kamay, kaya napagpasyahan ng mga operator na may kulang na tuntunin gayong naka-load pala ito. Basahin ang hilaw na listahan mula taas hanggang ibaba sa halip na maghanap ng piraso. Kung lumilitaw ang mga bantay pagkatapos ng permiso sa estado, hindi ginagawa ng hangganan ang sinasabi ng file.

Pagkatapos ay subukan ang pag-uugali hindi ang teksto. Magbukas ng bagong koneksyon sa isang pinapayagang host at panoorin ang sagot, ihatid ang isang hindi nakapipinsalang kahilingan sa isang destinasyong labas ng subnet at tiyaking namamatay ito, subukan ang koneksyong peer-to-peer, subukan ang serbisyong lokal sa gateway, at subukan ang hindi hininging koneksyon mula LAN patungo sa kliyente. Isama ang isang daloy na labas ng saklaw na umiral bago ang pagbabago, at burahin lamang ang daloy na iyon sa halip na i-flush ang buong talahanayan ng pagsubaybay ng makina.

Itala ang mga limitasyon sa tabi ng mga tuntunin: nililimitahan nito ang transit at wala nang iba. Hindi nito pinipigilan ang isang kliyente na gamitin ang sarili nitong koneksyon sa internet, hindi pinipigilan ang isang pinapayagang host ng LAN na ipasa pa ang trapiko, at hindi nito pinapalitan ang awtentikasyon sa loob ng mga pinapayagang serbisyo.