kubectl OpenVPN ಮೂಲಕ ಖಾಸಗಿ ಕ್ಲಸ್ಟರ್ನ API ಪರಿಹರಿಸಲಾರದು

kubectl ಹೆಸರು ಹುಡುಕಾಟದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ ಆದರೆ ಸುರಂಗ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು API ಯ ಖಾಸಗಿ ವಿಳಾಸ ಇನ್ನೂ ping ಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಮಾರ್ಗ ಸರಿಯಾಗಿದೆ; ಕ್ಲೈಂಟ್ ಕ್ಲಸ್ಟರ್ನ ಖಾಸಗಿ ವಲಯದ ಬಗ್ಗೆ ಎಂದೂ ಕೇಳದ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಕೇಳುತ್ತಿದೆ. ಎರಡು ಸರಿಪಡಿಸುವಿಕೆಗಳು ಹೆಚ್ಚು ಬಳಕೆಯಾಗುತ್ತವೆ: ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ನ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಪ್ರತಿ VPN ಕ್ಲೈಂಟ್ಗೆ ಕಳುಹಿಸುವುದು, ಅಥವಾ ಹೆಸರನ್ನು ಸ್ಥಳೀಯವಾಗಿ hosts ನಮೂದು ಅಥವಾ ಷರತ್ತುಬದ್ಧ ಫಾರ್ವರ್ಡರ್ನಿಂದ ಪಿನ್ ಮಾಡುವುದು. ಎರಡೂ ಒಂದೇ ಲಕ್ಷಣವನ್ನು ವಿಭಿನ್ನ ಜವಾಬ್ದಾರಿಯೊಂದಿಗೆ ಪರಿಹರಿಸುತ್ತವೆ, ಮತ್ತು ಅವನ್ನು ಬೆರೆಸುವುದೇ ತಂಡಗಳು ಪ್ರತಿ ಬಾರಿ ಎಂಡ್ಪಾಯಿಂಟ್ ಮರುನಿರ್ಮಾಣವಾದಾಗ hosts ಫೈಲ್ಗಳನ್ನು ಸಂಪಾದಿಸಲು ಕಾರಣ.

ಪರಿಹರಣ ಮತ್ತು ತಲುಪುವಿಕೆ ವಿಭಿನ್ನ ಪದರಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ

ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಹುಡುಕಾಟವನ್ನು ನೀವೇ ನಡೆಸಿ. Linux ನಲ್ಲಿ getent hosts ಅಥವಾ Windows ನಲ್ಲಿ nslookup ಕ್ಲೈಂಟ್ಗೆ ಉತ್ತರ ಸಿಗುತ್ತದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ; ಸಮಯ ಮೀರುವಿಕೆ ಅಥವಾ NXDOMAIN ರಿಸಾಲ್ವರ್ ಕಡೆ ಸೂಚಿಸುತ್ತದೆ, ತಪ್ಪು ವಿಳಾಸದ ಉತ್ತರ ಹಳೆಯ ದಾಖಲೆ ಅಥವಾ ಸಾರ್ವಜನಿಕ ಹಾದಿಯ ಕಡೆ ಸೂಚಿಸುತ್ತದೆ.

ನಂತರ kubectl ನಿಜವಾಗಿ ಯಾವ ಸರ್ವರ್ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. kubeconfig ಸಂದರ್ಭ URL ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಮತ್ತು VPN ಮಾರ್ಗ ಅದನ್ನು ಮತ್ತೆ ಬರೆಯುವುದಿಲ್ಲ: ಸಂದರ್ಭ ಸಾರ್ವಜನಿಕ ಎಂಡ್ಪಾಯಿಂಟ್ ಹೆಸರಿಸಿದರೆ DNS ಪರಿಪೂರ್ಣವಾಗಿರಬಹುದು ಮತ್ತು ಆದೇಶ ವಿಫಲವಾಗಬಹುದು.

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

ಮೂರನೇ ಸಂಕೇತ ಹುಡುಕಾಟದ ನಂತರದ ವೈಫಲ್ಯದ ಆಕಾರ. ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಲ್ಪಟ್ಟ ಹೆಸರು ನಂತರ TCP ಸಮಯ ಮೀರುವಿಕೆ ಪಡೆದರೆ ಅದು ಫೈರ್ವಾಲ್ ಅಥವಾ ಅಧಿಕೃತ ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆ. ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಲ್ಪಡುವ ಹೆಸರು ಪ್ರಶ್ನೆ ಖಾಸಗಿ ವಲಯದಿಂದ ಹೊರಬಂದಿದೆ ಎಂದರ್ಥ. ಈ ಮೂರು ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡಿ; ಪ್ರತಿಯೊಂದೂ ನಿಮ್ಮನ್ನು ಬೇರೆ ಜವಾಬ್ದಾರರ ಬಳಿಗೆ ಕರೆದೊಯ್ಯುತ್ತದೆ.

ಆಯ್ಕೆ A: ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ನ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸಿ

