VPN ಪ್ರಾರಂಭವಾದ ನಂತರ Azure VM IMDS ಅಥವಾ WireServer ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ

VM ಚಾಲನೆಯಲ್ಲಿದೆ, VPN ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಕೆಲವು ನಿಮಿಷಗಳ ನಂತರ Azure ಏಜೆಂಟ್ ಅಸ್ವಸ್ಥ ಸ್ಥಿತಿಯನ್ನು ವರದಿ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ SSH ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಪೋರ್ಟಲ್ನ Run Command ಉಳಿಯುವುದಿಲ್ಲ, ಇದು ಜನರನ್ನು ರೂಟ್ ಟೇಬಲ್ಗೆ ಬದಲಾಗಿ ಏಜೆಂಟ್ನತ್ತ ಕಳುಹಿಸುತ್ತದೆ. ಸುರಂಗ ಏರಿದಾಗ ಅತಿಥಿಯ ಸ್ವಂತ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿರ್ಧಾರಗಳು ಬದಲಾದವು, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ವಿಳಾಸಗಳು ಮೊದಲ ಬಲಿಪಶುಗಳು. ನಾನು ಇದನ್ನು ಏಜೆಂಟ್ ವೈಫಲ್ಯ ಎಂದು ಪರಿಗಣಿಸುವ ಮೊದಲು ರೂಟಿಂಗ್ ಲಕ್ಷಣ ಎಂದು ಪರಿಗಣಿಸುತ್ತೇನೆ.

ಲಕ್ಷಣ ಮುರಿದ ಏಜೆಂಟ್ನಂತೆ ಕಾಣುತ್ತದೆ

ಕೆಳಗಿನ ಎರಡೂ ವಿಳಾಸಗಳನ್ನು ಪರಿಹಾರವಾಗಿ ಸೂಚಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅವು ಒಂದೇ ಸೇವೆ ಅಲ್ಲ. ಒಂದಕ್ಕೆ /32 ನಕಲಿಸುವುದು ಏಕೆಂದರೆ ಅದು ಇನ್ನೊಂದಕ್ಕೆ ಕೆಲಸ ಮಾಡಿತು—ಹೀಗೆಯೇ ತಾತ್ಕಾಲಿಕ ಪರ್ಯಾಯ ಯಾರೂ ತೆಗೆಯಲು ಧೈರ್ಯ ಮಾಡದ ಶಾಶ್ವತ ಸಂರಚನೆಯಾಗುತ್ತದೆ.

ಕೆಲಸ ಮಾಡುವ ಕ್ರಮ: ಮೊದಲು ವಿಫಲ ಕರೆ ನಿಜವಾಗಿ ಯಾವ ವಿಳಾಸವನ್ನು ಗುರಿಯಾಗಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಅತಿಥಿ ಅದನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ಓದಿ. ಉಳಿದದ್ದೆಲ್ಲ ಹೆಚ್ಚುವರಿ ಹಂತಗಳೊಂದಿಗೆ ಊಹೆ ಮತ್ತು ಉದ್ದವಾದ ಬದಲಾವಣೆ ಕಿಟಕಿ.

168.63.129.16 ಸಾರ್ವಜನಿಕ ಗಮ್ಯಸ್ಥಾನವಲ್ಲ

168.63.129.16 Azure ನ ವಿಶೇಷ ವರ್ಚುವಲ್ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ವಿಳಾಸ, ಮತ್ತು ಅದರ ಒಂದು ಪಾತ್ರ WireServer, ಅದನ್ನು VM ಏಜೆಂಟ್ ಫ್ಯಾಬ್ರಿಕ್ನೊಂದಿಗೆ ಮಾತನಾಡಲು ಬಳಸುತ್ತದೆ. Microsoft ಏಜೆಂಟ್ನ TCP 80 ಮತ್ತು 32526 ಪೋರ್ಟ್ಗಳ ಸಂಚಾರ ಲಭ್ಯವಾಗಿರಬೇಕು ಎಂದು ದಾಖಲಿಸುತ್ತದೆ. ಇದು ಸಾಮಾನ್ಯ ಇಂಟರ್ನೆಟ್ ಹೋಸ್ಟ್ ಅಲ್ಲ, ಮತ್ತು ಪೂರ್ಣ-ಸುರಂಗ VPN ಅದನ್ನು ದೂರದ ನಿರ್ಗಮನಕ್ಕೆ ಒಯ್ಯಬಾರದು. ಆದ್ದರಿಂದ ಆರೋಗ್ಯವಾಗಿ ಕಾಣುವ ಸುರಂಗವೂ ಏಜೆಂಟನ್ನು ಹಸಿವಿನಿಂದ ಇಡಬಹುದು.

ಪ್ಲಾಟ್ಫಾರ್ಮ್ ವಿಳಾಸದ ದಾಖಲೆ ಈ ವಿಳಾಸವು ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ ರೂಟ್ಗಳಿಗೆ ಒಳಪಡುವುದಿಲ್ಲ ಎಂದೂ ಹೇಳುತ್ತದೆ; ಇದು Azure ಫ್ಯಾಬ್ರಿಕ್ನ ಗುಣಲಕ್ಷಣ, ನಿಮ್ಮ ಅತಿಥಿಯ ಬಗ್ಗೆ ಭರವಸೆ ಅಲ್ಲ. ಸ್ಥಳೀಯ ಫೈರ್ವಾಲ್ ನಿಯಮ ಅಥವಾ VPN ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ರೂಟಿಂಗ್ ನೀತಿ ಇನ್ನೂ ಮಾರ್ಗವನ್ನು ಮುರಿಯಬಹುದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ VNet ನ ರೂಟ್ ಟೇಬಲ್ನಲ್ಲಿ ಇರುವುದಿಲ್ಲ.

