Azure P2S VPN ನ ಹಿಂತಿರುಗುವ ಟ್ರಾಫಿಕ್ ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ಟನೆಲ್ ಐಕಾನ್ ಹಸಿರಾಗಿದೆ, NSG ಅನುಮತಿಸುವಂತೆ ಕಾಣುತ್ತದೆ, ಪರಿಣಾಮಕಾರಿ ರೂಟ್ಗಳು ಸರಿಯಾಗಿ ಕಾಣುತ್ತವೆ, ಆದರೂ VM ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ಗೆ ಮತ್ತೆ ಸಂಪರ್ಕ ತೆರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸಾಮಾನ್ಯ ಊಹೆ ಎಂದರೆ ಕೆಲಸ ಮಾಡುವ point-to-site ಟನೆಲ್ ಸಮ್ಮಿತೀಯವಾಗಿದೆ: ಕ್ಲೈಂಟ್ VM ತಲುಪಿದರೆ, VM ಕೂಡ ಕ್ಲೈಂಟ್ ತಲುಪುತ್ತದೆ. ಆ ಊಹೆಯೇ ತರ್ಕದ ದೋಷ, ಸಂರಚನೆಯದಲ್ಲ. ಟನೆಲ್ ಕೇಳದ ಹರಿವಿನ ಒಂದು ದಿಕ್ಕನ್ನು ಸಾಗಿಸಿ ಇನ್ನೊಂದನ್ನು ಬಿಡಬಹುದು, ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ ಯಾವ ಪದರ ಅದನ್ನು ಬಿಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ.

ಪುರಾಣ: ಸಂಪರ್ಕಿತ ಟನೆಲ್ ಎರಡು ದಿಕ್ಕಿನ ಟನೆಲ್ ಆಗಿದೆ

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

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

ತಲುಪುವಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ದಿಕ್ಕನ್ನು ಪರೀಕ್ಷಿಸಿ

ಒಂದು ಕ್ಲೈಂಟ್ ವಿಳಾಸ, ಒಂದು VM ವಿಳಾಸ ಮತ್ತು ಒಂದು ಪ್ರೋಟೋಕಾಲ್ ಆಯ್ಕೆಮಾಡಿ. ಕ್ಲೈಂಟ್ನಿಂದ ಸಂಪರ್ಕಿಸಿ ಫಲಿತಾಂಶ ದಾಖಲಿಸಿ; ನಂತರ ಅದೇ ಪರೀಕ್ಷೆಯನ್ನು VM ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಅದನ್ನೂ ದಾಖಲಿಸಿ. ಮೊದಲನೆಯದು ಯಶಸ್ವಿಯಾಗಿ ಎರಡನೆಯದು ವಿಫಲವಾದರೆ, ಕ್ಲೈಂಟ್ ಪೂಲ್, ಗೇಟ್ವೇ ಸಂಯೋಜನೆ ಮತ್ತು ಕ್ಲೈಂಟ್ನಿಂದ VNet ಗೆ ಇರುವ ಮಾರ್ಗ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತಿವೆ.

ಮುಂದಿನ ಹೆಜ್ಜೆ ಸಾಕ್ಷ್ಯ, ಹೆಚ್ಚು ನಿಯಮಗಳಲ್ಲ. VM ಸಬ್ನೆಟ್ನಲ್ಲಿನ NSG ಅನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪರಿಶೀಲಿಸಿ, VM ನ NIC ನಲ್ಲಿ ಪರಿಣಾಮಕಾರಿ ರೂಟ್ಗಳನ್ನು ಓದಿ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಟ್ರಾಫಿಕ್ ಕಳುಹಿಸುತ್ತಿರುವಾಗ VM ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ. ಉತ್ತರವಿಲ್ಲದೆ ಬರುವ ವಿನಂತಿ ಫಿಲ್ಟರ್ ಅಥವಾ ಹಿಂತಿರುಗುವ-ಮಾರ್ಗದ ಸಮಸ್ಯೆ; ಎಂದೂ ಬಾರದ ವಿನಂತಿ ಮಾರ್ಗದ ಸಮಸ್ಯೆ. ವಿಫಲವಾದ ping ಅನ್ನು VM ತಲುಪಲಾಗದಿರುವ ಸಾಕ್ಷ್ಯವೆಂದು ಪರಿಗಣಿಸಬೇಡಿ, ಏಕೆಂದರೆ TCP ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ ICMP ನೀತಿ ಉತ್ತರವನ್ನು ಬಿಡಬಹುದು.

IKEv2 point-to-site ಹಿಂತಿರುಗುವ ಮಾರ್ಗವೇ ಸಾಮಾನ್ಯ ಶಂಕಿತ

