عامل الميناء يكسر شبكة جسر ليبفيرت

هذه القضية تدفعني للجنون. أقوم بتشغيل تثبيت جديد من أوبونتو 18.04 ، مع:

  • أوفو لإدارة جدار الحماية
  • جسر بي آر 0
  • ليسد و ليبفيرت (كفم)

حاولت الأسهم docker.io حزمة وحزم شكل مستودع ديب عامل الميناء الخاصة.

أريد س تكون قادرة على نشر حاويات عامل الميناء اختيار إب لربط مينائها (على سبيل المثال. - ص 10.58.26.6: 98800: 98800) ثم فتح المنفذ مع أوفو.

ولكن يبدو عامل الميناء لإنشاء قواعد إيبتبلس أن بيرتوباتس جسر بر 0 (على سبيل المثال. المضيف لا يمكن بينغ ليبفيرت الضيوف)

لقد نظرت في كل مكان ولا يمكن العثور على حل جيد ، والأمن علم.

القيام يدويا iptables -I FORWARD -i br0 -o br0 -j ACCEPTيبدو أنه يجعل كل شيء يعمل.

أيضا الإعداد "iptables": false لعامل الميناء الخفي يسمح للجسر أن تتصرف بشكل طبيعي ، ولكن يكسر حاويات عامل الميناء الخروج الشبكة.

لقد وجدت هذا الحل الذي بدا بسيطا ، عن طريق تحرير ملف أوفو واحد https://stackoverflow.com/a/51741599/1091772، لكنه لا يعمل على الإطلاق.

ماذا ستكون أفضل الممارسات والطريقة الآمنة لحل هذا بشكل دائم, البقاء على قيد الحياة لإعادة التشغيل ?

تحرير:انتهى بي الأمر بإضافة -A ufw-before-forward -i br0 -o br0 -j ACCEPT في نهاية /etc/ufw/before.rules قبل الالتزام. هل يمكنني اعتبار هذا بمثابة إصلاح أم لا يثير بعض المشكلات ?

المشكلة ، في الواقع ميزة: فلتر

من الوصف ، وأعتقد أن التفسير المنطقي الوحيد هو أن جسر رمز نيتفيلتر تم تمكين: المقصود من بين الاستخدامات الأخرى لجسر فيريوال الجسر أو للاستفادة إيبتبلس'المباريات والأهداف من مسار الجسر دون الحاجة إلى (أو القدرة على) تكرارها جميعا إبتبلز. تجاهل تماما طبقات الشبكة ، رمز جسر إيثرنت ، في طبقة الشبكة 2 ، يجعل الآن أوبكالز ل إيبتبلس العمل على مستوى الملكية الفكرية ، أي طبقة الشبكة 3. يمكن تمكينه عالميا فقط حتى الآن: إما للمضيف وكل الحاويات ، أو لا شيء. بمجرد فهم ما يحدث ومعرفة ما الذي تبحث عنه ، يمكن اتخاذ خيارات مكيفة.

يصف مشروع نيتفيلتر مختلف ebtables/iptables التفاعلات عندما فلتر تم تمكين. خصوصا من الفائدة هو الباب 7 شرح سبب الحاجة أحيانا إلى بعض القواعد دون تأثير واضح لتجنب التأثيرات غير المقصودة من مسار الجسر، مثل استخدام:

iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -d 172.16.1.0/24 -j ACCEPTiptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j MASQUERADE

لتجنب نظامين على نفس الشبكة المحلية لتكون ناتيد من قبل... الجسر (انظر المثال أدناه).

لديك عدد قليل من الخيارات لتجنب مشكلتك، ولكن الخيار الذي اتخذ هو على الارجح أفضل إذا كنت لا تريد أن تعرف كل التفاصيل ولا التحقق مما إذا كانت بعض قواعد إيبتبلس (مخبأة في بعض الأحيان في مساحات أسماء أخرى) سوف تتعطل:

  • منع بشكل دائم فلتر وحدة ليتم تحميلها. عادة blacklist لا يكفي, install يجب استخدامها. هذا هو خيار عرضة للقضايا للتطبيقات التي تعتمد على فلتر: من الواضح عامل الميناء, كوبرنيتس, ...

    echo install br_netfilter /bin/true > /etc/modprobe.d/disable-br-netfilter.conf
  • قم بتحميل الوحدة ، ولكن قم بتعطيل آثارها. ل إيبتبلس'الآثار التي هي:

    sysctl -w net.bridge.bridge-nf-call-iptables=0

    في حالة وضع هذا عند بدء التشغيل ، يجب تحميل الوحدة أولا أو لن يكون هذا التبديل موجودا بعد.

