iptables: VPN müştəriləri yalnız bir hosta çatsın, başqa heç yerə

Əlaqəsiz görünən iki dəstək bileti əslində eyni səbəbi paylaşır. Birincisində administrator serverin yalnız tuneldən gələn bağlantıları qəbul etməsini istəyir; ikincisində VPN istifadəçiləri bir daxili hosta çatmalı və başqa heç yerə getməməlidir. Hər iki siyasət FORWARD zəncirinə aiddir və hər ikisi adətən INPUT-da sınanır. Nəticə firewall kimi görünür, amma yer tutucu kimi davranır.

Hansı zəncir sualınıza cavab verir

VPN müştərisinin LAN hostuna və ya internetə göndərdiyi paketlər nüvə tərəfindən yönləndirilir və FORWARD-da qiymətləndirilir. INPUT və OUTPUT yalnız serverin özündə bitən və ya ondan başlayan trafiki görür. Buna görə tun0-dan gəlməyən hər şeyi rədd etmək serverin öz dinləyicilərini qoruyur və mövcud axınlar əvvəlcə qəbul edilməzsə SSH sessiyanızı da dayandıracaq. Bu, müştərilərin hara gedə biləcəyi barədə heç nəyi dəyişmir.

Əvvəlcə sualı adlandırın: serverə kim çata bilər, yoxsa müştərilər hara gedə bilər. Əksər şəbəkələr hər iki cavabı istəyir, amma müxtəlif zəncirlərdə.

Əvvəlcə vəziyyət, sonra icazə, sonra rədd

İcazə siyahısı yalnız o zaman işləyir ki, konkret icazə ümumi rəddin üstündə otursun və qayıdış trafiki hər ikisinin üstündə qəbul edilsin. Qaydaları açıq mövqelərə daxil edin, sonra zənciri iptables -S FORWARD ilə çıxarın ki, sıra təxmin deyil, görünən olsun.

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

İki xırdalıq bunun real trafiklə təmasda qalıb-qalmayacağını həll edir. Vəziyyət qaydası olmadan, yenicə icazə verdiyiniz bağlantılara gələn cavablar özləri rədd qaydasına düşür və atılır. Məhdudiyyətsiz LOG qaydası skan ilk dəfə dəydikdə kiçik bölməni doldurub bitirə bilər, ona görə logging davam etməzdən əvvəl -m limit --limit 10/min əlavə edin. REJECT dərhal xəta qaytarır, bu da siyahını tənzimləyərkən daha dostcasıdır; DROP səssizcə atır, ona görə hər səhv vaxt aşımı kimi görünür. Birini qəsdən seçin və seçimi dəyişiklik qeydinə yazın.

Yönləndirmə və NAT əvvəlcədən işləməlidir

Filtrləmə yolun mövcud olduğunu sübut edə bilməz. Əvvəlcə nüvənin ümumiyyətlə yönləndirdiyini təsdiqləyin və bu ayarı bir dəfəlik shell əmri deyil, davamlı edin. Filtr sonuncu təbəqədir, birinci deyil.

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

Maskaradın yeri müştərilərin haradan çıxdığından asılıdır. Tuneldən uzaq şəbəkəyə çıxırlarsa, NAT qaydası WAN interfeysinə deyil, həmin interfeysə yazılır. Sonra sayğaclara baxın: POSTROUTING sayğacı heç tərpənmirsə, FORWARD qəbul sayı isə artırsa, qayıdış yolu pozulub, filtr isə qaydasındadır. Bu oxunuş heç vaxt problem olmayan qaydaları yenidən yazmaqla bir günorta itirməyin qarşısını alır.

Poçt bloku bir zəncir yuxarıya aiddir

INPUT-da 25-ci portu bloklamaq yalnız VPN serverinə ünvanlanmış poçtu dayandırır. Tuneldən poçt göndərən yoluxmuş müştəri yönləndirilir, ona görə blok 465 və 587-nin yanında FORWARD-da oturmalıdır. Bir tətbiq qanuni olaraq poçtu relay edirsə, onun təyinatını və portunu həmin qaydanın üstünə qoyun.

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

Başqa heç nəyi sərtləşdirməzdən əvvəl rədd sayğacını bir həftə işlədin. Dırmaşmağı dayandıran rəqəm yenicə pozduğunuz qanuni axındır.

Geri oxuyun, sonra müştəridən sübut edin

Qaydalar toplusunu nüvənin bildirdiyi kimi oxuyun, skriptinizin yazdığı kimi deyil. iptables -S FORWARD ilə başlayın, sonra iptables -t nat -L POSTROUTING -n -v ilə NAT cədvəli, sonra yoxladığınız axın üçün conntrack girişi. İş davam etdikcə geri qaytarma əmri və ya planlaşdırılmış təmizləmə saxlayın. Hər çağırış -w tələb edir, əks halda iki administrator xtables kilidində toqquşacaq. Dəyişiklik pəncərəsində bunların heç biri könüllü deyil.

Hovuzun içindəki və xaricindəki bir müştəridən test edərək bitirin. Yalnız yazdığınız maşından işləyən qayda siyasət deyil.