ಈ ಲೇಖನದ ಹಿಂದಿನ Azure ವರದಿಯಲ್ಲಿ, ಕ್ಲೈಂಟ್ IKEv2 ಮೂಲಕ VM ಗಳನ್ನು ತಲುಪಬಹುದಿತ್ತು, ಆದರೆ VM ನಿಂದ ಕ್ಲೈಂಟ್ಗೆ ಒಳಬರುವ ICMP, ಗೇಟ್ವೇಯ ಟನೆಲ್ ಪ್ರಕಾರವನ್ನು OpenVPN ಗೆ ಬದಲಾಯಿಸುವವರೆಗೆ ವಿಫಲವಾಗುತ್ತಿತ್ತು. ವರದಿಗಾರರು Microsoft, IKEv2 point-to-site ಮಾರ್ಗದಲ್ಲಿ ಮಿತಿಯನ್ನು ದೃಢೀಕರಿಸಿದೆ ಎಂದು ಹೇಳುತ್ತಾರೆ: ಕ್ಲೈಂಟ್ ಸೆಷನ್ ಪ್ರಾರಂಭಿಸದಿದ್ದರೆ VM ನಿಂದ ಕ್ಲೈಂಟ್ಗೆ ಹಿಂತಿರುಗುವ ಟ್ರಾಫಿಕ್ ಸಮ್ಮಿತೀಯವಾಗಿ ರೂಟ್ ಆಗುವುದಿಲ್ಲ. IKEv2 ಟ್ರಾಫಿಕ್ ಸೆಲೆಕ್ಟರ್ಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ, ಮತ್ತು ಆ ಸಂದರ್ಭದಲ್ಲಿ ಗೇಟ್ವೇ ಹಿಂತಿರುಗುವ ದಿಕ್ಕನ್ನು ಗೌರವಿಸಲಿಲ್ಲ.

ಇದು OpenVPN ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಉತ್ತಮ ಟನೆಲ್ ಪ್ರಕಾರವನ್ನಾಗಿ ಮಾಡುವುದಿಲ್ಲ. ಇದು ಈ ಕೆಲಸದ ಹೊರೆಗೆ ಪರೀಕ್ಷಾ ಮ್ಯಾಟ್ರಿಕ್ಸ್ನಲ್ಲಿ ಟನೆಲ್ ಪ್ರಕಾರವನ್ನು ಚರವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ.

ಟನೆಲ್ ಪ್ರಕಾರ ಬದಲಾಯಿಸುವುದು ಸೇವಾ ಬದಲಾವಣೆ, ಟಾಗಲ್ ಅಲ್ಲ. ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ ಹೊಂದುವ ಪ್ರೊಫೈಲ್ ಬೇಕು, ಮತ್ತು ಗೇಟ್ವೇಗೆ ಬೇರೆ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ದೃಢೀಕರಣ ಸೆಟಪ್ ಬೇಕಾಗಬಹುದು. ಒಂದು ಪರೀಕ್ಷಾ ಕ್ಲೈಂಟ್ ಮತ್ತು ಒಂದು ಪರೀಕ್ಷಾ VM ಜೊತೆ ಏಕಮುಖ ವರ್ತನೆಯನ್ನು ಮರುಸೃಷ್ಟಿಸಿ, ಅನುಮೋದಿತ ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ ಪ್ರಕಾರ ಬದಲಾಯಿಸಿ, ನಂತರ ಅದೇ ದಿಕ್ಕಿನ ಪರೀಕ್ಷೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಬದಲಾವಣೆಯ ನಂತರವೂ ವರ್ತನೆ ಉಳಿದರೆ, ಟನೆಲ್ ಪ್ರಕಾರ ಕಾರಣವಾಗಿರಲಿಲ್ಲ ಮತ್ತು ಉತ್ಪಾದನೆಯನ್ನು ಮುಟ್ಟದೆ ಸಮಸ್ಯೆಯನ್ನು ಸಂಕುಚಿಸಿದ್ದೀರಿ.

ಪುರಾಣ: ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಶೋಧನೆ VNet ಗಡಿಯನ್ನು ದಾಟುತ್ತದೆ