هذان الخياران السابقان سيعطلان بالتأكيد إيبتبلس المباراة -m physdev: ال اكس تي فيسديف وحدة عند تحميل نفسها ، لصناعة السيارات في تحميل فلتر الوحدة النمطية (قد يحدث هذا حتى لو تسببت قاعدة مضافة من حاوية في التحميل). الآن فلتر لن يتم تحميلها, -m physdev ربما لن تتطابق أبدا.

  • العمل حول تأثير برنتفيلتر عند الحاجة ، مثل أوب: إضافة تلك القواعد لا أوب واضحة في سلاسل مختلفة (بريروتينغ ، إلى الأمام ، بوستروتينغ) كما هو موضح في الباب 7. على سبيل المثال:

    iptables -t nat -A POSTROUTING -s 172.18.0.0/16 -d 172.18.0.0/16 -j ACCEPTiptables -A FORWARD -i br0 -o br0 -j ACCEPT

    يجب ألا تتطابق هذه القواعد أبدا لأن حركة المرور في نفس إب لان لا يتم توجيهها ، باستثناء بعض الاجهزة دنات نادرة. ولكن بفضل فلتر إنهم يتطابقون, لأنهم مدعوون أولا تحول إطارات ("ترقية" إلى حزم إب) عبور جسر. ثم يتم استدعاؤهم مرة أخرى من أجل توجيه الحزم عبور جهاز التوجيه إلى واجهة غير ذات صلة (ولكن لن تتطابق بعد ذلك).

  • لا تضع إب على الجسر: وضع هذا إب على نهاية واحدة من veth واجهة مع الطرف الآخر على الجسر: وهذا ينبغي أن يضمن أن الجسر لن تتفاعل مع التوجيه ، ولكن هذا ليس ما تقوم به معظم الحاويات/فم المنتجات المشتركة.

  • يمكنك حتى إخفاء الجسر في مساحة اسم الشبكة المعزولة الخاصة به (لن يكون ذلك مفيدا إلا إذا كنت ترغب في العزلة عن الآخرين إبتبلز القواعد هذه المرة).

  • تبديل كل شيء إلى نفتابلز والتي من بين الأهداف المعلنة سوف تتجنب هذه جسر قضايا التفاعل. في الوقت الحالي ، لا يوجد دعم رسمي للجسر ، لا يزال ويب ولكن وعد أن يكون أنظف عندما تكون متاحة ، لأنه لن يكون هناك أي "أوبكال".

يجب عليك البحث ما يطلق تحميل فلتر (على سبيل المثال: -m physdev) ومعرفة ما إذا كان يمكنك تجنب ذلك أم لا ، لاختيار كيفية المضي قدما.


مثال مع مساحات أسماء الشبكة

دعنا نعيد إنتاج بعض التأثيرات باستخدام مساحة اسم الشبكة. لاحظ أنه في أي مكان أي إبتبلز سيتم استخدام القاعدة. لاحظ أيضا أن هذا المثال يعتمد على الإرث المعتاد iptables، ليس إيبتبلس على نفتابلز كما تمكين افتراضيا على دبيان المغفل.

دعونا إعادة إنتاج حالة بسيطة مماثلة مع العديد من الاستخدامات الحاويات: جهاز توجيه 192.168.0.1 / 192.0.2.100 القيام نات مع اثنين من المضيفين وراء: 192.168.0.101 و 192.168.0.102 ، مرتبطة مع جسر على جهاز التوجيه. يمكن للمضيفين التواصل مباشرة على نفس الشبكة المحلية ، من خلال الجسر.

