Windows NAT-T ರಿಜಿಸ್ಟ್ರಿ ಮೌಲ್ಯ: ಮೊದಲು ಟೋಪೊಲಜಿ ಪರಿಶೀಲಿಸಿ

Windows VPN ಸಂಪರ್ಕ ವಿಫಲವಾಗುತ್ತದೆ, ಹುಡುಕಾಟವು ರಿಜಿಸ್ಟ್ರಿ ಮೌಲ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಮೌಲ್ಯವನ್ನು ಮರುಪ್ರಾರಂಭದೊಂದಿಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಆ ಕ್ರಮ ಕೆಲವೊಮ್ಮೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಎಂದಿಗೂ ಏನನ್ನೂ ವಿವರಿಸುವುದಿಲ್ಲ. ಪ್ರಶ್ನೆಯಲ್ಲಿರುವ ಸೆಟ್ಟಿಂಗ್ ಸರ್ವರ್ NAT ಸಾಧನಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಎಲ್ಲಿದೆ ಎಂಬ ಒಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವ ಪ್ರೋಟೋಕಾಲ್ ಯಾವ ಹಂತದಲ್ಲಿ ವಿಫಲವಾಯಿತು ಎಂದು ತಿಳಿಯುವವರೆಗೆ ಅದು ಅರ್ಥಹೀನವಾಗಿದೆ.

ಮೌಲ್ಯವು ನಿಜವಾಗಿ ಏನನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ

AssumeUDPEncapsulationContextOnSendRule NAT ಸಾಧನದ ಹಿಂದೆ ಇರುವ ಸಹಚರದೊಂದಿಗೆ Windows ನ IPsec ಅನುಷ್ಠಾನವು ಸಂಬಂಧಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ದಾಖಲಿತ ಡೀಫಾಲ್ಟ್ 0 ಆ ಪ್ರಕರಣವನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ, ಸರ್ವರ್ NAT ನ ಹಿಂದಿನ ಬದಿಯಾಗಿದ್ದಾಗ 1 ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು 2 ಎರಡೂ ತುದಿಗಳನ್ನು ಅನುವಾದಿಸುವ ಪ್ರಕರಣವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಇವು ಟೋಪೊಲಜಿ ಕುರಿತಾದ ಹೇಳಿಕೆಗಳು—ಯಾರು ಎಲ್ಲಿದ್ದಾರೆ.

ಕ್ರಮವಾಗಿ ಓದಿದಾಗ ಸಂಖ್ಯೆಗಳು ಹೆಚ್ಚುತ್ತಿರುವ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನಲ್ಲ, ಹೆಚ್ಚುತ್ತಿರುವ ಅನುವಾದವನ್ನು ವಿವರಿಸುತ್ತವೆ. ಏನನ್ನೂ ಅನುವಾದಿಸದ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ 2 ಅನ್ನು ಹೊಂದಿಸುವುದು ಸಂಪರ್ಕವನ್ನು ವೇಗವಾಗಿಸುವುದಿಲ್ಲ ಅಥವಾ ಸ್ಥಿರಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ದೃಢೀಕರಣ ವೈಫಲ್ಯವನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. Microsoft ನ L2TP/IPsec ಗಾಗಿ NAT ಮಾರ್ಗದರ್ಶನ ನೀತಿ ಮತ್ತು ಅದರ ಐತಿಹಾಸಿಕ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸಂದರ್ಭವನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ನೀವು ನಿಜವಾಗಿ ಚಲಾಯಿಸುವ Windows ಆವೃತ್ತಿ ಮತ್ತು ಪಾತ್ರದೊಂದಿಗೆ ಆ ಸಂದರ್ಭವನ್ನು ಹೋಲಿಸಿ, ಏಕೆಂದರೆ ಹಲವು ಬಿಡುಗಡೆಗಳನ್ನು ದಾಟಿದ ದಾಖಲೆಯು ಪ್ರತಿ ಪ್ರಸ್ತುತ ಬಿಲ್ಡ್ ಬಗ್ಗೆ ಹೇಳಿಕೆಯಲ್ಲ.

ಸಂಖ್ಯೆಗಿಂತ ಮೊದಲು ಟೋಪೊಲಜಿಯನ್ನು ಹೊಂದಿಸಿ

ಮಾರ್ಗವನ್ನು ಎಳೆಯಿರಿ ಮತ್ತು ಅನುವಾದ ಬಿಂದುಗಳನ್ನು ಗುರುತಿಸಿ: ಕ್ಲೈಂಟ್ ಮನೆಯ ರೌಟರ್‌ನ ಹಿಂದೆ ಇದೆಯೇ, ಸರ್ವರ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅಥವಾ ವಿಳಾಸಗಳನ್ನು ಮರುಬರೆಯುವ ಫೈರ್‌ವಾಲ್‌ನ ಹಿಂದೆ ಇದೆಯೇ, ಮತ್ತು ಯಾವುದಾದರೂ ತುದಿ ನೀವು ನಿಯಂತ್ರಿಸದ ವಾಹಕ ಅನುವಾದದ ಹಿಂದೆ ಇದೆಯೇ. ಆ ರೇಖಾಚಿತ್ರದ ನಂತರವೇ ಮೌಲ್ಯವು ಅನ್ವಯಿಸುತ್ತದೆಯೇ ಮತ್ತು ಯಾವ ತುದಿಗೆ ಎಂದು ನಿರ್ಧರಿಸಬಹುದು.

