ಸಂಪರ್ಕವಾಗಿದೆ ಎಂಬುದು ಟನೆಲ್‌ನ ಸ್ಥಿತಿ, ತಲುಪುವಿಕೆಯ ಬಗ್ಗೆ ಹೇಳಿಕೆ ಅಲ್ಲ. ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ಕ್ಲೈಂಟ್ IKE ಮುಗಿಸಿ, ವಿಳಾಸ ಪಡೆದೂ ಏನನ್ನೂ ತಲುಪದಿರಬಹುದು, ಏಕೆಂದರೆ ಗೇಟ್‌ವೇ VNet ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ ಮಾತ್ರ ಸಂಚಾರವನ್ನು ಮುಂದೆ ಕಳುಹಿಸುತ್ತದೆ. ಈ ಐದು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಮೊದಲ ವೈಫಲ್ಯದಲ್ಲಿ ನಿಲ್ಲಿಸಿ. ಮುಂದೆ ಹಾರುವುದು DNS ಸಮಸ್ಯೆಯನ್ನು ಒಂದು ಗಂಟೆ ಫೈರ್‌ವಾಲ್ ಸಮಸ್ಯೆಯಾಗಿ ಪರಿಗಣಿಸುವ ದಾರಿ.

ಕ್ರಮವು ಪಟ್ಟಿಗಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ.

ಪರಿಶೀಲನೆ 1: ಟನೆಲ್ ಏನನ್ನು ಸಾಗಿಸಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ

Azure VPN Gateway ಟನೆಲ್ ಮುಗಿಸಿ VNet‌ಗೆ ಸೇರಿದ ಸಂಚಾರವನ್ನು ಮುಂದೆ ಕಳುಹಿಸುತ್ತದೆ; ಇದುಸಾಮಾನ್ಯ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನ ಅಲ್ಲ. ಬಳಕೆದಾರರು ತಮ್ಮ ಬ್ರೌಸಿಂಗ್ Azure ಮೂಲಕ ಹೊರಹೋಗಬೇಕು ಎಂದು ನಿರೀಕ್ಷಿಸಿದರೆ, ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಸೆಟ್ಟಿಂಗ್ ಬರುವ ಮೊದಲೇ ವಿನ್ಯಾಸ ತಪ್ಪಾಗಿದೆ. split tunneling ಆನ್ ಮಾಡಿ ಸ್ಥಳೀಯ ಇಂಟರ್ನೆಟ್ ಸ್ಥಳೀಯ ಮಾರ್ಗವನ್ನೇ ಬಳಸಲಿ, ಮತ್ತು ಸ್ಥಿರ ನಿರ್ಗಮನ ವಿಳಾಸ ನಿಜವಾಗಿ ಬೇಕಾದಾಗ NAT ಇನ್‌ಸ್ಟಾನ್ಸ್ ಅಥವಾ ಸೈಟ್-ಟು-ಸೈಟ್ ಟನೆಲ್ ಬಳಸಿ.

ಏನನ್ನೂ ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ಎಲ್ಲಿಗೆ ತಲುಪಬೇಕು ಎಂದು ಬರೆಯಿರಿ. ಆ ಪಟ್ಟಿ ಇಲ್ಲದೆ ಪ್ರತಿ ಭಾಗಶಃ ಫಲಿತಾಂಶವೂ ಪ್ರಗತಿಯಂತೆ ಕಾಣುತ್ತದೆ.

ಪರಿಶೀಲನೆ 2: ಪ್ರಮಾಣಪತ್ರಗಳ ಮೊದಲು ವಿಳಾಸ ಸ್ಥಳಗಳನ್ನು ಹೋಲಿಸಿ