VPN ಸರ್ವರ್ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ನ ಒಳಗೆ ಚಲಿಸಿದಾಗ, ಕ್ಲೈಂಟ್ಗಳು ಸರ್ವರ್ ಹೋಸ್ಟ್ನಂತೆಯೇ ಅದೇ ರಿಸಾಲ್ವರ್ ಬಳಸಬಹುದು. OpenVPN Community ನಲ್ಲಿ ಸರ್ವರ್ DNS ಆಯ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ; Access Server ಅದೇ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ನಿರ್ವಾಹಕ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ಗಳು ಪ್ರೊಫೈಲ್ ಅನ್ನು ಮತ್ತೆ ಡೌನ್ಲೋಡ್ ಮಾಡಬೇಕು ಏಕೆಂದರೆ DNS ಸೂಚನೆ ಅದರೊಳಗೆ ಪ್ರಯಾಣಿಸುತ್ತದೆ.

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

ಮಾರ್ಗ ಸಾಲು split tunnel ಪ್ರೊಫೈಲ್ಗಳಲ್ಲಿ ಮುಖ್ಯ. ರಿಸಾಲ್ವರ್ ವಿಳಾಸ ಕಳುಹಿಸುವುದು ಅದನ್ನು ತಲುಪಬಹುದಾದಂತೆ ಮಾಡುವುದಕ್ಕೆ ಸಮಾನವಲ್ಲ: ಸುರಂಗದ ಮೂಲಕ ಕ್ಲಸ್ಟರ್ನ ಉಪಜಾಲ ಮಾತ್ರ ಹೋದರೆ, 10.0.0.4 ಗೆ ಪ್ರಶ್ನೆ ಸ್ಥಳೀಯ LAN ಮೂಲಕ ಹೊರಟು ಸಾಯುತ್ತದೆ. ರಿಸಾಲ್ವರ್ಗೆ ಹೋಸ್ಟ್ ಮಾರ್ಗ ಕಳುಹಿಸಿ, ಅಥವಾ ಅದರ ಉಪಜಾಲವನ್ನು ಸುರಂಗದಲ್ಲಿ ಸೇರಿಸಿ.

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

ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಏನು ಅನ್ವಯವಾಯಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ: systemd-resolved Linux ನಲ್ಲಿ resolvectl status, macOS ನಲ್ಲಿ scutil --dns, Windows ನಲ್ಲಿ ipconfig /all. ಕಳುಹಿಸಿದ DNS ಸರ್ವರ್ ಎಂದೂ ಕಾಣದಿದ್ದರೆ ಪ್ರೊಫೈಲ್ ಮತ್ತೆ ಲೋಡ್ ಆಗಿಲ್ಲ ಎಂದರ್ಥ.

ಆಯ್ಕೆ B: hosts ನಮೂದುಗಳು ಮತ್ತು ಷರತ್ತುಬದ್ಧ ಫಾರ್ವರ್ಡಿಂಗ್

hosts ನಮೂದು ಸಾಧ್ಯವಾದಷ್ಟು ಚಿಕ್ಕ ಸರಿಪಡಿಸುವಿಕೆ ಮತ್ತು ಅತ್ಯಂತ ಸೂಕ್ಷ್ಮ. ಅದು ಒಂದು ಹೆಸರನ್ನು ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಒಂದು ವಿಳಾಸಕ್ಕೆ ನಕ್ಷೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರದರ್ಶನಕ್ಕೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಖಾಸಗಿ ಎಂಡ್ಪಾಯಿಂಟ್ ಅಥವಾ ಅದರ IP ಮರುನಿರ್ಮಾಣವಾದಾಗ ಮುರಿಯುತ್ತದೆ. ಅದು ನಿಜವಾದ ಅಂತರವನ್ನು ಉಳಿದ ತಂಡದಿಂದ ಮರೆಮಾಡುತ್ತದೆ.

ಷರತ್ತುಬದ್ಧ ಫಾರ್ವರ್ಡರ್ ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ DNS ಕಳುಹಿಸದೆ ಉತ್ತಮವಾಗಿ ಸ್ಕೇಲ್ ಆಗುತ್ತದೆ. dnsmasq ಒಂದು ವಲಯವನ್ನು VNet ರಿಸಾಲ್ವರ್ಗೆ ಕಳುಹಿಸಿ ಉಳಿದುದನ್ನು ಶಾಂತವಾಗಿ ಬಿಡಬಹುದು: server=/cluster.internal/10.0.0.4. Windows DNS ನಲ್ಲಿ ಷರತ್ತುಬದ್ಧ ಫಾರ್ವರ್ಡರ್ಗಳಿವೆ, ಮತ್ತು Windows ಕ್ಲೈಂಟ್ಗಳು ಅದೇ ವಿಭಜನೆಗೆ NRPT ನಿಯಮ ಬಳಸಬಹುದು. ಫಾರ್ವರ್ಡರ್ಗೆ ಇನ್ನೂ VNet ರಿಸಾಲ್ವರ್ಗೆ ಮಾರ್ಗ ಬೇಕು.

