هذا في الواقع سؤال جيد حقًا ولست متفاجئًا من أن لا أحد آخر قد طرحه بعد. الإجابة معقدة، ولكن حتى الآن كانت الردود على هذا الموضوع للأسف سلبية في نبرتها دون الإجابة على السؤال.
ليس الأمر أن Discourse يتجاوز ufw، بل إن docker يتجاوز ufw عن طريق إضافة قواعد تجعل أي منافذ مكشوفة لحاويات docker تعمل على الرغم من وجود ufw.
ماذا يحدث؟
تصل الحزم الواردة الموجهة إلى حاوية إلى جدول FORWARD، وليس جدول INPUT كما قد يتوقع المرء.
تثبيت docker قبل التثبيت
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ufw-before-logging-forward all -- any any anywhere anywhere
0 0 ufw-before-forward all -- any any anywhere anywhere
0 0 ufw-after-forward all -- any any anywhere anywhere
0 0 ufw-after-logging-forward all -- any any anywhere anywhere
0 0 ufw-reject-forward all -- any any anywhere anywhere
0 0 ufw-track-forward all -- any any anywhere anywhere
بعد تثبيت docker
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
8 416 DOCKER-USER all -- any any anywhere anywhere
8 416 DOCKER-ISOLATION-STAGE-1 all -- any any anywhere anywhere
0 0 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
4 256 DOCKER all -- any docker0 anywhere anywhere
4 160 ACCEPT all -- docker0 !docker0 anywhere anywhere
0 0 ACCEPT all -- docker0 docker0 anywhere anywhere
0 0 ufw-before-logging-forward all -- any any anywhere anywhere
0 0 ufw-before-forward all -- any any anywhere anywhere
0 0 ufw-after-forward all -- any any anywhere anywhere
0 0 ufw-after-logging-forward all -- any any anywhere anywhere
0 0 ufw-reject-forward all -- any any anywhere anywhere
0 0 ufw-track-forward all -- any any anywhere anywhere
السبب في وصول الحزم إلى جدول التوجيه هو بسبب القواعد التي يضيفها docker إلى جدول nat:
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
210 12734 DOCKER all -- any any anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- docker0 any anywhere anywhere
0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:https to:172.17.0.2:443
107 6848 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:http to:172.17.0.2:80
يتم معالجة nat/PREROUTING قبل اتخاذ القرار بشأن ما إذا كان سيتم إرسال الحزم عبر INPUT أو FORWARD.
في النهاية، تكمن المشكلة في وجود خدمتين على النظام تقوم بتعديل قواعد جدار الحماية. ufw لا يعرف شيئًا عن هذا، لذا يمكنه فقط الإبلاغ عما قام هو بتكوينه.
حل
لحل هذه المشكلة، قم بإعادة تكوين جدار الحماية لتمرير حركة المرور الموجهة إلى docker عبر سلاسل ufw أيضًا:
أستخدم التعديل الطفيف التالي لعملهم، والذي يتم وضعه قبل تمكين ufw:
# مسروق من https://github.com/chaifeng/ufw-docker - يبدو منطقيًا
# إضافة التوجيه إلى ufw-user-input يسمح بالاتصالات
# بالمنافذ الموجهة التي فتحناها صراحةً
cat <<EOUFW >> /etc/ufw/after.rules
# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16
-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN
-A DOCKER-USER -j ufw-user-forward
-A DOCKER-USER -j ufw-user-input
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER
EOUFW