#!/bin/shfor ns in host1 host2 router; do    ip netns del $ns 2>/dev/null || :    ip netns add $ns    ip -n $ns link set lo updoneip netns exec router sysctl -q -w net.ipv4.conf.default.forwarding=1ip -n router link add bridge0 type bridgeip -n router link set bridge0 upip -n router address add 192.168.0.1/24 dev bridge0for i in 1 2; do    ip -n host$i link add eth0 type veth peer netns router port$i    ip -n host$i link set eth0 up    ip -n host$i address add 192.168.0.10$i/24 dev eth0    ip -n host$i route add default via 192.168.0.1    ip -n router link set port$i up master bridge0done#to mimic a standard NAT router, iptables rule voluntarily made as it is to show the last "effect"ip -n router link add name eth0 type dummyip -n router link set eth0 upip -n router address add 192.0.2.100/24 dev eth0ip -n router route add default via 192.0.2.1ip netns exec router iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

دعونا تحميل وحدة النواة فلتر (للتأكد من أنه لن يكون لاحقا) وتعطيل آثاره باستخدام مفتاح التبديل (ليس لكل مساحة اسم جسر-نف-كول-إيبتبلس، متوفر فقط في مساحة الاسم الأولية:

modprobe br_netfiltersysctl -w net.bridge.bridge-nf-call-iptables=0

تحذير: مرة أخرى ، وهذا يمكن أن يعطل إيبتبلس قواعد مثل -m physdev في أي مكان على المضيف أو في الحاويات التي تعتمد على فلتر تحميل وتمكين.

دعونا نضيف بعض عدادات المرور بينغ اللجنة الدولية لشؤون المفقودين.

ip netns exec router iptables -A FORWARD -p icmp --icmp-type echo-requestip netns exec router iptables -A FORWARD -p icmp --icmp-type echo-reply

دعونا بينغ:

# ip netns exec host1 ping -n -c2 192.168.0.102PING 192.168.0.102 (192.168.0.102) 56(84) bytes of data.64 bytes from 192.168.0.102: icmp_seq=1 ttl=64 time=0.047 ms64 bytes from 192.168.0.102: icmp_seq=2 ttl=64 time=0.058 ms--- 192.168.0.102 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 1017msrtt min/avg/max/mdev = 0.047/0.052/0.058/0.009 ms

لن تتطابق العدادات:

# ip netns exec router iptables -v -S FORWARD-P FORWARD ACCEPT -c 0 0-A FORWARD -p icmp -m icmp --icmp-type 8 -c 0 0-A FORWARD -p icmp -m icmp --icmp-type 0 -c 0 0

دعونا تمكين جسر-نف-كول-إيبتبلس وبينغ مرة أخرى:

# sysctl -w net.bridge.bridge-nf-call-iptables=1net.bridge.bridge-nf-call-iptables = 1# ip netns exec host1 ping -n -c2 192.168.0.102PING 192.168.0.102 (192.168.0.102) 56(84) bytes of data.64 bytes from 192.168.0.102: icmp_seq=1 ttl=64 time=0.094 ms64 bytes from 192.168.0.102: icmp_seq=2 ttl=64 time=0.163 ms--- 192.168.0.102 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 1006msrtt min/avg/max/mdev = 0.094/0.128/0.163/0.036 ms

هذه المرة تحولت الحزم حصلت على مباراة في إيبتبلس ' تصفية / سلسلة إلى الأمام:

# ip netns exec router iptables -v -S FORWARD-P FORWARD ACCEPT -c 4 336-A FORWARD -p icmp -m icmp --icmp-type 8 -c 2 168-A FORWARD -p icmp -m icmp --icmp-type 0 -c 2 168

دعونا نضع سياسة إسقاط (التي تصفر العدادات الافتراضية) وحاول مرة أخرى:

# ip netns exec host1 ping -n -c2 192.168.0.102PING 192.168.0.102 (192.168.0.102) 56(84) bytes of data.--- 192.168.0.102 ping statistics ---2 packets transmitted, 0 received, 100% packet loss, time 1008ms# ip netns exec router iptables -v -S FORWARD-P FORWARD DROP -c 2 168-A FORWARD -p icmp -m icmp --icmp-type 8 -c 4 336-A FORWARD -p icmp -m icmp --icmp-type 0 -c 2 168

رمز الجسر تصفية الإطارات/الحزم تحولت عبر إيبتبلس. دعونا نضيف قاعدة الالتفافية (والتي سوف الصفر مرة أخرى العدادات الافتراضية) كما هو الحال في المرجع وحاول مرة أخرى:

# ip netns exec router iptables -A FORWARD -i bridge0 -o bridge0 -j ACCEPT# ip netns exec host1 ping -n -c2 192.168.0.102PING 192.168.0.102 (192.168.0.102) 56(84) bytes of data.64 bytes from 192.168.0.102: icmp_seq=1 ttl=64 time=0.132 ms64 bytes from 192.168.0.102: icmp_seq=2 ttl=64 time=0.123 ms--- 192.168.0.102 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 1024msrtt min/avg/max/mdev = 0.123/0.127/0.132/0.012 ms# ip netns exec router iptables -v -S FORWARD-P FORWARD DROP -c 0 0-A FORWARD -p icmp -m icmp --icmp-type 8 -c 6 504-A FORWARD -p icmp -m icmp --icmp-type 0 -c 4 336-A FORWARD -i bridge0 -o bridge0 -c 4 336 -j ACCEPT

دعونا نرى ما يتم تلقيه الآن بالفعل على المضيف2 خلال بينغ من المضيف1:

# ip netns exec host2 tcpdump -l -n -s0 -i eth0 -p icmptcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes02:16:11.068795 IP 192.168.0.1 > 192.168.0.102: ICMP echo request, id 9496, seq 1, length 6402:16:11.068817 IP 192.168.0.102 > 192.168.0.1: ICMP echo reply, id 9496, seq 1, length 6402:16:12.088002 IP 192.168.0.1 > 192.168.0.102: ICMP echo request, id 9496, seq 2, length 6402:16:12.088063 IP 192.168.0.102 > 192.168.0.1: ICMP echo reply, id 9496, seq 2, length 64

... بدلا من المصدر 192.168.0.101. تم استدعاء قاعدة التنكر أيضا من مسار الجسر. لتجنب هذا إما إضافة (كما هو موضح في الباب 7مثال) قاعدة استثناء من قبل ، أو ذكر واجهة صادرة غير جسر ، إن أمكن على الإطلاق (الآن أصبح متاحا حتى يمكنك استخدامه -m physdev إذا كان يجب أن يكون جسرا...).


ذات الصلة بشكل عشوائي:

لكمل / نيتفيلتر-ديف: بر نت فيلتر: تمكين في نيتنس غير الأولية: سيساعد ذلك على تمكين هذه الميزة لكل مساحة اسم وليس عالميا، مما يحد من التفاعلات بين المضيفين والحاويات.

نيتفيلتر-ديف: نيتفيلتر: فيسديف: ريلاكس بر_نيتفيلتر التبعية: مجرد محاولة حذف غير موجود فيسديف القاعدة يمكن أن تخلق مشاكل.

نيتفيلتر-ديف: دعم تتبع الاتصال للجسر: ويب بريدج نيتفيلتر كود لإعداد جسر فيريوال جسر باستخدام نفتابلز ، وهذه المرة أكثر أناقة. أعتقد أن واحدة من الخطوات الأخيرة للتخلص من إيبتبلس (نواة الجانب أبي).

إذا كانت التهديدات المذكورة أعلاه لا تحل مشكلتك ، فإليك كيفية حل المشكلة على امتداد دبيان.

  • 1 ، حفظ إيبتبلس الحالي الخاص بك

    iptables-save > your-current-iptables.rules
  • 2 ، حذف الكل أنشأ عامل الميناء القواعد

    iptables -D <DOCKER-CHAIN-RULES> <target-line-number>
  • 3 ، إضافة إيتبابلز قواعد لقبول أي حركة المرور إلى المدخلات ، إلى الأمام والإخراج

    iptables -I INPUT -j ACCEPTiptables -I FORWARD -j ACCEPTiptables -I OUTPUT -j ACCEPT
  • 4 ، إعادة تشغيل عامل الميناء الخاص بك

    service docker restart

وبمجرد الانتهاء من الخطوة 3 ، يمكنك بينغ المضيف ليبفرت كفم المحظورة من جهاز كمبيوتر آخر ، سترى ردود اللجنة الدولية لشؤون المفقودين.

إعادة تشغيل عامل الميناء أيضا إضافة قواعد إيبتبلس المطلوبة مرة أخرى إلى الجهاز الخاص بك ولكن لن يتم حظر الخاص بك كبم الجسور المضيفين أي أكثر من ذلك.

إذا كان الحل أعلاه لا يعمل بالنسبة لك ، يمكنك استعادة إيبتبلس باستخدام الأمر التالي:

  • استعادة إيبتبلس

    iptables-restore < your-current-iptables.rules