ಫಾರ್ವರ್ಡಿಂಗ್ ಸಾಮಾನ್ಯ ಬ್ರೌಸಿಂಗ್ ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಇಡುತ್ತದೆ, ಇದು split tunnel ನಲ್ಲಿ ಮುಖ್ಯ. ಅದು ನಿಮಗೆ ಖಾಸಗಿ ವಲಯದ ಪ್ರಶ್ನೆಗಳನ್ನು ಲಾಗ್ ಮಾಡಲು ಒಂದು ಸ್ಥಳ ಮತ್ತು ಫಾರ್ವರ್ಡರ್ ಹೋಸ್ಟ್ ಸರಿದಾಗ ಮುರಿಯುವ ಒಂದು ಸ್ಥಳ ನೀಡುತ್ತದೆ.

ಜವಾಬ್ದಾರಿಯಿಂದ ಆಯ್ಕೆಮಾಡಿ, ಅನುಕೂಲದಿಂದ ಅಲ್ಲ

VPN ಪ್ರೊಫೈಲ್ ನಿಯಂತ್ರಿಸುತ್ತೀರಿ ಮತ್ತು API ಮಾತ್ರವಲ್ಲ ಪ್ರತಿ ಖಾಸಗಿ ಹೆಸರೂ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ಬಯಸಿದರೆ ರಿಸಾಲ್ವರ್ ಕಳುಹಿಸಿ. ಕ್ಲೈಂಟ್ಗಳು ಉಳಿದ ಎಲ್ಲದಕ್ಕೂ ಸ್ಥಳೀಯ DNS ಇಟ್ಟುಕೊಳ್ಳಬೇಕಿದ್ದರೆ, ಅಥವಾ VPN ಅನ್ನು ಕ್ಲಸ್ಟರ್ಗಿಂತ ಬೇರೆ ತಂಡ ನಿರ್ವಹಿಸಿದರೆ ಫಾರ್ವರ್ಡರ್ ಆಯ್ಕೆಮಾಡಿ.

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

API ಎಂಡ್ಪಾಯಿಂಟ್ ಪರೀಕ್ಷಿಸಿ, ಹೆಸರನ್ನು ಮಾತ್ರವಲ್ಲ

ಹುಡುಕಾಟ ಯಶಸ್ವಿಯಾದ ನಂತರ, ಕ್ಲಸ್ಟರ್ CA ಯೊಂದಿಗೆ API ಯ ಆವೃತ್ತಿ ಎಂಡ್ಪಾಯಿಂಟ್ ಪಡೆಯಿರಿ. curl --cacert ca.crt https://api.internal.example:6443/version TLS ಮತ್ತು ಅಧಿಕಾರದ ವೈಫಲ್ಯಗಳನ್ನು DNS ನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. 403 ಎಂದರೆ ಹೆಸರು ಮತ್ತು ಸಂಪರ್ಕ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಮತ್ತು ಗುರುತು ಮಾಡುವುದಿಲ್ಲ.

ಕ್ಲೈಂಟ್ನ ವಿಳಾಸ ಶ್ರೇಣಿಯನ್ನು ಕ್ಲಸ್ಟರ್ನ ಅಧಿಕೃತ ನೆಟ್ವರ್ಕ್ಗಳು ಅಥವಾ ಫೈರ್ವಾಲ್ ಅನುಮತಿಸುತ್ತವೆಯೇ ಎಂದೂ ಪರಿಶೀಲಿಸಿ. ಖಾಸಗಿ ಕ್ಲಸ್ಟರ್ಗಳು ಹೆಚ್ಚಾಗಿ API ಸಂಚಾರವನ್ನು VNet ಅಥವಾ peered ಶ್ರೇಣಿಗಳಿಂದ ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಬೇರೆ ಪೂಲ್ನಿಂದ ವಿಳಾಸ ನೀಡುವ ಸುರಂಗ ನೆಟ್ವರ್ಕ್ ಪದರದಲ್ಲಿ ಸಂಪರ್ಕಿಸಿ API ಯಲ್ಲಿ ಬಿಡಲ್ಪಡುತ್ತದೆ.

ಹಂತ ಹೆಚ್ಚಿಸುವಾಗ ನಾಲ್ಕು ಸಂಗತಿಗಳನ್ನು ಬರೆಯಿರಿ: ಕ್ಲೈಂಟ್ ಬಳಸಿದ ರಿಸಾಲ್ವರ್, ಅದು ಹಿಂತಿರುಗಿಸಿದ ವಿಳಾಸ, ಆಯ್ಕೆಮಾಡಿದ kubeconfig ಸಂದರ್ಭದಲ್ಲಿ ಸರ್ವರ್ URL, ಮತ್ತು ವಿಫಲವಾದ ಮೊದಲ ಕಾರ್ಯಾಚರಣೆ. ಆ ದಾಖಲೆ ಮುಂದಿನ ಎಂಜಿನಿಯರ್ಗೆ DNS, ಮಾರ್ಗ ಅಥವಾ ಫೈರ್ವಾಲ್ ನೀತಿ ಬದಲಿಸಬೇಕೇ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ hosts ಫೈಲ್ ಸಂಪಾದನೆಯನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.

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