פֿאַר אַ נאָמענטוים וואָס איז שוין פֿאַראַן אין /run/netns/proxy-egress, פֿאַרבעט דאָס אַרײַן אין דעם עקסיסטירנדיקן drop-in פֿון דער Squid־סערוויס:

[Service]
NetworkNamespacePath=/run/netns/proxy-egress

שטעלט די סערוויס נאָך דער קאָמפּאָנענט וואָס שאַפֿט דעם נאָמענטוים. די איינשטעלונג שאַפֿט ווידער דעם נאָמענטוים נישט, און אויך נישט זיינע אינטערפֿייסן, אַדרעסן אָדער רוטעס.

סיי דער צוהער־סאָקעט סיי דער אַרויסגאַנג־סאָקעט זענען איצט דאָרט. קליענטן דאַרפֿן אַ וועג צו יענעם צוהערער און זיין אויפֿגעהיטע צוטריט־פּאָליטיק; דער loopback פֿון דעם האָסט איז נישט אויטאָמאַטיש דער loopback פֿון דעם נאָמענטוים.

Resolver־טעקעס דאַרפֿן באַזונדערע אויפֿמערקזאַמקייט. אַנדערש ווי ip netns exec מאָונטעט די נעץ־איינשטעלונג נישט קיין /etc/netns/NAME־טעקעס איבער זייערע געוויינטלעכע וועגן. ווען דער אײַנזאַץ דאַרפֿט די resolver־טעקע פֿון זיין נאָמענטוים:

BindReadOnlyPaths=/etc/netns/proxy-egress/resolv.conf:/etc/resolv.conf

ניצט resolver־אַדרעסן וואָס זענען דערגרייַכיק פֿון יענעם נאָמענטוים און פֿאַרבעט זיי מיט די עקסיסטירנדיקע sandbox/טעקע־סיסטעם כּללים. בלויז בינדן Squid ס אַרויסגאַנג־קוואַל־אַדרעס שטעלט נישט דעם פּראָצעס אין דעם קאָנטעקסט.

פֿאַרבונדענע אַרטיקלען