VPN ಕಂಟೇನರ್ನ ನೆಟ್ವರ್ಕ್ ಹಂಚಿಕೊಳ್ಳುವುದು: DNS ಗೆ ಏನಾಗುತ್ತದೆ

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

ಹಂತ 1: ಹೋಸ್ಟ್ನಿಂದ ಅಲ್ಲ, ಅಪ್ಲಿಕೇಶನ್ನಿಂದ ಪರೀಕ್ಷಿಸಿ

ಸಮಸ್ಯೆ ಇರುವ ಕಂಟೇನರ್ನ ಒಳಗೆ ಲುಕಪ್ ಚಲಾಯಿಸಿ, ಹೋಸ್ಟ್ನಲ್ಲಿ ಅಲ್ಲ ಮತ್ತು ಬ್ರೌಸರ್ನಲ್ಲಿ ಅಲ್ಲ. docker exec app-container getent hosts db.internal ಮುಖ್ಯವಾದ ಏಕೈಕ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಪ್ರಕ್ರಿಯೆಯ ರಿಜಾಲ್ವರ್ ಏನನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

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

ಹಂತ 2: ರನ್ಟೈಮ್ನ ಬೆಂಬಲಿತ ಮಾದರಿಯನ್ನು ಓದಿ

Docker ನ ನೆಟ್ವರ್ಕ್ ದಾಖಲೆ ಇನ್ನೊಂದು ಕಂಟೇನರ್ನ ನೆಟ್ವರ್ಕ್ ಮೋಡ್ ಹಂಚಿಕೊಳ್ಳುವ ಕಂಟೇನರ್ಗಳ DNS ಫ್ಲ್ಯಾಗ್ಗಳ ಮೇಲಿನ ನಿರ್ಬಂಧಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ. Compose ನಲ್ಲಿ network_mode: service:vpn ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು VPN ಕಂಟೇನರ್ನ ನೇಮ್ಸ್ಪೇಸ್ಗೆ ಬಂಧಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಸೇವೆಗೆ dns ಸೆಟ್ಟಿಂಗ್ಗಳು ಸಾಮಾನ್ಯ ಸೇವೆಯಂತೆ ವರ್ತಿಸುವುದಿಲ್ಲ. ನೀವು ಪಡೆಯುವ ಪರಿಹಾರವೇ ಹಂಚಿದ ನೇಮ್ಸ್ಪೇಸ್ ಹೊಂದಿರುವ ಪರಿಹಾರ.

ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ ಬ್ರಿಡ್ಜ್ ನೆಟ್ವರ್ಕ್ಗಳು ಸಹ Docker ನ ಒಳಗೊಂಡಿರುವ DNS ಅನ್ನು ಡಿಫಾಲ್ಟ್ ಬ್ರಿಡ್ಜ್ಗಿಂತ ವಿಭಿನ್ನವಾಗಿ ಬಳಸುತ್ತವೆ. ಆದ್ದರಿಂದ dns ಕೆಲಸ ಮಾಡುವ ಬ್ರಿಡ್ಜ್ ಉದಾಹರಣೆಯಿಂದ ನಕಲಿಸಿದ ಷರತ್ತು ಹಂಚಿದ ಸ್ಟ್ಯಾಕ್ನಲ್ಲಿ ಏನನ್ನೂ ಮಾಡದಿರಬಹುದು. ಷರತ್ತನ್ನು ನಕಲಿಸುವ ಮೊದಲು ವ್ಯವಸ್ಥೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.

ಲೂಪ್ಬ್ಯಾಕ್ ವಿಳಾಸ ಯಾವಾಗಲೂ ಸಂಬಂಧಿತ ನೆಟ್ವರ್ಕ್ ಸಂದರ್ಭವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಹಂಚಿದ ನೇಮ್ಸ್ಪೇಸ್ನ ಒಳಗೆ, 127.0.0.1 ಹೋಸ್ಟ್ನ ರಿಜಾಲ್ವರ್ ಅಲ್ಲ.

ಹಂತ 3: ಪ್ರಶ್ನೆಯನ್ನು ಅದರ ಸ್ವೀಕರಿಸುವವರವರೆಗೆ ಅನುಸರಿಸಿ

ಅಪ್ಲಿಕೇಶನ್ನ ರಿಜಾಲ್ವರ್ ಸಂರಚನೆಯನ್ನು ಓದಿ, ನಂತರ ಅಪ್ಲಿಕೇಶನ್ನೊಂದಿಗೆ ಬರುವ ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್-ನಿರ್ದಿಷ್ಟ ಎನ್ಕ್ರಿಪ್ಟ್ ಆದ DNS ಅನ್ನು ಓದಿ, ಏಕೆಂದರೆ ತನ್ನದೇ ರಿಜಾಲ್ವರ್ ಚಲಾಯಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ನೀವು ಸಂಪಾದಿಸಿದ ಫೈಲ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ನಂತರ ಆಯ್ಕೆಮಾಡಿದ ರಿಜಾಲ್ವರ್ VPN ನ ಮಾರ್ಗಗಳು ಮತ್ತು ಫೈರ್‌ವಾಲ್ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ತಲುಪಬಹುದೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಟನೆಲ್ನ ಆಚೆ ಬದಿಯಲ್ಲಿರುವ ರಿಜಾಲ್ವರ್ ವಿಳಾಸವು ನೇಮ್ಸ್ಪೇಸ್ಗೆ ಅಲ್ಲಿಗೆ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ ನಿಷ್ಪ್ರಯೋಜಕ. ಯಾವುದೇ ಫೈಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಸ್ವೀಕರಿಸುವವರನ್ನು ದೃಢೀಕರಿಸಿ.

