VPN ಸೈಡ್ಕಾರ್ಗಾಗಿ ಕಿಲ್ ಸ್ವಿಚ್: ಹೊರಹೋದಾಗ ಟ್ರಾಫಿಕ್ ತಡೆಯಿರಿ

VPN ಕಂಟೇನರ್ನ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಹಂಚಿಕೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್ ಕಂಟೇನರ್ಗೆ ಸ್ವಂತ ಇಂಟರ್ಫೇಸ್ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಟನೆಲ್ ವಿಫಲವಾದಾಗ ಅದು ಏನನ್ನೂ ಕಳುಹಿಸಲಾರದು ಎಂದು ಭಾವಿಸುವುದು ಸುಲಭ. ಮುಖ್ಯವಾದ ವಿಫಲತೆ ಮೋಡ್ನಲ್ಲಿ ಆ ಊಹೆ ತಪ್ಪು. VPN ಪ್ರಕ್ರಿಯೆ ಸತ್ತರೂ ನೇಮ್ಸ್ಪೇಸ್ ಉಳಿದರೆ, ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಸಾಕೆಟ್ಗಳನ್ನು ಮತ್ತು ನೇಮ್ಸ್ಪೇಸ್ ತನ್ನ ಮಾರ್ಗಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಇನ್ನೂ ಸ್ಥಾಪಿತವಾದ ಮಾರ್ಗದಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಮುಂದುವರಿಯುತ್ತದೆ. ನಿಜವಾದ ಕಿಲ್ ಸ್ವಿಚ್ ಎಂದರೆ ಸ್ಪಷ್ಟ ಫಿಲ್ಟರಿಂಗ್ ನೀತಿ ಮತ್ತು ರನ್ಟೈಮ್ನ ಜೀವನಚಕ್ರದ ಪರೀಕ್ಷೆಗಳು, ಸ್ಟಾರ್ಟಪ್ ಅವಲಂಬನೆ ಅಲ್ಲ.

ನೇಮ್ಸ್ಪೇಸ್ ಹಂಚಿಕೊಳ್ಳುವುದು ಕಿಲ್ ಸ್ವಿಚ್ ಏಕೆ ಅಲ್ಲ

ನೇಮ್ಸ್ಪೇಸ್ ಹಂಚಿಕೊಳ್ಳುವುದು ಎಂದರೆ ಅಪ್ಲಿಕೇಶನ್ VPN ಕಂಟೇನರ್ನ ಇಂಟರ್ಫೇಸ್ಗಳು, ವಿಳಾಸಗಳು ಮತ್ತು ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ಬಳಸುತ್ತದೆ. ಹಂಚಿದ ನೇಮ್ಸ್ಪೇಸ್ ಸುರಕ್ಷಿತವಾಗಿರುವವರೆಗೆ ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವತಂತ್ರ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ ಮಾಯವಾದಾಗ ಆ ನೇಮ್ಸ್ಪೇಸ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಏನೂ ಹೇಳುವುದಿಲ್ಲ.

Compose ಅವಲಂಬನಾ ಷರತ್ತುಗಳು ಅವಲಂಬನೆ ಆರೋಗ್ಯಕರವಾಗುವವರೆಗೆ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭವನ್ನು ವಿಳಂಬಗೊಳಿಸಬಹುದು. ಇದು ಸಮಯದ ಒಂದು ಕ್ಷಣವನ್ನು ಮಾತ್ರ ಒಳಗೊಳ್ಳುತ್ತದೆ, ನಂತರದ ಯಾವುದೇ ವಿಫಲತೆಯನ್ನು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಇದು ಪ್ರಾರಂಭ ಕ್ರಮದ ಸಾಧನ, ನಿರಂತರ ಎಗ್ರೆಸ್ ಫೈರ್ವಾಲ್ ಅಲ್ಲ.

ಕಂಟೇನರ್ ಹೊರಹೋದಾಗ ನಿಜವಾಗಿ ಏನಾಗುತ್ತದೆ

ಮೂರು ಘಟನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ಕಂಟೇನರ್ನೊಳಗಿನ VPN ಪ್ರಕ್ರಿಯೆ ಕಂಟೇನರ್ ನಡೆಯುತ್ತಿದ್ದಂತೆಯೇ ಸಾಯಬಹುದು. ಕಂಟೇನರ್ ನಿಲ್ಲಬಹುದು ಅಥವಾ ತೆಗೆದುಹಾಕಬಹುದು, ಇದು ನೇಮ್ಸ್ಪೇಸ್ ನಾಶಮಾಡುತ್ತದೆ. ಕಂಟೇನರ್ ಮತ್ತೆ ರಚಿಸಬಹುದು, ಇದು ಹೊಸ ನೇಮ್ಸ್ಪೇಸ್ ಮತ್ತು ಹೊಸ ನಿಯಮಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ.