ಅತಿವ್ಯಾಪ್ತಿಯನ್ನು ಅಗಲವಾದ ಶ್ರೇಣಿಗಳ ಮೇಲೆ ನಿರ್ಣಯಿಸಲಾಗುತ್ತದೆ, ಹಾಗಾಗಿ ಸಬ್‌ನೆಟ್ ಮಟ್ಟದಲ್ಲಿ ಬೇರೆಯಾಗಿ ಕಾಣುವ ಎರಡು ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಅವುಗಳ ಮೂಲ ಬ್ಲಾಕ್‌ಗಳು ಅತಿವ್ಯಾಪಿಸಿದರೆ ಇನ್ನೂ ಘರ್ಷಿಸುತ್ತವೆ. ಗೇಟ್‌ವೇ ಸಬ್‌ನೆಟ್ ಮೀಸಲಾದದ್ದಾಗಿರಬೇಕು ಮತ್ತು SKUಗೆ ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿರಬೇಕು, ಮತ್ತು ಕ್ಲೈಂಟ್ ವಿಳಾಸ ಪೂಲ್ VNet ಅಥವಾ peering ಮೂಲಕ ತಲುಪುವ ಯಾವುದರೊಂದಿಗೂ ಘರ್ಷಿಸಬಾರದು. ಯೋಜನೆ ಬದಲಿಸಿ ಮತ್ತೆ ನಿಯೋಜಿಸಿ, ಏಕೆಂದರೆ ಸರಿದೂಗಿಸಲು ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸಿದರೆ ಕೆಲವು ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಕೆಲಸ ಮಾಡುವ ಮತ್ತು ಇತರವಕ್ಕೆ ವಿವರಿಸಲಾಗದಂತೆ ಮಾಡದ ಟನೆಲ್ ಉಂಟಾಗುತ್ತದೆ. ಇಲ್ಲಿ ಒದಗಿಸುವಿಕೆ ಗಟ್ಟಿಯಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಅದೇ ಒಳ್ಳೆಯ ಸಂದರ್ಭ.

ದೃಢೀಕರಣ ಮುಂದಿನ ದ್ವಾರ. ಪ್ರಮಾಣಪತ್ರ, RADIUS ಮತ್ತು Entra ID ಪ್ರೊಫೈಲ್‌ಗಳು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದವು ಅಲ್ಲ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೇಜ್ ಬೇರೆ.

ಪರಿಶೀಲನೆ 3: ಒಳಗಿನಿಂದ ಖಾಸಗಿ ಹೆಸರು ಬಿಡಿಸಿ

ಕ್ಲೈಂಟ್ ತನ್ನದೇ ರಿಸಾಲ್ವರ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಪ್ರೊಫೈಲ್ VNetನ DNS ಸರ್ವರ್‌ಗಳನ್ನು ಹೊತ್ತಿದ್ದರೆ ಹೊರತು, ಮತ್ತು ಆ ಪಟ್ಟಿ ಡೌನ್‌ಲೋಡ್ ಸಮಯದಲ್ಲಿ ಅಳವಡಿಸಲಾಗುತ್ತದೆ. VNet ಒಳಗೆ forwarder ಸೇರಿಸಿ, ಅದನ್ನು VNetನ DNS ಸರ್ವರ್ ಆಗಿ ಹೊಂದಿಸಿ, ನಂತರ ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೇಜ್ ಮತ್ತೆ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಆಮದು ಮಾಡಿ. ಹಳೆಯ ಪ್ಯಾಕೇಜ್ ಮತ್ತೆ ಬಳಸಿದರೆ ಹಳೆಯ ರಿಸಾಲ್ವರ್ ಪಟ್ಟಿಯನ್ನಷ್ಟೇ ಪರೀಕ್ಷಿಸುತ್ತದೆ.

ಮೊದಲು ವಿಳಾಸ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಅದು ಒಂದೇ ಹೆಜ್ಜೆಯಲ್ಲಿ ರೂಟಿಂಗ್ ಮತ್ತು ಹೆಸರಿಸುವಿಕೆಯನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ: Test-NetConnection 10.20.1.4 -Port 3389.

ವಿಳಾಸ ಉತ್ತರಿಸಿ ಹೆಸರು ಉತ್ತರಿಸದಿದ್ದರೆ, ರಿಸಾಲ್ವರ್‌ಗೆ ನೇರವಾಗಿ ಕೇಳಿ Resolve-DnsName files.corp.example -Server 10.20.0.4. ಎರಡೂ ವಿಫಲವಾದರೆ, ದೋಷ DNSನದಲ್ಲ ಮತ್ತು ನೀವು DNS ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸಂಪಾದಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕು. 168.63.129.16ನಲ್ಲಿ Azure ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ DNS VNetನ ಒಳಗಿನಿಂದ ಮಾತ್ರ ಉತ್ತರಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ಹೊರಗಿನ ಕ್ಲೈಂಟ್ ಆ ವಿಳಾಸವನ್ನು ರಿಸಾಲ್ವರ್ ಆಗಿ ಬಳಸಲಾಗದು.

ಪರಿಶೀಲನೆ 4: ಟನೆಲ್‌ನ ಹಿಂದಿನ ಸೇವೆ ಪರೀಕ್ಷಿಸಿ

