Windows ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ UNC ಪ್ರವೇಶ: ಮೊದಲು ಹೆಸರು, ನಂತರ ಗುರುತು

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

ಹೋಸ್ಟ್‌ನ Explorer ಸಾಕ್ಷ್ಯವಲ್ಲ

ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಹಂಚಿಕೆ ತೆರೆಯುವುದು ಹೋಸ್ಟ್‌ನ DNS ಕ್ಲೈಂಟ್, ಹೋಸ್ಟ್‌ನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಮತ್ತು ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಲಾಗ್ ಇನ್ ಆದ ಖಾತೆಯನ್ನು ಬಳಸುತ್ತದೆ. ಕಂಟೇನರ್ ಪ್ರಕ್ರಿಯೆ ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಸೂಚ್ಯವಾಗಿ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ, ಕಂಟೇನರ್ ಅದೇ ಯಂತ್ರದಲ್ಲಿ ಚಲಿಸಿದರೂ ಮತ್ತು VPN ಕ್ಲೈಂಟ್ ಕೂಡ ಅಲ್ಲೇ ಚಲಿಸಿದರೂ. ಮೊದಲ ಗಡಿ ನೆಟ್‌ವರ್ಕ್ ಮಾರ್ಗ: ಕಂಟೇನರ್ ಹೆಸರನ್ನು ಪರಿಹರಿಸಬಲ್ಲದೇ, ಮತ್ತು SMB ಪೋರ್ಟ್‌ಗೆ TCP ಸೆಷನ್ ತೆರೆಯಬಲ್ಲದೇ. ಎರಡನೆಯದು ಗುರುತು: ಫೈಲ್ ಸರ್ವರ್ ಕಂಟೇನರ್ ಒದಗಿಸುವುದನ್ನು ಕೆಲಸದ ಹೊರೆಗೆ ಬೇಕಾದ ಅನುಮತಿಗಳೊಂದಿಗೆ ಸ್ವೀಕರಿಸುತ್ತದೆಯೇ.

ಅವೆರಡನ್ನೂ ಒಂದೇ ಸಮಸ್ಯೆ ಎಂದು ಪರಿಗಣಿಸುವುದು ಪರಿಚಿತ ಚಕ್ರವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ—ವಾಸ್ತವವಾಗಿ ಹಂಚಿಕೆಯಿಂದ ಬರುವ ಪ್ರವೇಶ-ನಿರಾಕರಣೆ ಉತ್ತರವನ್ನು ಸರಿಪಡಿಸಲು ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳನ್ನು ವಿಸ್ತರಿಸುವುದು.

ಕಂಟೇನರ್‌ನ ಸ್ವಂತ ವಿನಂತಿಯನ್ನು ಅನುಸರಿಸಿ

Windows ಕಂಟೇನರ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಅನ್ನು Host Networking Service ನಿರ್ವಹಿಸುತ್ತದೆ, ಅದು ತನ್ನದೇ ನೆಟ್‌ವರ್ಕ್ ನೇಮ್‌ಸ್ಪೇಸ್ ಇರುವ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ. ನೀವು ಆರಿಸಿದ ಮೋಡ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನುವಾದಿತವೇ, ಬ್ರಿಡ್ಜ್ ಆದದ್ದೇ, ಅಥವಾ ಹೋಸ್ಟ್‌ನೊಂದಿಗೆ ಹಂಚಿದ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಂಪರ್ಕಿತವೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಆ ನಿರ್ಧಾರ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎರಡು ವಿಷಯಗಳನ್ನು ಬದಲಿಸುತ್ತದೆ: ಕಂಟೇನರ್ ಏನನ್ನು ಪರಿಹರಿಸಬಲ್ಲದು, ಮತ್ತು ಫೈಲ್ ಸರ್ವರ್ ಯಾವ ಮೂಲ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ.

ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಕಂಟೇನರ್ ಸ್ವತಃ ಏನನ್ನು ಗಮನಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿ. ಹೊರಗೆ ಪರಿಹರಿಸಲಾಗುವ ಹೆಸರು ಒಳಗೆ ವಿಫಲವಾಗಬಹುದು, ಏಕೆಂದರೆ ಕಂಟೇನರ್‌ನ DNS ಸಂರಚನೆ ಹೋಸ್ಟ್‌ನದ್ದಲ್ಲ, ಮತ್ತು ಅನುವಾದಿತ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಫೈಲ್ ಸರ್ವರ್‌ನ ನಿಯಮಗಳು ನಿರೀಕ್ಷಿಸದ ಮೂಲವನ್ನು ಒದಗಿಸಬಹುದು.