ಮೊದಲ ಸಂದರ್ಭದಲ್ಲಿ ನೇಮ್ಸ್ಪೇಸ್ ಮುಂದುವರಿಯುತ್ತದೆ, ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗ ಇನ್ನೂ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ಗೆ ತೋರಿಸಬಹುದು, ಅಪ್ಲಿಕೇಶನ್ ನೇರವಾಗಿ ಕಳುಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಎರಡನೇ ಸಂದರ್ಭದಲ್ಲಿ ಅವಲಂಬಿತ ಅಪ್ಲಿಕೇಶನ್ ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪರ್ಕವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ ಅದರ ನೇಮ್ಸ್ಪೇಸ್ ಮಾಯವಾಯಿತು. ಮೂರನೇ ಸಂದರ್ಭದಲ್ಲಿ ಟನೆಲ್ ಸಿದ್ಧವಾಗುವ ಮೊದಲೇ ಅಪ್ಲಿಕೇಶನ್ ಹೊಸ ನೇಮ್ಸ್ಪೇಸ್ಗೆ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಳ್ಳಬಹುದು. ಪ್ರತಿ ಸಂದರ್ಭಕ್ಕೂ ಬೇರೆ ಪರೀಕ್ಷೆ ಬೇಕು, ಮತ್ತು ಕೇವಲ ಕ್ರಮಬದ್ಧ ಡಿಸ್ಕನೆಕ್ಟ್ ಒಳಗೊಳ್ಳುವ ವಿನ್ಯಾಸ ಅತ್ಯಂತ ಕಡಿಮೆ ಆಸಕ್ತಿಕರ ಸಂದರ್ಭವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.

ಸ್ಪಷ್ಟ ಎಗ್ರೆಸ್ ನೀತಿ ನಿರ್ಮಿಸಿ

ನೀತಿಯನ್ನು ಹಂಚಿದ ನೇಮ್ಸ್ಪೇಸ್ನೊಳಗೆ ಬರೆಯಿರಿ, ಅದು ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ರೂಪ ಸಂಕುಚಿತ ವಿನಾಯಿತಿಗಳೊಂದಿಗೆ ಡಿಫಾಲ್ಟ್ ಡ್ರಾಪ್: loopback, ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್, ಮತ್ತು ಟನೆಲ್ ಸಾಗಣೆಗೆ ಬೇಕಾದ ನಿರ್ದಿಷ್ಟ ಎಂಡ್ಪಾಯಿಂಟ್ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್.

ಎಂಡ್ಪಾಯಿಂಟ್ ವಿನಾಯಿತಿ ಟನೆಲ್ ಮೇಲೇರುವ ಮೊದಲು ಇರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ VPN ಕ್ಲೈಂಟ್ ತನ್ನ ಸರ್ವರ್ ತಲುಪಲಾರದು. ಅದಕ್ಕೇ ನಿಯಮ ಸಮೂಹ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಅನುಮತಿ ನೀಡುವ ಬದಲು ಬಾಹ್ಯ ಸಾಗಣೆಗೆ ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮತಿ ನೀಡುತ್ತದೆ. ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ IPv6 ಸಂಪರ್ಕ ಇದ್ದರೆ IPv6 ನಿಯಮಗಳನ್ನೂ ಸೇರಿಸಿ, ಏಕೆಂದರೆ IPv4 ಮಾತ್ರ ಇರುವ ನೀತಿ ಇನ್ನೊಂದು ಕುಟುಂಬವನ್ನು ತೆರೆದಿಡುತ್ತದೆ.

DNS ಕೂಡ ನೀತಿಯ ಭಾಗ. ಅಪ್ಲಿಕೇಶನ್ ಟನೆಲ್ನೊಳಗೆ ಮಾತ್ರ ತಲುಪಬಹುದಾದ ರಿಜಾಲ್ವರ್ ಮೂಲಕ ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸಿದರೆ, ಟನೆಲ್ ಕೆಳಗಿರುವಾಗ ಡ್ರಾಪ್ ನಿಯಮ ಪರಿಹಾರವನ್ನು ಮುರಿಯುತ್ತದೆ, ಇದು ಕಿಲ್ ಸ್ವಿಚ್ಗೆ ಸರಿಯಾದ ನಡವಳಿಕೆ. ಇದೇ ನೀವು ಬಯಸುವುದೇ ಎಂದು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಧರಿಸಿ.