ಪ್ರಸ್ತುತ Windows Server ಆವೃತ್ತಿಗಳು ಕೇವಲ NAT traversal ನಿಷ್ಕ್ರಿಯಗೊಂಡ ಸ್ಥಿತಿಯಲ್ಲಿ ಬರುತ್ತವೆ ಎಂಬ ಹೇಳಿಕೆ ಕ್ರಮಕ್ಕೆ ತುಂಬಾ ವಿಶಾಲವಾಗಿದೆ. ಮುಖ್ಯವಾದುದು ನಿಮ್ಮ ಸಿಸ್ಟಂನ ನೀತಿ, ಅದರ ಮುಂದಿನ ಟೋಪೊಲಜಿ ಮತ್ತು ವಿಫಲವಾದ ವಿನಿಮಯ—ಅದೇ ಕ್ರಮದಲ್ಲಿ. ಎರಡೂ ತುದಿಗಳಿಗೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಗಳಿದ್ದರೆ, ಸೆಟ್ಟಿಂಗ್ ನಿಮ್ಮ ಸಮಸ್ಯೆಯಲ್ಲ. ಬದಲಿಗೆ ಪ್ರಸ್ತಾವ, ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಖಾತೆಯನ್ನು ನೋಡಿ, ಮತ್ತು ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಬಿಡಿ.

ಮೊದಲು ವೈಫಲ್ಯದ ಹಂತವನ್ನು ಪರಿಶೀಲಿಸಿ

L2TP/IPsec ಕನಿಷ್ಠ ಮೂರು ವಿಭಿನ್ನ ವೈಫಲ್ಯಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ: ಸಹಚರನನ್ನು ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ, IPsec ರಕ್ಷಣೆಯನ್ನು ಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಸುರಂಗ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ನಂತರ PPP ಬಳಕೆದಾರ ದೃಢೀಕರಣವನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ತಿರಸ್ಕೃತ ಖಾತೆಯನ್ನು NAT ನೀತಿ ಬದಲಿಸಿ ಸರಿಪಡಿಸಲಾಗದು, ಮತ್ತು ಪ್ರಸ್ತಾವಗಳ ಅಸಾಮರಸ್ಯವನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಸರಿಪಡಿಸಲಾಗದು.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

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

HTTPS ಮೇಲಿನ SSTP ಮತ್ತು ಸ್ಥಳೀಯ IKEv2 ತಮ್ಮದೇ ಲಾಗ್‌ಗಳು ಮತ್ತು ತಮ್ಮದೇ ನಿಯಂತ್ರಣಗಳನ್ನು ಹೊಂದಿವೆ. ಕೇವಲ Windows ನಲ್ಲೂ ಚಲಿಸುವ ಕಾರಣದಿಂದ ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ NAT-traversal ಪ್ರಕರಣವಾಗುವುದಿಲ್ಲ.

ಹಿಂತಿರುಗುವ ದಾರಿಯೊಂದಿಗೆ ಬದಲಾವಣೆ ಮಾಡಿ

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

NAT ಸಾಧನವು ಇನ್ನೂ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ಸಾರಿಗೆ ಮತ್ತು ಹಿಂತಿರುಗುವ ಸಂಚಾರವನ್ನು ಹೊತ್ತೊಯ್ಯಬೇಕು. ರಿಜಿಸ್ಟ್ರಿ ಮೌಲ್ಯವು ಯಾವುದೇ ಮುಂದಕ್ಕೆ ರವಾನೆ ನಿಯಮವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ, ಯಾವುದೇ ಪ್ರಸ್ತಾವವನ್ನು ಜೋಡಿಸುವುದಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಗುರುತನ್ನು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಬದಲಾವಣೆಯ ನಂತರ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ ಸಂಪರ್ಕ ಸಂಪೂರ್ಣ ಬೇರೆ ಕಾರಣಕ್ಕೆ ಕೆಲಸ ಮಾಡುತ್ತಿರಬಹುದು. ಮೂಲ ಟೋಪೊಲಜಿಯೊಂದಿಗೆ ಮೂಲ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಯಾವ ಹಂತ ವಿಫಲವಾಯಿತು ಮತ್ತು ಮೌಲ್ಯವು ಅದನ್ನು ಏಕೆ ಪರಿಹರಿಸಬೇಕಿತ್ತು ಎಂದು ಬರೆಯಿರಿ. ಆ ವಾಕ್ಯವೇ ಇಂಟರ್ನೆಟ್ ವದಂತಿಯನ್ನು ಸಮರ್ಥಿಸಬಹುದಾದ ಸಂರಚನೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.