docker exec -it app powershell -Command "Resolve-DnsName files.corp.example"
docker exec -it app powershell -Command "Test-NetConnection files.corp.example -Port 445"
docker exec -it app powershell -Command "Get-NetIPConfiguration"

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

ಗುರುತು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರ

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

Microsoft ನ ಕಂಟೇನರ್ gMSA ಮಾರ್ಗದರ್ಶಿ ಆ ರುಜುವಾತು-ವಿಶೇಷಣ ವ್ಯವಸ್ಥೆ ಮತ್ತು ಅದರ ಪೂರ್ವಾಪೇಕ್ಷೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ ಡೊಮೇನ್ ಸದಸ್ಯತ್ವ ಮತ್ತು ರುಜುವಾತನ್ನು ಪಡೆಯಬಲ್ಲ ಹೋಸ್ಟ್ ಸೇರಿವೆ. ಖಾತೆ, ಪಡೆಯುವಿಕೆ, ಕಂಟೇನರ್ ಒಳಗಿನ ಪ್ರಕ್ರಿಯೆ ಗುರುತು ಮತ್ತು ಹಂಚಿಕೆ ಅನುಮತಿಗಳು—ಎಲ್ಲವೂ ಹೊಂದಿಕೆಯಾಗಬೇಕು. VPN ಲಾಗಿನ್ ಆ ಗುರುತಲ್ಲ, ಮತ್ತು ಹೋಸ್ಟ್ ಬಳಕೆದಾರರ ಸೆಷನ್ ಅನ್ನು ಮರುಸೃಷ್ಟಿಸಲು ಇಮೇಜ್‌ನಲ್ಲಿ ಪಾಸ್‌ವರ್ಡ್ ಬೇಯಿಸುವುದು ಶಾಶ್ವತ ಒಡ್ಡುವಿಕೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ವಿಫಲವಾಗುವ ಹಂತವನ್ನು ಗೋಚರವಾಗಿರಿಸಿ

ಪರಿಹಾರ ವೈಫಲ್ಯ, ಸಂಪರ್ಕ ನಿರಾಕರಣೆ ಮತ್ತು ಪ್ರವೇಶ ನಿರಾಕರಣೆಗೆ ಬೇರೆ ಬೇರೆ ಸಾಕ್ಷ್ಯ ಬೇಕು. ಅವು ಕ್ರಮವಾಗಿ DNS ಪ್ರಶ್ನೆ, ರೂಟಿಂಗ್ ಅಥವಾ ಫಿಲ್ಟರಿಂಗ್ ಪ್ರಶ್ನೆ, ಮತ್ತು ದೃಢೀಕರಣ ಅಥವಾ ಅನುಮತಿ ಪ್ರಶ್ನೆ. ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಾಮಾನ್ಯ ದೋಷವನ್ನಲ್ಲ, ಕಂಟೇನರ್‌ಗೆ ಸಿಕ್ಕ ಉತ್ತರವನ್ನು ಓದಿ.

ಕೆಲಸದ ಹೊರೆಯ ಸ್ವಂತ ಗುರುತಿನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ನಿರಾಕರಣೆಯನ್ನೂ ಪರೀಕ್ಷಿಸಿ.

ಮರುಸಂಪರ್ಕಕ್ಕೆ ಯೋಜಿಸಿ

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

ನೆಟ್‌ವರ್ಕ್ ಮೋಡ್, DNS ಮೂಲ ಮತ್ತು ಗುರುತಿನ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿಯೋಜನೆ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ದಾಖಲಿಸಿ. ಮುಂದಿನ ವೈಫಲ್ಯ ನಿಖರವಾಗಿ ಈ ಮೂರು ಅಂಶಗಳ ಬಗ್ಗೆ ಇರುತ್ತದೆ.