ಜೀವನಚಕ್ರ ಪರೀಕ್ಷಿಸಿ, ಕೇವಲ ಡಿಸ್ಕನೆಕ್ಟ್ ಅಲ್ಲ

ಟನೆಲ್ ಆರೋಗ್ಯಕರವಾಗಿರುವಾಗ ಹೊಸ ಹಾನಿರಹಿತ ವಿನಂತಿ ಕಳುಹಿಸಿ, ನಂತರ VPN ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಂದು ಇನ್ನೊಂದನ್ನು ಕಳುಹಿಸಿ. ಕಂಟೇನರ್ ನಿಂತ ನಂತರ, ಮರುಪ್ರಾರಂಭದ ನಂತರ ಮತ್ತು ಮತ್ತೆ ರಚಿಸಿದ ನಂತರ ಪುನರಾವರ್ತಿಸಿ. ಹೊಸ ವಿನಂತಿ ಮುಖ್ಯ ಏಕೆಂದರೆ ಹೊಸದನ್ನು ನಿರ್ಬಂಧಿಸುವ ನಿಯಮ ಬದಲಾವಣೆಯನ್ನು ಇರುವ ಸಂಪರ್ಕ ದಾಟಬಹುದು.

ನಿರ್ಬಂಧಿಸುವ ಕಾರ್ಯವಿಧಾನವಾಗಿ ಆರೋಗ್ಯ ಪರಿಶೀಲನೆ ಅಥವಾ ಎಗ್ರೆಸ್ IP ಹುಡುಕಾಟವನ್ನು ಅವಲಂಬಿಸಬೇಡಿ. ಪರಿಶೀಲನೆ ಸ್ಥಿತಿಯನ್ನು ಗಮನಿಸಿ ವರದಿ ಮಾಡುತ್ತದೆ; ನೀತಿ ಟ್ರಾಫಿಕ್ ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಎರಡೂ ಒಂದೇ ನಿಯೋಜನೆಯ ಭಾಗ, ಅವು ಒಂದಕ್ಕೊಂದು ಪರ್ಯಾಯವಲ್ಲ.

ನಿಯಮಗಳನ್ನು ದಾಖಲಿಸಿ, ಪರೀಕ್ಷೆ ನವೀಕರಣವನ್ನು ದಾಟಿ ಉಳಿಯುವಂತೆ

ಪ್ರತಿ ವಿಫಲತೆ ಸಂದರ್ಭದ ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶವನ್ನು ಅದನ್ನು ಜಾರಿಗೊಳಿಸುವ ನಿಯಮಗಳೊಂದಿಗೆ ನಿಯೋಜನೆ ದಾಖಲೆಯಲ್ಲಿ ಬರೆಯಿರಿ. ಆ ದಾಖಲೆ ಇಮೇಜ್ ನವೀಕರಣ ಅಥವಾ ರನ್ಟೈಮ್ ಅಪ್ಗ್ರೇಡ್ ನಂತರ ಅದೇ ಪರೀಕ್ಷೆಯನ್ನು ಚಲಾಯಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ನೇಮ್ಸ್ಪೇಸ್ ನಡವಳಿಕೆ ಅಥವಾ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗಗಳು ಯಾರೂ compose ಫೈಲ್ ಸಂಪಾದಿಸದೆಯೇ ಬದಲಾಗಬಹುದು.

VPN ಎಂಡ್ಪಾಯಿಂಟ್ನ ಅಗತ್ಯವಾದ ಬಾಹ್ಯ ಮಾರ್ಗವನ್ನು ಅಪ್ಲಿಕೇಶನ್ನ ಅಮಿತ ಎಗ್ರೆಸ್ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ, DNS ಮತ್ತು IPv6 ಅನ್ನು ಉದ್ದೇಶಿತ ವ್ಯಾಪ್ತಿಯೊಳಗೆ ಇರಿಸಿ. ನೀತಿ ಅನುಕೂಲಕ್ಕಾಗಿ ಸಂಪೂರ್ಣ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ಗೆ ಅನುಮತಿ ನೀಡಿದರೆ, ಕಿಲ್ ಸ್ವಿಚ್ ಹೋಗಿದೆ. Docker ನೆಟ್ವರ್ಕ್ ದಾಖಲೆ ನೀತಿ ನಿರ್ಮಿಸಿರುವ ಹಂಚಿದ ನೇಮ್ಸ್ಪೇಸ್ ವ್ಯವಸ್ಥೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ರನ್ಟೈಮ್ ನಡವಳಿಕೆ ಪ್ರಶ್ನಾರ್ಹವಾದಾಗ ಅದೇ ನೋಡಬೇಕಾದ ಉಲ್ಲೇಖ.