Docker: VPN ಸೆಷನ್ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ಪೂರ್ವನಿರ್ಧರಿತ ವಿಳಾಸ ಪೂಲ್‌ಗಳು ಉಳಿದಿಲ್ಲ
ಪೂರ್ವನಿರ್ಧರಿತ-ಪೂಲ್ ದೋಷವು ಸ್ವಯಂಚಾಲಿತ ಹಂಚಿಕೆಗೆ ಸಂಬಂಧಿಸಿದೆ, ಸಾರ್ವಜನಿಕ ವಿಳಾಸಗಳಿಗಲ್ಲ. ಹಂಚಿಕೆಗಳನ್ನು ಎಣಿಸಿ, ಆನ್-ಲಿಂಕ್ ಮಾರ್ಗಗಳನ್ನು ಹೋಲಿಸಿ ಮತ್ತು VPN ನೀತಿಯನ್ನು ಅಕ್ಷತವಾಗಿ ಇರಿಸಿ.
ವೈಫಲ್ಯವು ನಿರ್ದಿಷ್ಟವಾಗಿದೆ: ಹೊಸ ಬ್ರಿಡ್ಜ್ ನೆಟ್‌ವರ್ಕ್‌ಗಾಗಿ Docker ಸ್ವೀಕಾರಾರ್ಹ ಸ್ವಯಂಚಾಲಿತ ಸಬ್‌ನೆಟ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ಯಂತ್ರದ ವಿಳಾಸಗಳು ಖಾಲಿಯಾದವು ಎಂದು ಅರ್ಥವಲ್ಲ, ಮತ್ತು VPN ಮುರಿದಿದೆ ಎಂದೂ ಅರ್ಥವಲ್ಲ. ರೋಗನಿರ್ಣಯವನ್ನು ಎರಡು ಪ್ರಶ್ನೆಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ: ಡೀಮನ್ ಯಾವ ಅಭ್ಯರ್ಥಿ ಬ್ಲಾಕ್‌ಗಳನ್ನು ನೋಡಬಲ್ಲದು, ಮತ್ತು ಈ ಪರಿಸರದಲ್ಲಿ ಅದರ ಹಂಚಿಕೆದಾರ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನು ಹೊರಗಿಡುತ್ತದೆ. ಅವುಗಳನ್ನು ಅದೇ ಕ್ರಮದಲ್ಲಿ ನಿಭಾಯಿಸಿ, ಏಕೆಂದರೆ ಮೊದಲ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವವರೆಗೆ ಎರಡನೇ ಪ್ರಶ್ನೆಗೆ ಅರ್ಥವಿಲ್ಲ.
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಏನು ವಿಫಲವಾಯಿತು ಎಂದು ದೃಢೀಕರಿಸಿ
ಕೆಳಗಿನ ಹಂತಗಳನ್ನು ಡೀಮನ್ ಚಲಾಯಿಸುವ ಹೋಸ್ಟ್‌ನಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಿ. ದೂರದ ಸಂದರ್ಭದೊಂದಿಗೆ ಮಾತನಾಡುವ ಶೆಲ್ ಬೇರೊಂದು ಯಂತ್ರವನ್ನು ವಿವರಿಸುತ್ತಿದೆ, ಮತ್ತು ಆ ಒಂದು ತಪ್ಪು ಒಂದು ಗಂಟೆಯನ್ನು ವ್ಯರ್ಥ ಮಾಡಬಹುದು.
ಅದೇ ಸಮಯದಲ್ಲಿ ಟಿಕೆಟ್‌ನಲ್ಲಿ Engine ಆವೃತ್ತಿಯನ್ನು ದಾಖಲಿಸಿ. ಈ ರನ್‌ಬುಕ್‌ನ ಉಳಿದ ಭಾಗದ ಪ್ರತಿಯೊಂದು ಹ್ಯೂರಿಸ್ಟಿಕ್ ಆವೃತ್ತಿ-ಸೀಮಿತವಾಗಿದೆ, ಮತ್ತು ಆವೃತ್ತಿ ಇಲ್ಲದ ಹೇಳಿಕೆ ವದಂತಿ.
ನೀವು ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಹಂಚಿಕೆಗಳನ್ನು ಎಣಿಸಿ
ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ, ನಂತರ ಮುಖ್ಯವಾದವುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ: docker network ls, ನಂತರ docker network inspect NETWORK_NAME. ಅವುಗಳ IPAM ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಜೋಡಿಸಲಾದ ಕಂಟೇನರ್‌ಗಳನ್ನು ಓದಿ. ಹಲವು Compose ಯೋಜನೆಗಳು ತಮ್ಮ ಕಂಟೇನರ್ ಎಣಿಕೆ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬ್ಲಾಕ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ಯೋಜನೆಯೂ ತನ್ನದೇ ಆದ ಡೀಫಾಲ್ಟ್ ನೆಟ್‌ವರ್ಕ್ ರಚಿಸಲು ಒಲವು ತೋರುತ್ತದೆ. ನಿಲ್ಲಿಸಿದ ಕಂಟೇನರ್ ತನ್ನ ನೆಟ್‌ವರ್ಕ್‌ನ ಹಂಚಿಕೆಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವುದಿಲ್ಲ.
ಪೂಲ್ ಸಂರಚನೆಯನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಡೀಫಾಲ್ಟ್ ಪೂಲ್‌ಗೆ ಮೂಲ ಶ್ರೇಣಿ ಮತ್ತು ಪ್ರತಿ-ನೆಟ್‌ವರ್ಕ್ ಪ್ರಿಫಿಕ್ಸ್ ಗಾತ್ರ ಇರುತ್ತದೆ. ಪ್ರತಿ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ದೊಡ್ಡ ಹಂಚಿಕೆಗಳು ಲಭ್ಯವಿರುವ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಬೇಗನೆ ಖಾಲಿ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಅದು ಸಾಮರ್ಥ್ಯದ ಸತ್ಯ, ರೂಟಿಂಗ್ ಸಮಸ್ಯೆ ಅಲ್ಲ.
ಎಣಿಕೆಯನ್ನು ಬರೆಯಿರಿ. ಮುಂದಿನ ಬದಲಾವಣೆ ಸಹಾಯ ಮಾಡಿತೇ ಎಂದು ಹೇಳುವ ಮೂಲರೇಖೆ ಅದೇ.
ಡೀಮನ್ ಮಾರ್ಗಗಳನ್ನು ಹೇಗೆ ನೋಡುತ್ತದೆ ಎಂದು ಹೋಲಿಸಿ
VPN ಅಭ್ಯರ್ಥಿ ಆಯ್ಕೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಬಹುದು, ಆದರೆ ಹೇಗೆ ಎಂಬುದನ್ನು ನಿಖರ ಅನುಷ್ಠಾನ ನಿರ್ಧರಿಸುತ್ತದೆ. Linux ನಲ್ಲಿ Moby 28.2.2 ನಲ್ಲಿ, InferReservedNetworks ನೇಮ್‌ಸರ್ವರ್ ವಿಳಾಸಗಳನ್ನು ಮತ್ತು ಕೆಲವು ಆನ್-ಲಿಂಕ್ IPv4 ಮಾರ್ಗಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಪ್ರತಿ ಕೋಷ್ಟಕದ ಪ್ರತಿ ಮಾರ್ಗವನ್ನೂ ಸರಳವಾಗಿ ಕಾಯ್ದಿರಿಸುವುದಿಲ್ಲ. ಸಂಗ್ರಹಿಸಿದ ಲಿಂಕ್ ಮಾರ್ಗಗಳು ನಿರ್ದಿಷ್ಟಪಡಿಸದ ಗಮ್ಯ ವಿಳಾಸವನ್ನೂ ಹೊರಗಿಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಒಂದೇ 0.0.0.0/1 ಮಾರ್ಗವು ಎಲ್ಲಾ ವಿಳಾಸಗಳನ್ನು ಕಾಯ್ದಿರಿಸುವುದಿಲ್ಲ. ಇನ್ನೊಂದು ವಿಸ್ತೃತ ಆನ್-ಲಿಂಕ್ ಪ್ರಿಫಿಕ್ಸ್, ಉದಾಹರಣೆಗೆ 128.0.0.0/1, ಪರಿಚಿತ 172 ಮತ್ತು 192 ಅಭ್ಯರ್ಥಿ ಶ್ರೇಣಿಗಳನ್ನು ಛೇದಿಸಬಹುದು.
VPN ಸಂಪರ್ಕಗೊಳ್ಳುವ ಮೊದಲು ಮತ್ತು ನಂತರ ip -4 route show table all ಅನ್ನು ಡೀಮನ್‌ನ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಹೋಲಿಸಿ. ವ್ಯತ್ಯಾಸವೇ ಸಾಕ್ಷ್ಯ, ಮತ್ತು ಆವೃತ್ತಿಯೇ ಹೇಳಿಕೆಯ ವ್ಯಾಪ್ತಿ.
ಒಂದು ಬಿಡುಗಡೆಯ ಹ್ಯೂರಿಸ್ಟಿಕ್ ಅನ್ನು ಎಲ್ಲಾ ಬಿಡುಗಡೆಗಳಿಗೆ ಸಾಮಾನ್ಯೀಕರಿಸಬೇಡಿ. ಹಾಗೆಯೇ ಫೋರಮ್ ಉತ್ತರವೊಂದು ನೀತಿ ಬದಲಾವಣೆಯಾಗುತ್ತದೆ.
ಕೆಲಸ ಮಾಡುವ ಅತ್ಯಂತ ಚಿಕ್ಕ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಆರಿಸಿ
ದೃಢೀಕೃತ ಬಳಕೆಯಾಗದ ನೆಟ್‌ವರ್ಕ್ ನಿಮಗೆ ಬೇಕಾದ ಬ್ಲಾಕ್ ಅನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಂಡಿದ್ದರೆ, ವಿಶಾಲವಾಗಿ ಕತ್ತರಿಸುವ ಬದಲು ಮಾಲೀಕರೊಂದಿಗೆ ಅದರ ಗುರಿ ನಿವೃತ್ತಿಯನ್ನು ಯೋಜಿಸಿ. ಹೊಸ ನೆಟ್‌ವರ್ಕ್‌ಗೆ, ಸ್ಪಷ್ಟವಾಗಿ ಪರಿಶೀಲಿಸಿದ ಬಳಕೆಯಾಗದ ಸಬ್‌ನೆಟ್ ಸ್ವಯಂಚಾಲಿತ ಆಯ್ಕೆಯ ಮೇಲಿನ ಅವಲಂಬನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸುತ್ತದೆ. ಆ ಸಬ್‌ನೆಟ್ ಇನ್ನೂ ನಿಜವಾದ Docker, LAN ಮತ್ತು ಅಗತ್ಯವಾದ VPN ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ತಪ್ಪಿಸಬೇಕು, ಏಕೆಂದರೆ ಖಾಸಗಿ ಎಂದರೆ ಸುರಕ್ಷಿತ ಎಂದಲ್ಲ. ನಿಜವಾದ ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ರೂಟ್ ಮಾಡುವುದು ಹಂಚಿಕೆ ದೋಷವನ್ನು ಮುರಿದ ಪ್ರವೇಶದೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ.
default-address-pools ಬದಲಾಯಿಸುವುದು ಭವಿಷ್ಯದ ಹಂಚಿಕೆಗಳ ಬಗ್ಗೆ ವಿಶಾಲ ನೀತಿ. ಸಂಘರ್ಷವಿಲ್ಲದ ಮೂಲ ಮತ್ತು ಸೂಕ್ತವಾದ ಹಂಚಿದ ಗಾತ್ರವನ್ನು ಆರಿಸಿ, ಅದನ್ನು ಇರುವ ಡೀಮನ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ವಿಲೀನಗೊಳಿಸಿ, ಮತ್ತು ದಾಖಲಿತ ಮರುಪ್ರಾರಂಭದ ಪರಿಣಾಮವನ್ನು ಯೋಜಿಸಿ. ಇರುವ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮೌನವಾಗಿ ಮರುಸಂಖ್ಯೆಯಾಗುವುದಿಲ್ಲ.
ಹಂಚಿಕೆ ಯಶಸ್ವಿಯಾಗಲು ಕಂಪನಿ ಮಾರ್ಗ ಪುಶ್‌ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ. ಸ್ಪಷ್ಟ ವಿಳಾಸ ಯೋಜನೆ ಸಾಮಾನ್ಯವಾಗಿ ಕಡ್ಡಾಯ ನೀತಿಯನ್ನು ದುರ್ಬಲಗೊಳಿಸದೆ ಸ್ಥಳೀಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.
ಹಂಚಿಕೆ ಮತ್ತು ರೂಟಿಂಗ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸ್ವೀಕರಿಸಿ
ಬದಲಾವಣೆಯ ನಂತರ, Docker ನಿಜವಾಗಿ ರಚಿಸಿದ ಸಬ್‌ನೆಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ VPN ಮತ್ತು ಸ್ಥಳೀಯ ಅವಲಂಬನೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ. ಯಶಸ್ವಿ ಹಂಚಿಕೆ ಮತ್ತು ಚಾಲನಾ ಸಮಯದ ಸರಿಯಾದ ರೂಟಿಂಗ್ ಎರಡು ವಿಭಿನ್ನ ಸ್ವೀಕೃತಿ ಪರಿಶೀಲನೆಗಳು, ಮತ್ತು ಮೊದಲನೆಯದನ್ನು ಪಾಸ್ ಮಾಡುವುದು ಎರಡನೆಯದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಟನೆಲ್‌ನ ಹಿಂದಿನ ಸಂಪನ್ಮೂಲವನ್ನು ತಲುಪದಿದ್ದರೆ, ಪೂಲ್ ದೋಷ ಮುಚ್ಚಿಟ್ಟಿದ್ದ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆ ನಿಮಗಿದೆ. ಎರಡೂ ಫಲಿತಾಂಶಗಳನ್ನು ಟಿಕೆಟ್‌ನಲ್ಲಿ ದಾಖಲಿಸಿ.
ಮಾರ್ಗ ವ್ಯತ್ಯಾಸ ಮತ್ತು ಪೂಲ್ ಎಣಿಕೆಯನ್ನು ಬದಲಾವಣೆ ದಾಖಲೆಯೊಂದಿಗೆ ಇರಿಸಿ, ಏಕೆಂದರೆ ಮುಂದಿನ VPN ಕ್ಲೈಂಟ್ ನವೀಕರಣ Docker ಅನ್ನು ಸ್ಪರ್ಶಿಸದೆ ಮೊದಲನೆಯದನ್ನು ಬದಲಿಸಬಹುದು.
ಬೇರೆಯವರು ಈ ಎರಡು ಪರಿಶೀಲನೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ ಅದೇ ಉತ್ತರ ಪಡೆದಾಗ ರನ್‌ಬುಕ್ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ.