Docker ಕಂಟೇನರ್ ಸಂಚಾರವು ಹೋಸ್ಟ್ VPN ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ: ಪರಿಶೀಲಿಸುವ ವಿಧಾನ
ಹೋಸ್ಟ್ VPN ಕೇವಲ ಹೋಸ್ಟ್ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಅನ್ನು ಆವರಿಸುತ್ತದೆ. ಬ್ರಿಡ್ಜ್ನಲ್ಲಿರುವ ಕಂಟೇನರ್ ಸಂಚಾರವು ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆಯೇ ಅಥವಾ ನೇರವಾಗಿ ಹೊರಹೋಗುತ್ತದೆಯೇ ಎಂದು ತಿಳಿಯಲು ಈ ಪರಿಶೀಲನೆಗಳನ್ನು ಬಳಸಿ.
ಹೋಸ್ಟ್ನಲ್ಲಿರುವ ನಿಮ್ಮ ಬ್ರೌಸರ್ VPN ನ ನಿರ್ಗಮನ ವಿಳಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ, ಕಂಟೇನರ್ ನಿಮ್ಮ ಮನೆಯ ಸಂಪರ್ಕವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಯಾರೋ ಅದನ್ನು ಸೋರಿಕೆ ಎಂದು ಕರೆಯುತ್ತಾರೆ. ಏನೂ ಸೋರಿಲ್ಲ. ಹೋಸ್ಟ್ ಸುರಂಗವು ಹೋಸ್ಟ್ನ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ಗೆ ಸೇರಿದ ಇಂಟರ್ಫೇಸ್ಗಳು, ಮಾರ್ಗಗಳು ಮತ್ತು ನಿಯಮಗಳ ಗುಂಪು, ಮತ್ತು ಬ್ರಿಡ್ಜ್ನಲ್ಲಿರುವ ಕಂಟೇನರ್ ತನ್ನದೇ ಆದ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಹೊಂದಿರುವ ಬೇರೆ ನೇಮ್ಸ್ಪೇಸ್ ಆಗಿದೆ. VPN ಕ್ಲೈಂಟ್ ವಾರಗಳ ಕಾಲ ಸಂಪರ್ಕದಲ್ಲಿದ್ದರೂ ಒಂದೂ ಕಂಟೇನರ್ ಪ್ಯಾಕೆಟ್ ಎಂದೂ ಒಳಗೆ ಬಾರದ Compose ಸ್ಟಾಕ್ನಲ್ಲಿ ನಾನು ಕುಳಿತಿದ್ದೇನೆ.
ಟ್ರೇ ಐಕಾನ್ಗಿಂತ ಮೊದಲು ನೇಮ್ಸ್ಪೇಸ್ ಪರಿಶೀಲಿಸಿ
ನೇಮ್ಸ್ಪೇಸ್ಗಳೇ ಇಡೀ ವಾದ. Docker ಬ್ರಿಡ್ಜ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಕಂಟೇನರ್ ಪ್ರಾರಂಭಿಸಿದಾಗ, ಅದು ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ರಚಿಸುತ್ತದೆ, veth ಜೋಡಿಯ ಒಂದು ತುದಿಯನ್ನು ಅದರೊಳಗೆ ಜೋಡಿಸುತ್ತದೆ, ಮತ್ತು ಆ ನೇಮ್ಸ್ಪೇಸ್ಗೆ ವಿಳಾಸ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ. ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್, ಅದನ್ನು ಏನೇ ಕರೆದರೂ, ಹೋಸ್ಟ್ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ ಜೀವಿಸುತ್ತದೆ. ಕಂಟೇನರ್ ಒಳಗಿನ ಸಂಚಾರವು ಅದನ್ನು ನೋಡಲಾರದು, ಮತ್ತು ಹೊರಗಿನಿಂದ ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಸೆಟ್ಟಿಂಗ್ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.
ಪ್ರತ್ಯೇಕತೆಯಿಂದ ಹೊರಬರಲು ಎರಡು ಬೆಂಬಲಿತ ಕ್ರಮಗಳಿವೆ. --network host ಕಂಟೇನರ್ ಅನ್ನು ಹೋಸ್ಟ್ ನೇಮ್ಸ್ಪೇಸ್ ಒಳಗೆ ಇಡುತ್ತದೆ, ಹಾಗಾಗಿ ಅದು ಹೋಸ್ಟ್ನ ಮಾರ್ಗಗಳನ್ನು ಮತ್ತು ಆ ಮೂಲಕ ಸುರಂಗವನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ. --network container:vpn ಇನ್ನೊಂದು ಕಂಟೇನರ್ನ ನೇಮ್ಸ್ಪೇಸ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಹೆಚ್ಚಿನ ಸೈಡ್ಕಾರ್ ವಿನ್ಯಾಸಗಳು ಕೆಲಸದ ಹೊರೆಯನ್ನು VPN ಕಂಟೇನರ್ ಮೂಲಕ ಕಳುಹಿಸುವುದು ಹೀಗೆಯೇ. ಎರಡೂ ಸ್ಪಷ್ಟ ಆಯ್ಕೆಗಳು; ಸಾಮಾನ್ಯವಾಗಿ ಅವುಗಳಲ್ಲಿ ಒಂದೇ ನಿಯೋಜಿಸುವವರ ಉದ್ದೇಶವಾಗಿರುತ್ತದೆ.
ಹೋಸ್ಟ್ ಮೋಡ್ ಉಚಿತ ಅಪ್ಗ್ರೇಡ್ ಅಲ್ಲ. ಕಂಟೇನರ್ ತನ್ನದೇ ವಿಳಾಸವನ್ನು ಹೊಂದುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಪೋರ್ಟ್ ಪ್ರಕಟಣೆ ಅನ್ವಯವಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಅಲ್ಲಿ NET_ADMIN ಹೊಂದಿರುವ ಪ್ರಕ್ರಿಯೆಯು ಹೋಸ್ಟ್ನ ರೂಟಿಂಗ್ ಅನ್ನು ಮರುಬರೆಯಬಹುದು. ಅದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದು ಸರಿಯಾದ ನಿರ್ಧಾರವಾಗಿರಬಹುದು. ಅದು ಈಗಾಗಲೇ ಆನ್ ಆಗಿದೆ ಎಂದು ಊಹಿಸುವುದು, ಎಂದೂ ಮಾರ್ಗದಲ್ಲಿ ಇಲ್ಲದ ಸುರಂಗವನ್ನು ಜನರು ಸಂಜೆ ಡೀಬಗ್ ಮಾಡಲು ಕಾರಣ.
ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸೇತುವೆಯಿಂದ ಹೊರಗೆ ಅನುಸರಿಸಿ
ಬ್ರಿಡ್ಜ್ ಕಂಟೇನರ್ ತನ್ನ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ತನ್ನ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಅದು ಹೋಸ್ಟ್ನಲ್ಲಿರುವ ಬ್ರಿಡ್ಜ್ ಇಂಟರ್ಫೇಸ್. ನಂತರ ಹೋಸ್ಟ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಸಂರಚನೆಯಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ಹೊರಡುವ ಮೊದಲು ಮೂಲ ವಿಳಾಸವನ್ನು ತನ್ನ ವಿಳಾಸಕ್ಕೆ ಅನುವಾದಿಸುತ್ತದೆ. ಆ ಅನುವಾದದ ಹಂತವೇ ನೀತಿಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಸೋಲಿಸುತ್ತದೆ.
ಪ್ಯಾಕೆಟ್ ಸುರಂಗದ ಅಂತ್ಯದ ಬಿಂದುವನ್ನು ತಲುಪುವಾಗ ಅದು ಹೋಸ್ಟ್ನ ವಿಳಾಸವನ್ನು ಹೊತ್ತಿರುತ್ತದೆ. ಕಂಟೇನರ್ನ ಮೂಲ ವಿಳಾಸವನ್ನು ಆಧರಿಸಿದ ಯಾವುದೇ ನಿಯಮ, ನೀತಿ ಮಾರ್ಗ ಅಥವಾ ವಿಭಜಿತ ಸುರಂಗ ನಿರ್ಧಾರವು ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಮತ್ತು ಬೇರೆ ಬೇರೆ ನಿರ್ಗಮನಗಳ ಮೂಲಕ ಹೋಗಬೇಕಾದ ಎರಡು ಕಂಟೇನರ್ಗಳನ್ನು ಕೇವಲ ಮೂಲದಿಂದ ಬೇರ್ಪಡಿಸಲಾಗದು. ನಿಮಗೆ ಪ್ರತಿ-ಕಂಟೇನರ್ ರೂಟಿಂಗ್ ಬೇಕಾದರೆ, ನಿರ್ಧಾರವು ಅನುವಾದಕ್ಕೆ ಮೊದಲು ಅಥವಾ ನೀವು ನಿಯಂತ್ರಿಸುವ ನೇಮ್ಸ್ಪೇಸ್ ಒಳಗೆ ಆಗಬೇಕು.
Docker ಈ ನಿಯಮಗಳನ್ನು ತಾನೇ ನಿರ್ವಹಿಸುತ್ತದೆ, ಡೀಮನ್ ಯಾವ ಫೈರ್ವಾಲ್ ಬ್ಯಾಕೆಂಡ್ನೊಂದಿಗೆ ಸಂರಚಿಸಲ್ಪಟ್ಟಿದೆಯೋ ಅದರ ಮೂಲಕ. ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಸಂಚಾರಕ್ಕಾಗಿ ಬೆಂಬಲಿತ ಹುಕ್ನ ಹೊರಗೆ ಕೈಯಿಂದ ಬರೆದ ನಿಯಮಗಳು, DOCKER-USER, ಡೀಮನ್ ಮರುಪ್ರಾರಂಭವಾದಾಗ ಅಥವಾ ಹೋಸ್ಟ್ ಅಪ್ಗ್ರೇಡ್ ಆದಾಗ ಮರುಕ್ರಮಗೊಳಿಸಬಹುದು ಅಥವಾ ತೆಗೆದುಹಾಕಬಹುದು. ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರಿಂಗ್ ಕುರಿತ Docker ದಸ್ತಾವೇಜು ಸರಪಳಿಗಳ ಕ್ರಮವನ್ನು ತೋರಿಸುತ್ತದೆ; ಪ್ರಾಯೋಗಿಕ ಅಂಶವೆಂದರೆ ಪ್ರತಿ ನಿಯಮಕ್ಕೂ ಮಾಲೀಕರು ಮತ್ತು ನೀವು ನಿಜವಾಗಿ ಪರೀಕ್ಷಿಸಿದ ಮರುಲೋಡ್ ಮಾರ್ಗ ಬೇಕು.
ಎರಡು ವ್ಯವಸ್ಥೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ
ಒಂದು ನೇಮ್ಸ್ಪೇಸ್ನ ಸಾಕ್ಷ್ಯವು ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. VPN ಕಂಟೇನರ್ ಒಳಗೆ ಚಲಾಯಿಸಿದ ವಿನಂತಿಯು ಆ ಕಂಟೇನರ್ಗೆ ಸುರಂಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅದು ಹೋಸ್ಟ್ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯವಲ್ಲ, ಮತ್ತು --network host ಕಂಟೇನರ್ನಿಂದ ಚಲಾಯಿಸಿದ ಅದೇ ಆಜ್ಞೆ ಸೇತುವೆ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯವಲ್ಲ.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'
ನಂತರ ಪರೀಕ್ಷೆಯನ್ನು ಹೋಲುವ ಇಮೇಜ್ನಲ್ಲಿ ಅಲ್ಲ, ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ ಕಂಟೇನರ್ ಒಳಗೆ ಪುನರಾವರ್ತಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ ಹೆಚ್ಚುವರಿ ಮಾರ್ಗ, ಪ್ರಾಕ್ಸಿ ಪರಿಸರ ಚರ ಅಥವಾ ಬೇರೆ ರಿಸಾಲ್ವರ್ ಹೊಂದಿರಬಹುದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಉತ್ತರವನ್ನು ಬದಲಿಸುತ್ತದೆ. ಪ್ರತಿ ಬಾರಿ ಹೆಸರು ವಿಭೇದನ ಮತ್ತು ಎರಡನೇ ವಿಳಾಸ ಕುಟುಂಬವನ್ನು ಪರಿಶೀಲಿಸಿ: ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ ಬ್ರಿಡ್ಜ್ಗಳಲ್ಲಿನ ಕಂಟೇನರ್ಗಳು Docker ನ ಒಳನಿರ್ಮಿತ ರಿಸಾಲ್ವರ್ ಮೂಲಕ 127.0.0.11 ನಲ್ಲಿ ವಿಭೇದಿಸಲ್ಪಡುತ್ತವೆ, ಮತ್ತು ಸೇತುವೆಯಲ್ಲಿನ IPv6 ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವು ನೀವು IPv4 ಮಾತ್ರದ ಸುರಂಗವನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿರುವಾಗ ಸಂಚಾರವನ್ನು ಹೊರಗೆ ಕೊಂಡೊಯ್ಯಬಹುದು.
ರುಜುವಾತುಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಮಾದರಿಯನ್ನು ಓದಿ
ಹೋಸ್ಟ್ ಕೆಲಸ ಮಾಡಿ ಕಂಟೇನರ್ ಮಾಡದಿದ್ದಾಗ, ಕಾರಣ ಬಹುತೇಕ ಯಾವಾಗಲೂ ರಚನಾತ್ಮಕವಾಗಿರುತ್ತದೆ, ಮತ್ತು ಕೀಗಳನ್ನು ತಿರುಗಿಸುವುದು ಅಥವಾ ಕ್ಲೈಂಟ್ ಮರುಸ್ಥಾಪಿಸುವುದು ಮಧ್ಯಾಹ್ನವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ಮೊದಲು ಲಕ್ಷಣವನ್ನು ವಿಂಗಡಿಸಿ ಮತ್ತು ಪರಿಹಾರ ಸಾಮಾನ್ಯವಾಗಿ ತನ್ನ ಹೆಸರನ್ನು ತಾನೇ ಹೇಳುತ್ತದೆ.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
ಅತಿವ್ಯಾಪ್ತಿಯ ಸಾಲಿಗೆ ತನ್ನದೇ ವಾಕ್ಯ ಅರ್ಹ. 172.17.0.0/16 ಗೆ, ಅಥವಾ ನಿಮ್ಮ ಸೇತುವೆ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಆಕಸ್ಮಿಕವಾಗಿ ಹೊಂದಿರುವ 10.0.0.0/8 ಗೆ ಮಾರ್ಗವನ್ನು ತಳ್ಳುವ VPN ಪ್ರೊಫೈಲ್ ಸುರಂಗವು ಕಂಟೇನರ್ ಉಪಜಾಲವನ್ನು ಕ್ಲೇಮ್ ಮಾಡುವಂತೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅನುವಾದಿತ ವಿಳಾಸಗಳಿಗೆ ಹೋಗುವ ಪ್ರತ್ಯುತ್ತರಗಳು ತಪ್ಪು ದಿಕ್ಕಿಗೆ ಹೋಗುತ್ತವೆ ಅಥವಾ ಮಾಯವಾಗುತ್ತವೆ. Docker ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಅಪವಾದಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದಕ್ಕಿಂತ ಸ್ವಚ್ಛವಾಗಿದೆ.
ವ್ಯಾಪ್ತಿಯನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸಿ, ನಂತರ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅದನ್ನು ಮುರಿಯಿರಿ
ಎರಡು ವಿನ್ಯಾಸಗಳು ಪರಿಶೀಲನೆಯಲ್ಲಿ ನಿಲ್ಲುತ್ತವೆ. VPN ಕಂಟೇನರ್ನ ನೇಮ್ಸ್ಪೇಸ್ ಹಂಚಿಕೊಳ್ಳಿ ಮತ್ತು ಆವರಿಸಿದ ಪ್ರತಿ ಕೆಲಸದ ಹೊರೆಯೂ ಒಂದೇ ಮರುಪ್ರಾರಂಭದ ಗಡಿಯೊಂದಿಗೆ ಒಂದೇ ಸುರಂಗ ಬಳಸುತ್ತದೆ, ಇದು ಒಂದು ಸೇವೆಗೆ ಬೇರೆ ನಿರ್ಗಮನ ಅಥವಾ ತನ್ನದೇ DNS ಮಾರ್ಗ ಬೇಕಾಗುವವರೆಗೆ ಸರಳ. ಅಥವಾ ಕಂಟೇನರ್ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹೋಸ್ಟ್ನಲ್ಲಿರುವ VPN ಗೇಟ್ವೇಗೆ ರೂಟ್ ಮಾಡಿ: ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆ ಸಕ್ರಿಯ, ಸೇತುವೆ ಪೂರ್ವಪ್ರತ್ಯಯ ಸುರಂಗದ ಕಡೆಗೆ, ಹಿಂತಿರುಗುವ ಸಂಚಾರ ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ವಹಿಸಲಾಗಿದೆ. ಇದು ಪ್ರತಿ ನೆಟ್ವರ್ಕ್ಗೆ ನಿಯಂತ್ರಣವನ್ನು ಖರೀದಿಸುತ್ತದೆ ಮತ್ತು ಡೀಮನ್ ಹಾಗೂ ಕ್ಲೈಂಟ್ ಅಪ್ಗ್ರೇಡ್ಗಳ ಉದ್ದಕ್ಕೂ ನಿರ್ವಹಿಸಬೇಕಾದ ನಿಯಮಗಳ ಗುಂಪನ್ನು ನಿಮಗೆ ತೆರಬೇಕಾಗುತ್ತದೆ.
ಹೇಗಾದರೂ, ಮುಖ್ಯವಾದ ಪರೀಕ್ಷೆ ವೈಫಲ್ಯದ ಸಂದರ್ಭ. ಕಂಟೇನರ್ ವಿನಂತಿ ಗಾಳಿಯಲ್ಲಿರುವಾಗ ಸುರಂಗವನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ನೋಡಿ. ಅದು ನೇರ ಮಾರ್ಗಕ್ಕೆ ಹಿಂತಿರುಗಿದರೆ, ವ್ಯಾಪ್ತಿ ಎಂದೂ ಜಾರಿಗೊಳಿಸಲ್ಪಟ್ಟಿಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ನ kill switch ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಸಂಚಾರವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ, ಸೇತುವೆಯಿಂದ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನಲ್ಲ. ನಂತರ ಡೀಮನ್ ಮತ್ತು ಹೋಸ್ಟ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಎರಡನೇ ಬಾರಿ ಖಚಿತಪಡಿಸಿ; ಕೈಯಿಂದ ಬರೆದ ನಿಯಮಗಳು ಮಾಯವಾಗುವ ಕ್ಷಣ ಅದೇ.
ಅದನ್ನು ಮುಗಿದಿದೆ ಎಂದು ಹೇಳುವ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಖಚಿತಪಡಿಸಿ: ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್ ಸಂಚಾರದಂತೆಯೇ ಅದೇ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿದೆ, ಕಂಟೇನರ್ ಪರೀಕ್ಷೆ ನಿಜವಾದ ಕಂಟೇನರ್ ಒಳಗೆ ನಡೆಯಿತು, ಹೆಸರು ವಿಭೇದನ ಮತ್ತು ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಪರಿಶೀಲಿಸಲಾಯಿತು, ಮತ್ತು ಸುರಂಗ-ವೈಫಲ್ಯ ಪರೀಕ್ಷೆ ಇನ್ನೂ ಮುಚ್ಚಿದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ನಂತರ ಫೈರ್ವಾಲ್ ಬ್ಯಾಕೆಂಡ್, ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿ ಮತ್ತು ಪ್ರತಿ ನಿಯಮದ ಮಾಲೀಕರನ್ನು ಬರೆಯಿರಿ. ಆ ದಾಖಲೆಯೇ ಮುಂದಿನ ಅಪ್ಗ್ರೇಡ್ ಹಳೆಯ ಊಹೆಗಳ ದಾಖಲೆಯಾಗದ ಮಿಶ್ರಣವನ್ನು ಬಿಡದಂತೆ ತಡೆಯುತ್ತದೆ.