ಎರಡನೇ ಊಹೆ ಸಂಬಂಧವಿಲ್ಲದ ಕಾರಣದಿಂದ ವಿಫಲವಾಗುತ್ತದೆ. Azure ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಟ್ರಾಫಿಕ್ ಸಾಗಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ VM site-to-site ಅಥವಾ point-to-site ಸಂಪರ್ಕದ ಮೂಲಕ ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ನಿಂದ ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಫ್ರೇಮ್ಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಮೂಲಕ ಸಹಚರರನ್ನು ಹುಡುಕುವ ಅಪ್ಲಿಕೇಶನ್ಗಳು, ಉದಾಹರಣೆಗೆ ಹಳೆಯ ಫೈಲ್ ಬ್ರೌಸಿಂಗ್ ಅಥವಾ ಕೆಲವು ಸಾಧನ-ಶೋಧನಾ ಪ್ರೋಟೋಕಾಲ್ಗಳು, ರೂಟ್ಗಳನ್ನು ಹೇಗೆ ಬರೆದರೂ ದೂರದ ಬದಿಯನ್ನು ಎಂದೂ ನೋಡುವುದಿಲ್ಲ.

ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಶೋಧನೆಯನ್ನು DNS ಹೆಸರುಗಳು, ಡೈರೆಕ್ಟರಿ ಸೇವೆ ಅಥವಾ ಸ್ಪಷ್ಟ ಸಹಚರ ಪಟ್ಟಿಯೊಂದಿಗೆ ಬದಲಾಯಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ಗೆ unicast ಪರ್ಯಾಯವಿಲ್ಲದಿದ್ದರೆ, ವಿನ್ಯಾಸಕ್ಕೆ ವಿಶಾಲ ಟನೆಲ್ ಅಲ್ಲ, ಬೇರೆ ಶೋಧನಾ ಕಾರ್ಯವಿಧಾನ ಬೇಕು.

ಏನನ್ನು ಬದಲಾಯಿಸಬೇಕು, ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಸಾಬೀತುಪಡಿಸಬೇಕು

ದಿಕ್ಕಿನ ಪರೀಕ್ಷೆ ಕೇವಲ IKEv2 ನಲ್ಲಿ ವಿಫಲವಾದರೆ, ಗೇಟ್ವೇಯ ಟನೆಲ್ ಪ್ರಕಾರ, ಕ್ಲೈಂಟ್ ವಿಳಾಸ ಪೂಲ್ ಮತ್ತು ನಿಖರವಾದ ICMP ಅಥವಾ TCP ಪರೀಕ್ಷೆಯನ್ನು ದಾಖಲಿಸಿ, ನಂತರ ಪೀಡಿತ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಅನುಮೋದಿತ OpenVPN ಪ್ರೊಫೈಲ್ ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ. ಎಲ್ಲಾ ಟನೆಲ್ ಪ್ರಕಾರಗಳಲ್ಲಿ ವಿಫಲವಾದರೆ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ: ಕ್ಲೈಂಟ್ ವಿಳಾಸ VM ಸಬ್ನೆಟ್ನಿಂದ ರೂಟ್ ಆಗಬಲ್ಲದಾಗಿರಬೇಕು, ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ ಯಾವುದೇ ರೂಟ್ ಮಾನ್ಯ ಮುಂದಿನ ಹಾಪ್ ಕಡೆಗೆ ತೋರಿಸಬೇಕು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಫೈರ್ವಾಲ್ ಒಳಬರುವ ಹರಿವನ್ನು ಸ್ವೀಕರಿಸಬೇಕು. NSG ಮತ್ತು ರೂಟ್ ಸಾಕ್ಷ್ಯಗಳನ್ನು ಟಿಕೆಟ್ಗೆ ಲಗತ್ತಿಸಿ.

ಅಪ್ಲಿಕೇಶನ್ನೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ, ping ನೊಂದಿಗೆ ಅಲ್ಲ. ಬದಲಾವಣೆಯ ನಂತರದ ಯಶಸ್ವಿ ICMP ವಿನಿಮಯ ಸೇವಾ ಪೋರ್ಟ್, ಅದರ ದೃಢೀಕರಣ ಅಥವಾ ಹೆಸರು ವಿಭಜನೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಮರುಸಂಪರ್ಕದ ನಂತರ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಪೂಲ್ನಿಂದ ಬೇರೆ ವಿಳಾಸ ಪಡೆಯುವ ಕ್ಲೈಂಟ್ ಫಲಿತಾಂಶವನ್ನು ಬದಲಾಯಿಸಬಹುದು. ನಂತರ ಕ್ಲೈಂಟ್ ನಿದ್ರಿಸಿ ಎಚ್ಚರಗೊಂಡ ನಂತರ ಇನ್ನೊಮ್ಮೆ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಮತ್ತೆ ಪ್ರಾರಂಭವಾದ ಸೆಷನ್ನಲ್ಲಿ ಏಕಮುಖ ವರ್ತನೆ ಹೆಚ್ಚಾಗಿ ಮತ್ತೆ ಕಾಣಿಸುತ್ತದೆ.