ಸಮಸ್ಯೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತಿರುವುದು ಏಜೆಂಟ್ ಆಗಿದ್ದರೆ, ಏನನ್ನೂ ಮರುಸ್ಥಾಪಿಸುವ ಮೊದಲು ಸೇವೆಯ ಸ್ಥಿತಿ ಮತ್ತು ಆ ವಿಳಾಸಕ್ಕೆ ಇರುವ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ.

169.254.169.254 ಗೆ ತನ್ನದೇ ನಿಯಮಗಳಿವೆ

169.254.169.254 Azure Instance Metadata Service ನ link-local ವಿಳಾಸ. ಅದಕ್ಕೆ ಬರುವ ವಿನಂತಿಗಳಿಗೆ ತಮ್ಮದೇ ಅಗತ್ಯಗಳಿವೆ: ಪ್ರಾಥಮಿಕ NIC ಮತ್ತು ಪ್ರಾಥಮಿಕ IP, ವಿಳಾಸವನ್ನು ಬೆಂಬಲಿಸುವ DHCP ಸಂರಚನೆ, ಮತ್ತು ಯಾವುದೇ HTTP ಪ್ರಾಕ್ಸಿ ಬೈಪಾಸ್. ಅವನ್ನು ದೂರದ VPN ನಿರ್ಗಮನ ಅಥವಾ ಅನಿಯಂತ್ರಿತ ಇಂಟರ್ನೆಟ್ ಗೇಟ್ವೇ ಮೂಲಕ ಕಳುಹಿಸುವುದು Microsoft ವಿವರಿಸುವ ಪ್ರವೇಶ ಮಾದರಿ ಅಲ್ಲ.

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

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

ಅತಿಥಿಯ ನೀತಿ ರೂಟಿಂಗ್ ಓದಿ, ಮುಖ್ಯ ಟೇಬಲ್ ಮಾತ್ರವಲ್ಲ

Linux ಅತಿಥಿಯಲ್ಲಿ ಮೂರು ಓದು-ಮಾತ್ರ ಆಜ್ಞೆಗಳು ಪದರಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತವೆ: ನೀತಿ ನಿಯಮಗಳಿಗೆ ip -4 rule show, ನಂತರ ಕರ್ನಲ್ ನಿಜವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುವ ನಿರ್ಧಾರಗಳಿಗೆ ip -4 route get 168.63.129.16 ಮತ್ತು ip -4 route get 169.254.169.254. VPN ಸಂಪರ್ಕಗೊಳ್ಳುವ ಮೊದಲು ಮತ್ತು ನಂತರ ಅವನ್ನು ಚಲಾಯಿಸಿ. ಆ ಎರಡು ಔಟ್ಪುಟ್ಗಳ ವ್ಯತ್ಯಾಸವೇ ನಿಮ್ಮ ಬದಲಾವಣೆ-ಗುಂಪು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಏನು ಮಾಡಿತು ಎಂಬ ಯಾವುದೇ ಊಹೆಗಿಂತ ಅದು ಉಪಯುಕ್ತ.

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

ಹಳೆಯ ಗೇಟ್ವೇ ಮೂಲಕ ಎರಡೂ /32 ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸುವ ಪಾಕವಿಧಾನವನ್ನು ವಿರೋಧಿಸಿ. link-local ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಮಾರ್ಗ ಮತ್ತು ಸಾಮಾನ್ಯ WAN ಮುಂದಿನ ಹಾಪ್ ಬೇರೆ ಬೇರೆ ವಸ್ತುಗಳು, ಮತ್ತು ಸರ್ವವ್ಯಾಪಿ ವಿನಾಯಿತಿ ನಿಜವಾದ ನೀತಿ ಘರ್ಷಣೆಯನ್ನು ಮರೆಮಾಡುತ್ತದೆ.

ಆಡಳಿತ ಮತ್ತು ಚೇತರಿಕೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ

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

ನಂತರ ಮೂರು ಹರಿವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ: ನೀವು ನಿಜವಾಗಿ ಬಯಸಿದ ಖಾಸಗಿ ಸಂಪನ್ಮೂಲ, ಬೆಂಬಲಿತ ಏಜೆಂಟ್ ಮತ್ತು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಸಂವಹನ, ಮತ್ತು ಆಡಳಿತ ಮಾರ್ಗ. ಒಂದನ್ನು ಮರುಸ್ಥಾಪಿಸುವುದು ಉಳಿದ ಎರಡು ಉಳಿದಿವೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ.

ಅನುಮೋದಿತ ವಿನಾಯಿತಿಯನ್ನು ಅತಿಥಿ ನೆಟ್ವರ್ಕ್ ಮತ್ತು VPN ಸಂರಚನೆಯ ಮಾಲೀಕರ ಅಡಿಯಲ್ಲಿ ಬರೆಯಿರಿ, ಮರುಸಂಪರ್ಕ ಮತ್ತು ಮರುಪ್ರಾರಂಭದಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನೂ ಸೇರಿಸಿ. Azure UDR ಗಳು ಅತಿಥಿಯ ರೂಟ್ ಟೇಬಲ್ ಅಲ್ಲ, ಮತ್ತು ಅವನ್ನು ಸಂಪಾದಿಸುವುದು ಸ್ಥಳೀಯ ನೀತಿ ನಿಯಮವನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.