ಆರೋಗ್ಯಕರ ಟನೆಲ್ ಮತ್ತು ಮುಚ್ಚಿದ ಪೋರ್ಟ್ ಕ್ಲೈಂಟ್‌ನಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ. ಅತಿಥಿ ಫೈರ್‌ವಾಲ್ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಸಬ್‌ನೆಟ್ ಅಥವಾ NICನ ನೆಟ್‌ವರ್ಕ್ ಭದ್ರತಾ ಗುಂಪು, ನಂತರ ಸೇವೆ ಖಾಸಗಿ ವಿಳಾಸದಲ್ಲಿ ಕೇಳುತ್ತದೆಯೇ ಅಥವಾ loopbackನಲ್ಲಿ ಮಾತ್ರ ಎಂದು. ಇಂಟರ್ನೆಟ್‌ಗೆ ನಿಯಮ ತೆರೆಯುವ ಬದಲು ಕ್ಲೈಂಟ್ ಪೂಲ್‌ಗೆ ಮೂಲವಾಗಿ ಅನುಮತಿ ನೀಡಿ, ಮತ್ತು Azure Filesಗೆ SMBಗೆ ಖಾಸಗಿ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮಾರ್ಗ ಟನೆಲ್ ಮೂಲಕ ಹೋಗಬೇಕು ಎಂದು ನೆನಪಿಡಿ. ಸಂಪನ್ಮೂಲ IPಯಿಂದ ಉತ್ತರಿಸಿ ಹೆಸರಿನಿಂದ ಉತ್ತರಿಸದಿದ್ದರೆ, ಗೇಟ್‌ವೇ ಮುಟ್ಟುವ ಬದಲು ಪರಿಶೀಲನೆ 3ಗೆ ಮರಳಿ.

ಕೆಲಸ ಮಾಡುವಾಗ ಒಂದು ಕೋಷ್ಟಕ ಪದರಗಳನ್ನು ಬೇರ್ಪಡಿಸಿಡುತ್ತದೆ:

SymptomLayer to check
Name fails, private IP worksResolver setting or forwarder
Private IP also failsAddress plan, NSG, guest firewall
Private works, internet failsExpected; the gateway is not an egress
Connects, then dropsTunnel type or certificate mismatch

ಪರಿಶೀಲನೆ 5: ಏರಿಸುವ ಮೊದಲು ಪ್ರೊಫೈಲ್ ದಾಖಲಿಸಿ

ಟಿಕೆಟ್‌ನಲ್ಲಿ ಗೇಟ್‌ವೇ ಪ್ರಕಾರ, ಟನೆಲ್ ಪ್ರಕಾರ, ದೃಢೀಕರಣ ವಿಧಾನ ಮತ್ತು ಕ್ಲೈಂಟ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ ಬರೆಯಿರಿ. ಪ್ರಮಾಣಪತ್ರದ IKEv2 ಪ್ರೊಫೈಲ್ ಮತ್ತು RADIUS ಪ್ರೊಫೈಲ್ ಬೇರೆ ಬೇರೆ ಕಾರಣಗಳಿಂದ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಬೇರೆ ಟನೆಲ್ ಪ್ರಕಾರಕ್ಕೆ ನಿರ್ಮಿಸಿದ ಕ್ಲೈಂಟ್ ಗೇಟ್‌ವೇ ಹೊಂದುವ ಪ್ರೋಟೋಕಾಲ್ ನೀಡಿದಾಗ ಮಾತ್ರ ಸಂಪರ್ಕವಾಗುತ್ತದೆ.

ಸಣ್ಣ ತಂಡಕ್ಕೆ ಬಾಳಿಕೆ ಬರುವ ವಿನ್ಯಾಸ ಎಂದರೆ ಒಂದು VNet, ಒಂದು DNS forwarder ಮತ್ತು ದಾಖಲಿತ split-tunnel ಕ್ಲೈಂಟ್. ಅಗತ್ಯವು ಸ್ಥಿರ ಸಾರ್ವಜನಿಕ ನಿರ್ಗಮನವಾದರೆ, ನೀವು ನಿಯಂತ್ರಿಸುವ ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ ಸೈಟ್-ಟು-ಸೈಟ್ ಟನೆಲ್ ಮುಗಿಸಿ ಇಂಟರ್ನೆಟ್ ಸಂಚಾರವನ್ನು ಅಲ್ಲಿಗೆ ರೂಟ್ ಮಾಡಿ, ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ಗೇಟ್‌ವೇಗೆ ಅದಕ್ಕೆ ಎಂದೂ ನಿರ್ಮಿಸದ ಕೆಲಸ ಕೇಳುವ ಬದಲು.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು