حركة مرور أودب لم يتم إعادة توجيهها من حاويات عامل الميناء - > مضيف عامل الميناء

Blake_P · May 1, 2022, 10:26pm

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

ومن المعروف أن رمز إدارة التكوين الذي يبني المضيف عامل الميناء للعمل على معيار ريل 7 صورة من السوق ، وبالتالي فإن المشكلة معروفة أن يكون شيئا داخل سو ريل 7 صورة.

ريل 7.2 / عامل ميناء الإصدار 1.12.6, بناء 884867/1.12.6. الحاوية هي ريل 7.3. سيلينو في تمكين / وضع متساهل. مضيف عامل الميناء هو مثيل أمازون إي سي 2.

بعض التكوين:

# /etc/sysconfig/dockerOPTIONS='--dns=10.0.0.10 --dns=10.0.0.11 --dns-search=example.com'DOCKER_CERT_PATH=/etc/dockerADD_REGISTRY='--add-registry registry.example.com'no_proxy=169.254.169.254,localhost,127.0.0.1,registory.example.comhttp_proxy=http://proxy.example.com:8080https_proxy=http://proxy.example.com:8080ftp_proxy=http://proxy.example.com:8080

تكوين محلل في الحاوية والمضيف هو نفسه:

# /etc/resolv.confsearch example.comnameserver 10.0.0.10nameserver 10.0.0.11

إذا قمت بإعادة تشغيل الخفي عامل الميناء مع --debug أرى ما يلي في journalctl -u docker.service:

Aug 08 11:44:23 myhost.example.com dockerd-current[17341]: time="2017-08-08T11:44:23.430769581+10:00" level=debug msg="Name To resolve: http://proxy.example.com."Aug 08 11:44:23 myhost.example.com dockerd-current[17341]: time="2017-08-08T11:44:23.431488213+10:00" level=debug msg="Query http://proxy.example.com.[1] from 172.18.0.6:38189, forwarding to udp:10.162.182.101"Aug 08 11:44:27 myhost.example.com dockerd-current[17341]: time="2017-08-08T11:44:27.431772666+10:00" level=debug msg="Read from DNS server failed, read udp 172.18.0.6:38189->10.162.182.101:53: i/o timeout"

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

في الواقع ، (تحديث #3) اتضح أنني يمكن تجنب المشكلة تماما ببساطة عن طريق تكوين دنس لاستخدام تكب بدلا من أودب ، أي.

# head -1 /etc/sysconfig/dockerOPTIONS="--dns=10.0.0.10 --dns=10.0.0.11 --dns-search=example.com --dns-opt=use-vc"

(إضافة سطر use-vc يخبر المحلل لاستخدام تكب بدلا من أودب.)

فعلت ملاحظة بعض القواعد المشبوهة المظهر في إيبتبلس ، ولكن هذه تبين أن تكون طبيعية:

# iptables -n -L DOCKER-ISOLATION -v --line-numbersChain DOCKER-ISOLATION (1 references)num   pkts bytes target     prot opt in     out     source               destination         1        0     0 DROP       all  --  br-1d6a05c10468 docker0  0.0.0.0/0            0.0.0.0/0           2        0     0 DROP       all  --  docker0 br-1d6a05c10468  0.0.0.0/0            0.0.0.0/0           3    34903   11M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

بعد حذف هاتين القاعدتين ، واصلت رؤية المشكلة.

إيبتبلس كامل:

# iptables -nL -vChain INPUT (policy ACCEPT 2518 packets, 1158K bytes) pkts bytes target     prot opt in     out     source               destination         Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target     prot opt in     out     source               destination         23348 9674K DOCKER-ISOLATION  all  --  *      *       0.0.0.0/0            0.0.0.0/0               0     0 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0               0     0 ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED    0     0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0               0     0 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0           23244 9667K DOCKER     all  --  *      br-1d6a05c10468  0.0.0.0/0            0.0.0.0/0           23232 9667K ACCEPT     all  --  *      br-1d6a05c10468  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED  104  6230 ACCEPT     all  --  br-1d6a05c10468 !br-1d6a05c10468  0.0.0.0/0            0.0.0.0/0              12   700 ACCEPT     all  --  br-1d6a05c10468 br-1d6a05c10468  0.0.0.0/0            0.0.0.0/0           Chain OUTPUT (policy ACCEPT 2531 packets, 414K bytes) pkts bytes target     prot opt in     out     source               destination         Chain DOCKER (2 references) pkts bytes target     prot opt in     out     source               destination             0     0 ACCEPT     tcp  --  !br-1d6a05c10468 br-1d6a05c10468  0.0.0.0/0            172.18.0.2           tcp dpt:443    0     0 ACCEPT     tcp  --  !br-1d6a05c10468 br-1d6a05c10468  0.0.0.0/0            172.18.0.2           tcp dpt:80    0     0 ACCEPT     tcp  --  !br-1d6a05c10468 br-1d6a05c10468  0.0.0.0/0            172.18.0.3           tcp dpt:389Chain DOCKER-ISOLATION (1 references) pkts bytes target     prot opt in     out     source               destination             0     0 DROP       all  --  br-1d6a05c10468 docker0  0.0.0.0/0            0.0.0.0/0               0     0 DROP       all  --  docker0 br-1d6a05c10468  0.0.0.0/0            0.0.0.0/0           23348 9674K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

جسر التكوين

# ip addr show docker04: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN     link/ether 02:42:a8:73:db:bb brd ff:ff:ff:ff:ff:ff    inet 172.17.0.1/16 scope global docker0       valid_lft forever preferred_lft forever# ip addr show br-1d6a05c104683: br-1d6a05c10468: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP     link/ether 02:42:d5:b6:2d:f5 brd ff:ff:ff:ff:ff:ff    inet 172.18.0.1/16 scope global br-1d6a05c10468       valid_lft forever preferred_lft forever

و

# docker network inspect bridge [    {        "Name": "bridge",        "Id": "e159ddd37386cac91e0d011ade99a51f9fe887b8d32d212884beace67483af44",        "Scope": "local",        "Driver": "bridge",        "EnableIPv6": false,        "IPAM": {            "Driver": "default",            "Options": null,            "Config": [                {                    "Subnet": "172.17.0.0/16",                    "Gateway": "172.17.0.1"                }            ]        },        "Internal": false,        "Containers": {},        "Options": {            "com.docker.network.bridge.default_bridge": "true",            "com.docker.network.bridge.enable_icc": "true",            "com.docker.network.bridge.enable_ip_masquerade": "true",            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",            "com.docker.network.bridge.name": "docker0",            "com.docker.network.driver.mtu": "1500"        },        "Labels": {}    }]

في السجلات:

Aug 04 17:33:32 myhost.example.com systemd[1]: Starting Docker Application Container Engine...Aug 04 17:33:33 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:33.056770003+10:00" level=info msg="libcontainerd: new containerd process, pid: 2140"Aug 04 17:33:34 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:34.740346421+10:00" level=info msg="Graph migration to content-addressability took 0.00 seconds"Aug 04 17:33:34 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:34.741164354+10:00" level=info msg="Loading containers: start."Aug 04 17:33:34 myhost.example.com dockerd-current[2131]: .........................time="2017-08-04T17:33:34.903371015+10:00" level=info msg="Firewalld running: true"Aug 04 17:33:35 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:35.325581993+10:00" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address" Aug 04 17:33:36 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:36+10:00" level=info msg="Firewalld running: true"Aug 04 17:33:37 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:37+10:00" level=info msg="Firewalld running: true"Aug 04 17:33:37 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:37+10:00" level=info msg="Firewalld running: true"Aug 04 17:33:38 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:38+10:00" level=info msg="Firewalld running: true"Aug 04 17:33:39 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:39+10:00" level=info msg="Firewalld running: true"Aug 04 17:33:40 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:40+10:00" level=info msg="Firewalld running: true"Aug 04 17:33:40 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:40+10:00" level=info msg="Firewalld running: true"Aug 04 17:33:42 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:42+10:00" level=info msg="Firewalld running: true"Aug 04 17:33:42 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:42+10:00" level=info msg="Firewalld running: true"Aug 04 17:33:43 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:43.541905145+10:00" level=info msg="Loading containers: done."Aug 04 17:33:43 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:43.541975618+10:00" level=info msg="Daemon has completed initialization"Aug 04 17:33:43 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:43.541998095+10:00" level=info msg="Docker daemon" commit="88a4867/1.12.6" graphdriver=devicemapper version=1.12.6Aug 04 17:33:43 myhost.example.com dockerd-current[2131]: time="2017-08-04T17:33:43.548508756+10:00" level=info msg="API listen on /var/run/docker.sock"Aug 04 17:33:43 myhost.example.com systemd[1]: Started Docker Application Container Engine.

من الحاوية ، يمكنني اختبار الاتصال بالبوابة الافتراضية ولكن فشل كل دقة الاسم.

لقد لاحظت شيئا غريبا في السجل (تحديث #2 وأنا أعلم الآن أن هذا هو الرنجة الحمراء-انظر المناقشة أدناه):

# journalctl -u docker.service |grep insmod > /tmp/log # \n's replaced belowJul 26 23:59:02 myhost.example.com dockerd-current[3185]: time="2017-07-26T23:59:02.056295890+10:00" level=warning msg="Running modprobe bridge br_netfilter failed with message: insmod /lib/modules/3.10.0-514.26.2.el7.x86_64/kernel/net/bridge/bridge.ko sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-arptables: No such file or directorysysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-iptables: No such file or directorysysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-ip6tables: No such file or directorymodprobe: ERROR: Error running install command for bridgemodprobe: ERROR: could not insert 'bridge': Unknown error 253insmod /lib/modules/3.10.0-514.26.2.el7.x86_64/kernel/net/llc/llc.ko insmod /lib/modules/3.10.0-514.26.2.el7.x86_64/kernel/net/802/stp.ko install /sbin/modprobe --ignore-install bridge && /sbin/sysctl -q -w net.bridge.bridge-nf-call-arptables=0 net.bridge.bridge-nf-call-iptables=0 net.bridge.bridge-nf-call-ip6tables=0 insmod /lib/modules/3.10.0-514.26.2.el7.x86_64/kernel/net/bridge/br_netfilter.ko , error: exit status 1"

تحديث #1: وهذا قادم من:

# tail -2 /etc/modprobe.d/dist.conf# Disable netfilter on bridges when the bridge module is loadedinstall bridge /sbin/modprobe --ignore-install bridge && /sbin/sysctl -q -w net.bridge.bridge-nf-call-arptables=0 net.bridge.bridge-nf-call-iptables=0 net.bridge.bridge-nf-call-ip6tables=0

أيضا:

# cat /proc/sys/net/bridge/bridge-nf-call-{arp,ip,ip6}tables111

ومع ذلك ، حتى بعد أن أفعل هذا:

# for i in /proc/sys/net/bridge/bridge-nf-call-{arp,ip,ip6}tables ; do echo 0 > $i ; done

لا يوجد حظ حتى الآن.

قضيت يوما كاملا على هذا حتى سحب شعري من الآن. أي أفكار حول ما يمكنني تجربته أو ما قد تكون المشكلة موضع تقدير كبير.

تحديث # 4

>أجريت بعض التجارب باستخدام نيتكات ولقد أثبتت أن جميع الحزم أودب لا يتم توجيهها إذا أرسلت من أي حاوية المضيف. حاولت استخدام عدة منافذ بما في ذلك 53 و 2115 و 50000. حزم تكب على ما يرام ولكن. هذا لا يزال صحيحا إذا كنت مسح قواعد إيبتبلس مع iptables -F.

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

لإعداد الاختبار:

على المضيف ، الذي لديه إب 10.1.1.10:

# nc -u -l 50000

على الحاوية:

# echo "foo" | nc -w1 -u 10.1.1.10 50000

أثناء التقاط تفريغ تكب أرى:

17:20:36.761214 IP (tos 0x0, ttl 64, id 48146, offset 0, flags [DF], proto UDP (17), length 32)    172.17.0.2.41727 > 10.1.1.10.50000: [bad udp cksum 0x2afa -> 0x992f!] UDP, length 4        0x0000:  4500 0020 bc12 4000 4011 53de ac11 0002  E.....@.@.S.....        0x0010:  0aa5 7424 a2ff c350 000c 2afa 666f 6f0a  ..t$...P..*.foo.        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................17:20:36.761214 IP (tos 0x0, ttl 64, id 48146, offset 0, flags [DF], proto UDP (17), length 32)    172.17.0.2.41727 > 10.1.1.10.50000: [bad udp cksum 0x2afa -> 0x992f!] UDP, length 4        0x0000:  4500 0020 bc12 4000 4011 53de ac11 0002  E.....@.@.S.....        0x0010:  0aa5 7424 a2ff c350 000c 2afa 666f 6f0a  ..t$...P..*.foo.        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................

حاولت دون جدوى لإصلاح اختبارية أودب سيئة عبر هذا.

>>لاحظت ، مع ذلك ، أن المجاميع الاختبارية أودب سيئة ينظر إليها حتى أثناء الإرسال الناجح لحزم أودب (المضيف المضيف) والحاوية الحاوية.

باختصار ، أنا أعرف الآن:

التوجيه على ما يرام
يتم مسح إيبتبلس
سيلينو هو متساهل
كل برنامج التعاون الفني يعمل في كل الاتجاهات
>كل أودب من حاوية حاوية على ما يرام
>كل أودب من المضيف المضيف على ما يرام
>كل أودب من المضيف حاوية على ما يرام
لكن> لا يتم إعادة توجيه حزم أودب من حاوية المضيف

Jaime_curly · May 1, 2022, 10:30pm

أنا أحسب ذلك.

كان لدينا تريند مايكرو (مكافحة الفيروسات) وكيل يعمل في الشركات المملوكة للدولة التي لم أكن أعرف عن.

كان إصلاحه بسيطا مثل:

# systemctl stop ds_agent.service# pkill ds_agent

لست متأكدا بالضبط في هذه المرحلة لماذا يتم حظر أودب من الحاويات أو كيفية وقفه.

Carol_B · May 1, 2022, 10:35pm

يبدو أن لديك مودبروب install التوجيه الذي لا يمكن أن يعمل. ربما انها نتيجة لتحديث غير مكتملة لريل 7.2 أو بعض الإصلاحات اليدوية.

حاول grep -r bridge /etc/modprobe.d /lib/modprobe.d للمبتدئين, أو حفر حولها /etc/modprobe.d أو /lib/modprobe.d ومحاولة العثور على حيث أنها لا تحدد install القاعدة التي تدعو sysctl -q -w net.bridge.bridge-nf-call-arptables=0 net.bridge.bridge-nf-call-iptables=0 net.bridge.bridge-nf-call-ip6tables=0

هذا sysctl من الواضح أنه في المكان الخطأ. إما أنها زائدة عن الحاجة أو يجب أن تظهر بعد br_netfilter، ليس قبل ذلك. لم؟ مؤخرا /proc/sys/net/bridge تم نقل المناولة من bridge وحدة إلى br_netfilter وحدة. يحدث هذا مع بعض نسخة من kernel*.rpm، في حين أن محتويات modprobe.d يتم توزيع الدلائل مع الحزم الفردية الأخرى. لقد تحققت على بلدي ريل 7.2:

# modprobe bridge# sysctl -q -w net.bridge.bridge-nf-call-iptables=0sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-iptables: No such file or directory# modprobe br_netfilter# sysctl -q -w net.bridge.bridge-nf-call-iptables=0    # ok now

لا أرى هذه القواعد "المكسورة" على فانيلا ريل 7.1 ~~وأصلهم غامض بالنسبة لي~~. لقد حاولت:

# modprobe -n -vvv bridgemodprobe: INFO: custom logging function 0x40a130 registeredinsmod /lib/modules/3.10.0-229.11.1.el7.x86_64/kernel/net/llc/llc.koinsmod /lib/modules/3.10.0-229.11.1.el7.x86_64/kernel/net/802/stp.koinsmod /lib/modules/3.10.0-229.11.1.el7.x86_64/kernel/net/bridge/bridge.komodprobe: INFO: context 0xf1c270 released# echo "install bridge echo example_of_a_modprobe_rule" > /etc/modprobe.d/zzz5.conf# modprobe -n -vvv bridgemodprobe: INFO: custom logging function 0x40a130 registeredinsmod /lib/modules/3.10.0-229.11.1.el7.x86_64/kernel/net/llc/llc.koinsmod /lib/modules/3.10.0-229.11.1.el7.x86_64/kernel/net/802/stp.koinstall echo example_of_a_modprobe_rulemodprobe: INFO: context 0xeaa270 released# rm /etc/modprobe.d/zzz5.conf

تحديث: يبدو مثل يستخدم زينسرفر الإختراق مودبروب مماثلة. انها علة سيئة لتغيير عالميا السلوك وحدة النواة للجميع سواء كنت في الواقع تشغيل زينسرفر أم لا.

تحديث 2: الآن ، لقد وجدت ذلك /etc/modprobe.d/dist.conf يسبب هذه المشكلة وليس عامل الميناء. سواء كان لديك عامل ميناء أم لا, modprobe bridge سيعود دائما 1 وخطأ الطباعة. حي عادة.أسيوط هو جزء من module-init-tools حزمة على ريل 6. ليس من المفترض أن يتم استخدام هذا الملف على ريل7. انها ليست على أي من أنظمة ريل 7 بلدي وأنها تعمل على ما يرام. في ريل 7 الحزمة هي kmod وأنها لا تحتوي على حي.أسيوط. وأود أن:

rpm -qf /etc/modprobe.d/dist.conf  # what package owns this file?

إذا حي.أسيوط ليست مملوكة من قبل حزمة ، والنسخ الاحتياطي وحذف أي خطوط التي لا تعطيك أي فائدة واضحة (ربما حتى حذف الملف تماما).

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

Harley · May 1, 2022, 10:40pm

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

sudo yum install NetworkManager-tui

وإعادة تكوين بلدي resolv.conf مع نظام أسماء النطاقات الافتراضي كما 8.8.8.8.

nano /etc/resolv.conf

Leslie_J · May 1, 2022, 10:45pm

@ الأيتام ، تحديث مع نتائج من تجاربي نيتكات. في الأساس ، يتم فقدان كل أودب من حاوية - > المضيف ، ولكن تكب على ما يرام ، و أودب هو أيضا على ما يرام من حاوية - > حاوية ومن المضيف - > حاوية. وكل هذا صحيح بعد إيبتبلس-ف.

Addison_P · May 1, 2022, 10:51pm

هل هذا يساعد? How do I publish a UDP Port on Docker? - Stack Overflow

Rowan_R · May 1, 2022, 10:56pm

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

Thomas_J · May 1, 2022, 11:01pm

على أي واجهة قمت بتشغيل ‘تكبدومب’? يجب تشغيله على واجهة` دوكر 0 ’ ، واجهة المضيف المنتهية ولايته وعلى خادم الأسماء لمعرفة أين يتم إسقاط الحزم (ربما بسبب المجموع الاختباري أودب سيئة). هل يمكنك تشغيل ‘إيبتبلس - تي مانغل-بوستروتينغ-س دوكر 0 - ف أودب-ي الاختباري fill الاختباري ملء’ لمعرفة ما إذا كان إصلاح مشكلتك? إذا كان المضيف الخاص بك هو فم والأمر السابق لم يحل مشكلتك ، كما تفعل ذلك على واجهة المنتهية ولايته.

Mason_D · May 1, 2022, 11:06pm

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

Billie_C · May 1, 2022, 11:11pm

هل يمكن للحاويات الخاصة بك التحدث على المنفذ 53?
تلنت 8.8.8.8 53

Miller_A · May 1, 2022, 11:16pm

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