ಬ್ರೌಸರ್ನ IP-ಪರಿಶೀಲನಾ ಪುಟವು ಹೆಸರಿನ ಪ್ರಶ್ನೆಗಳು ಎಲ್ಲಿಗೆ ಹೋದವು ಎಂದು ಹೇಳಲಾರದು. ಅದು ಒಂದು HTTP ಸಂಪರ್ಕ ಎಲ್ಲಿಗೆ ಹೋಯಿತು ಎಂದು ಹೇಳುತ್ತದೆ.

ಹಂತ 4: ಎರಡು ವೈಫಲ್ಯ ವರ್ಗಗಳನ್ನು ಬೇರೆಯಾಗಿ ಸರಿಪಡಿಸಿ

ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ ಸೇವಾ ಹೆಸರುಗಳು ವಿಫಲವಾದರೆ, ಸಮಸ್ಯೆ ಕಂಟೇನರ್ ನೆಟ್ವರ್ಕ್ನ ಒಳಗಿನ ಸೇವಾ ಅನ್ವೇಷಣೆಯಲ್ಲಿದೆ, ಸಾರ್ವಜನಿಕ ರಿಜಾಲ್ವರ್ ಪಟ್ಟಿಯಲ್ಲಿಲ್ಲ. ಪ್ರತಿ ಸಾರ್ವಜನಿಕ DNS ವಿಳಾಸವನ್ನು ಬದಲಿಸುವುದರಿಂದ ನೆಟ್ವರ್ಕ್ನ ಅನ್ವೇಷಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಎಂದಿಗೂ ಕೇಳದ ದಾಖಲೆಗಳು ಸೃಷ್ಟಿಯಾಗುವುದಿಲ್ಲ.

ಎರಡೂ ವರ್ಗಗಳು ವಿಫಲವಾದರೆ, ರಿಜಾಲ್ವರ್ಗೆ ತಲುಪುವಿಕೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಒಂದೇ ವಿಫಲವಾದರೆ, ಅನ್ವೇಷಣಾ ವ್ಯವಸ್ಥೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಎರಡಕ್ಕೂ ವಿಭಿನ್ನ ಮಾಲೀಕರಿದ್ದಾರೆ, ಆದ್ದರಿಂದ ಒಂದು ದುರಸ್ತಿ ಎರಡನ್ನೂ ಎಂದಿಗೂ ಆವರಿಸುವುದಿಲ್ಲ.

ಹಂತ 5: ಮರುಸೃಷ್ಟಿಯ ನಂತರ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ

ರನ್ಟೈಮ್ನ ಬೆಂಬಲಿತ ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ ಸಂರಚನೆಯನ್ನು ಬದಲಿಸಿ, ನಂತರ ಚಾಲನೆಯಲ್ಲಿರುವ ಕಂಟೇನರ್ ಒಳಗಿನ ಫೈಲ್ಗಳನ್ನು ಸಂಪಾದಿಸುವ ಬದಲು ಕಂಟೇನರ್ಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಿ. ಹೊಸ ಖಾಸಗಿ ಹೆಸರು, ಹೊಸ ಸಾರ್ವಜನಿಕ ಹೆಸರು ಮತ್ತು ಲುಕಪ್ ನಂತರ ಬರುವ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ. /etc/resolv.conf ಕಂಟೇನರ್ ಒಳಗಿನ ಸಂಪಾದನೆ ಮರುಸೃಷ್ಟಿಯಲ್ಲಿ ಮಾಯವಾಗುತ್ತದೆ ಮತ್ತು ದುರಸ್ತಿ ಕೆಲಸ ಮಾಡದಿದ್ದಾಗಲೂ ಅದು ಕೆಲಸ ಮಾಡಿತು ಎಂದು ನಿಮ್ಮನ್ನು ನಂಬಿಸುತ್ತದೆ.

ಹಂಚಿದ ನೆಟ್ವರ್ಕ್ ವ್ಯಾಖ್ಯಾನದ ಪಕ್ಕದಲ್ಲಿ ರಿಜಾಲ್ವರ್ನ ಮಾಲೀಕ ಮತ್ತು ನಿರೀಕ್ಷಿತ ನೇಮ್ಸ್ಪೇಸ್ ಅನ್ನು ದಾಖಲಿಸಿ. ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಎರಡೂ ಬೇಕಾಗುತ್ತವೆ.