ಯಾವ VPN ಹಂತ ವಿಫಲವಾಯಿತು: IPsec, L2TP ನಿಯಂತ್ರಣ ಅಥವಾ PPP ದೃಢೀಕರಣ
ಕೊನೆಯ ಯಶಸ್ವಿ ಹಂತವನ್ನು ಕಂಡುಹಿಡಿದು ಆ ಪದರವನ್ನು ಮಾತ್ರ ಸರಿಪಡಿಸಿ: IPsec, L2TP ನಿಯಂತ್ರಣ ಚಾನಲ್, PPP ದೃಢೀಕರಣ ಅಥವಾ ವಿಳಾಸ ಹಂಚಿಕೆ.
ನೀವು ಪಾಸ್‌ವರ್ಡ್ ಬದಲಿಸಿದಿರಿ ಮತ್ತು ಏನೂ ಚಲಿಸಲಿಲ್ಲ, ಏಕೆಂದರೆ ವೈಫಲ್ಯ ಎಂದೂ PPP ನಲ್ಲಿರಲಿಲ್ಲ. L2TP/IPsec ಐದು ಸಂಪೂರ್ಣ ಭಿನ್ನ ಹಸ್ತಾಂತರಗಳಿಗೆ ಒಂದೇ ಸಂಪರ್ಕ ದೋಷವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಹಸ್ತಾಂತರಕ್ಕೂ ತನ್ನದೇ ದುರಸ್ತಿ ಇದೆ. ಹಿಮ್ಮುಖವಾಗಿ ಕೆಲಸ ಮಾಡಿ: ಕೊನೆಯ ಯಶಸ್ವಿ ಹಂತವನ್ನು ಕಂಡುಹಿಡಿದು ಅದರ ನಂತರ ಬರುವುದನ್ನು ಮಾತ್ರ ಬದಲಿಸಿ. ಕೆಳಗಿನ ಕ್ರಮವು ಮೊದಲು ಯಾವ ಸಾಕ್ಷ್ಯ ಸಂಗ್ರಹಿಸಬೇಕೆಂದೂ ತೀರ್ಮಾನಿಸುತ್ತದೆ.
ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳಿಗೆ ಕ್ರಮವಾಗಿ ಉತ್ತರಿಸಿ
ಹೊಸ ಪ್ರಯತ್ನವನ್ನು ಒತ್ತಾಯಿಸಿ, ಏಕೆಂದರೆ ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳು ಪ್ರೊಫೈಲ್ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡು ಮತ್ತೆ ಸಂಪರ್ಕಗೊಳ್ಳುವವರೆಗೂ ಹಿಂದಿನ ದೋಷವನ್ನೇ ತೋರಿಸುತ್ತವೆ. ನಂತರ ಇದಕ್ಕೆ ಉತ್ತರಿಸಿ: IPsec ಭದ್ರತಾ ಸಂಯೋಗ ಇತ್ತೇ, L2TP ನಿಯಂತ್ರಣ ಸಂಪರ್ಕ ಮತ್ತು ಕರೆ ಕಾಣಿಸಿಕೊಂಡವೇ, PPP ದೃಢೀಕರಣ ತೀರ್ಪನ್ನು ತಲುಪಿತೇ, ಮತ್ತು IPCP ಕ್ಲೈಂಟ್‌ಗೆ ವಿಳಾಸ ನೀಡಿತೇ? ಮೊದಲ ಇಲ್ಲ ಎಂಬುದೇ ನೀವು ಸರಿಪಡಿಸುವ ಹಂತ. ಅದರ ನಂತರದ್ದೆಲ್ಲಾ ಪರೀಕ್ಷಿಸದ್ದು, ಆದ್ದರಿಂದ ಸಂಯೋಗವೇ ಇಲ್ಲದಿದ್ದಾಗ ತಿರಸ್ಕೃತ ಬಳಕೆದಾರಹೆಸರು ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಹೋಲಿಸುವ ಮೊದಲು ಎರಡೂ ತುದಿಗಳ ಗಡಿಯಾರಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿ. IPsec ಅನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಿ PPP ನಲ್ಲಿ ವಿಫಲವಾದ ಮರುಪ್ರಯತ್ನ, ಕ್ಲೈಂಟ್ ಕೇವಲ ಅಂತಿಮ ಸಂದೇಶವನ್ನು ತೋರಿಸಿದಾಗ ಮತ್ತು ಸರ್ವರ್ ಲಾಗ್ ಇನ್ನೂ ಹಿಂದಿನ ಪ್ರಯತ್ನವನ್ನು ಇಟ್ಟುಕೊಂಡಾಗ ಒಂದೇ ವೈಫಲ್ಯದಂತೆ ಕಾಣುತ್ತದೆ. ಅತಿ ಗಟ್ಟಿಯಾದ ಸಾಲಿನಿಂದಲ್ಲ, ಸಮಯ ಮುದ್ರೆಯಿಂದ ಓದಿ.
ನಿಮ್ಮ ಬಳಿ ಬಳಕೆದಾರರ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಮಾತ್ರ ಇದ್ದಾಗ ಅತ್ಯಂತ ಅಗ್ಗದ ವಿಭಜನೆಯನ್ನು ಅವಲಂಬಿಸಿ: ತಪ್ಪಾದ ಪೂರ್ವ-ಹಂಚಿಕೆ ಕೀ ಮತ್ತು ಎಂದೂ ಉತ್ತರಿಸದ xl2tpd Windows ಸಂವಾದದಲ್ಲಿ ಒಂದೇ ಪಠ್ಯವನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ, ಆದರೆ ಒಂದಕ್ಕೆ ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಬದಲಾದ ರಹಸ್ಯ ಬೇಕು, ಇನ್ನೊಂದಕ್ಕೆ ಸರ್ವರ್‌ನಲ್ಲೇ ಪ್ರಾರಂಭಿಸಿದ ಡೀಮನ್ ಅಥವಾ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಬೇಕು. ಮಧ್ಯದ ಸಾಧನವು ಒಳಗಿನ 1701 ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಮೋಡ್ IPsec ಸುತ್ತಿದ ನಂತರ ಬಿಡಲಾಗದು, ಆದ್ದರಿಂದ ಇಲ್ಲದ ಮಾರ್ಗ ಫಿಲ್ಟರ್ ಹುಡುಕಬೇಡಿ.
ಪ್ರತಿ ಪದರ ನಿಜವಾಗಿ ಏನನ್ನು ಹೊಂದಿದೆ
IPsec ಎರಡು ಸಹವರ್ತಿಗಳ ನಡುವೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರಕ್ಷಿಸುತ್ತದೆ; L2TP ಆ ರಕ್ಷಿತ ಮಾರ್ಗದ ಒಳಗೆ PPP ಅಧಿವೇಶನವನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದಲೇ RFC 3193 ತನ್ನದೇ ಸುರಂಗದ ಬದಲು ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಮೋಡ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಲೇಬಲ್ L2TP ಎನ್ನುತ್ತದೆ, ಆದ್ದರಿಂದ ಸುರಂಗ ಮತ್ತು ಲಾಗಿನ್ ಒಂದೇ ಕಾರ್ಯವಿಧಾನವೆನಿಸುತ್ತವೆ. ಹಾಗಲ್ಲ: L2TP ನಿಯಂತ್ರಣ ಸಂಪರ್ಕವು ನಿಯೋಜನೆ ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಲ್ಲಿ ಸುರಂಗದ ತುದಿಗಳನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ, ಮತ್ತು PPP ಸರ್ವರ್ ನೀತಿಯ ಪ್ರಕಾರ CHAP, PAP ಅಥವಾ MS-CHAPv2 ಮೂಲಕ ಬಳಕೆದಾರರನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ದೃಢೀಕರಿಸುತ್ತದೆ.
ಈ ವಿಭಜನೆಯೇ ಜನರು ಗೊಂದಲಿಸುವ ಎರಡು ರಹಸ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಪೂರ್ವ-ಹಂಚಿಕೆ ಕೀ IPsec ಸಹವರ್ತಿಗಳನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ಬಳಕೆದಾರಹೆಸರು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಬಳಕೆದಾರರನ್ನು PPP ಗೆ ಗುರುತಿಸುತ್ತವೆ. ಪ್ರಮಾಣಪತ್ರಗಳಿಂದ ದೃಢೀಕರಿಸುವ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ Windows ನ ಹಂಚಿಕೆ ರಹಸ್ಯವನ್ನು ಮತ್ತೆ ಟೈಪ್ ಮಾಡುವುದು ವಿಫಲ ಹಂತದಲ್ಲಿ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು PPP ಪಾಸ್‌ವರ್ಡ್ ಸಂಪಾದಿಸುವುದು ಕಾಣೆಯಾದ ರಕ್ಷಿತ ಚಾನಲ್ ಒದಗಿಸಲಾಗದು. ಅದೇ ಸಂಯಮ ಗುರುತಿನ ಪರಿಶೀಲನೆಗೂ ಅನ್ವಯಿಸುತ್ತದೆ: ಸುರಂಗ ಪಡೆಯಲು ಸಹವರ್ತಿಯ ಗುರುತು ಅಥವಾ ಪ್ರಮಾಣಪತ್ರ ಮಾನ್ಯತೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಆಗ ಸಂಪರ್ಕಗೊಳ್ಳುವುದು ಮಾರ್ಗ, ಸಹವರ್ತಿಯಲ್ಲ.
ದೃಢೀಕರಣವೂ PPP ಯ ಅಂತ್ಯವಲ್ಲ. ಬಳಕೆದಾರರು ಸ್ವೀಕೃತರಾದ ನಂತರ IPCP ಕ್ಲೈಂಟ್‌ನ ವಿಳಾಸ ಮತ್ತು ಸರ್ವರ್ ನೀಡಲು ಸಿದ್ಧವಿರುವ DNS ಹಾಗೂ WINS ಆಯ್ಕೆಗಳನ್ನು ಮಾತುಕತೆ ಮಾಡುತ್ತದೆ. ಕ್ಲೈಂಟ್ CHAP ಅಥವಾ MS-CHAPv2 ಪಾಸಾಗಿಯೂ ವಿಳಾಸವಿಲ್ಲದೆ ಉಳಿಯಬಹುದು, ಅದು PPP ಯ ಒಳಗಿನ ವೈಫಲ್ಯ, ಮಾರ್ಗ ನಿರ್ದೇಶನ ಸಮಸ್ಯೆಯಲ್ಲ. IPsec ಇಲ್ಲದ ಸಾಮಾನ್ಯ L2TP ಮಾನ್ಯ ಮತ್ತು ಅಸುರಕ್ಷಿತವಾಗಿ ಉಳಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಶಸ್ವಿ ಸಂಪರ್ಕವು ಸಂಚಾರ ರಕ್ಷಿತವೆಂದು ಎಂದೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ; ಸರ್ವರ್ ಏನು ಒತ್ತಾಯಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಕ್ಲೈಂಟ್ ಲೇಬಲ್ ಅಲ್ಲ.
ಮೊದಲ ಕಾಣೆಯಾದ ಹಂತದಿಂದ ನಿರ್ಧರಿಸಿ
ಕೋಷ್ಟಕವನ್ನು ಮೊದಲ ಕಾಣೆಯಾದ ಅಂಶದಿಂದ, ಎಡದಿಂದ ಬಲಕ್ಕೆ ಓದಿ. ಬಲ ಕಾಲಮ್ ಆ ಕ್ಷಣದಲ್ಲಿ ಯೋಗ್ಯವಾದ ಏಕೈಕ ಕೆಲಸ; ಅದರ ಎಡಕ್ಕಿರುವುದೆಲ್ಲಾ ಈಗಾಗಲೇ ಸಾಬೀತಾಗಿದೆ, ಮತ್ತು ಅದನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸುವುದು ಮಾಹಿತಿ ಸೇರಿಸದೆ ಅಡಚಣೆ ಕಿಟಕಿಯನ್ನು ಸುಡುತ್ತದೆ.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
ಮೂರು ಸಾಲುಗಳು ಎಚ್ಚರಿಕೆಗೆ ಅರ್ಹ. 1701 ಸಾಲು NAT ಹಿಂದಿನ Windows ಕ್ಲೈಂಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಇಳಿಯುವ ಸ್ಥಳ: ಸಂಯೋಗ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, ನಂತರ ಏನೂ ಬರುವುದಿಲ್ಲ, ಮತ್ತು ಕಾರಣ ಕೆಟ್ಟ ಪಾಸ್‌ವರ್ಡ್ ಅಲ್ಲ, ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್. IPCP ಸಾಲು ಮಾರ್ಗ ಸಮಸ್ಯೆ ಎಂದು ತಪ್ಪಾಗಿ ಓದಲ್ಪಡುವ ಸಾಲು, ಏಕೆಂದರೆ Windows ಕಾಣೆಯಾದ ವಿಳಾಸವನ್ನು ದೋಷ 720 ರಲ್ಲಿ ಸುತ್ತುತ್ತದೆ ಮತ್ತು ಟ್ರೇ ಚಿಹ್ನೆ ಸಂಪರ್ಕ ವಿಫಲವಾಯಿತು ಎಂದಷ್ಟೇ ಹೇಳುತ್ತದೆ; ಆ ವೈಫಲ್ಯ ದೃಢೀಕರಣದ ನಂತರ ಮತ್ತು ಮಾರ್ಗ ನಿರ್ದೇಶನದ ಮೊದಲು ಇರುತ್ತದೆ. ಕೊನೆಯ ಸಾಲು ಸಂಪೂರ್ಣವಾಗಿ IPsec ವೈಫಲ್ಯವಲ್ಲ, ಚಿಹ್ನೆ ಸಂಪರ್ಕ ಕಡಿತ ಎಂದು ಹೇಳಿದರೂ.
ಪದರಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಆದೇಶಗಳು
strongSwan ನಡೆಸುವ Linux ಸರ್ವರ್‌ನಲ್ಲಿ swanctl --list-sas ಸ್ಥಾಪಿತ ಸಂಯೋಗಗಳನ್ನು ಅವುಗಳ ಸಹವರ್ತಿ ಗುರುತಿನೊಂದಿಗೆ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ipsec statusall ಹಳೆಯ strongSwan ಹಾಗೂ libreswan ಹೋಸ್ಟ್‌ಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಅದರ ಕೆಳಗೆ ip xfrm state ಕರ್ನಲ್‌ನ ನಿಜವಾದ ಸಂಯೋಗಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ss -lunp | grep 1701 xl2tpd ಎಲ್ಲಿ ಬಂಧಿಸಲಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ನಿಯಂತ್ರಣ ಸಂಪರ್ಕಗಳು ಮತ್ತು ಕರೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುವುದನ್ನು ನೋಡಲು xl2tpd -D ಅನ್ನು ಮುಂಭಾಗದಲ್ಲಿ ಚಲಾಯಿಸಿ, ಮತ್ತು ಸೂಚಿಸಿದ ವಿಧಾನ ಹಾಗೂ ಉತ್ತರ ನೋಡಲು /etc/ppp/options.xl2tpd ನಲ್ಲಿ pppd ಡೀಬಗ್ ಆನ್ ಮಾಡಿ.
ಲಾಗ್‌ಗಳು ಯಶಸ್ವಿ ದೃಢೀಕರಣ ತೋರಿಸಿದ ನಂತರ ಮುಂದಿನ ಪ್ರಶ್ನೆ IPCP ಪೂರ್ಣಗೊಂಡಿತೇ ಎಂಬುದು. /etc/xl2tpd/xl2tpd.conf ನ [lns default] ವಿಭಾಗದಲ್ಲಿ ip range ಗೆ ಇನ್ನೂ ಮುಕ್ತ ವಿಳಾಸಗಳಿವೆಯೇ ಮತ್ತು ಕ್ಲೈಂಟ್ ನಿರೀಕ್ಷಿಸಿದರೆ /etc/ppp/options.xl2tpd ನಿಜವಾಗಿ ms-dns ಮತ್ತು ms-wins ಹೊಂದಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಖಾಲಿಯಾದ ಪೂಲ್ ಮತ್ತು ಕಾಣೆಯಾದ DNS ಆಯ್ಕೆ ತಂತಿಯಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ಕಾಣುತ್ತವೆ: ಮೊದಲನೆಯದು ಕ್ಲೈಂಟ್ ಅನ್ನು ವಿಳಾಸವಿಲ್ಲದೆ ಮತ್ತು 720 ಜೊತೆ ಬಿಡುತ್ತದೆ, ಎರಡನೆಯದು ವಿಳಾಸ ನೀಡುತ್ತದೆ ಆದರೆ ಪರಿಹಾರಕವಿಲ್ಲ, ಆದ್ದರಿಂದ ಹೆಸರುಗಳು ವಿಫಲವಾಗುತ್ತವೆ ಆದರೆ ಕಚ್ಚಾ ವಿಳಾಸಗಳಿಗೆ ping ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಎರಡನ್ನೂ ಪಾಸ್‌ವರ್ಡ್ ಮತ್ತೆ ನಮೂದಿಸಿ ಸರಿಪಡಿಸಲಾಗದು.
ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ NetworkManager ನ L2TP ಪ್ಲಗಿನ್ pppd ಸಂಭಾಷಣೆಯನ್ನು ಜರ್ನಲ್‌ಗೆ ಬರೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ journalctl -u NetworkManager -b ಸಾಮಾನ್ಯವಾಗಿ ಸುರಂಗ ಮೇಲಿದೆ, ದೃಢೀಕರಣ ತಿರಸ್ಕೃತ ಸ್ಥಿತಿಯನ್ನು ಸುರಂಗವೇ ಇಲ್ಲ ಸ್ಥಿತಿಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. Windows ನಲ್ಲಿ Get-VpnConnection ಪ್ರೊಫೈಲ್‌ನ ನಿಜವಾದ ದೃಢೀಕರಣ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು Event Viewer ನಲ್ಲಿ Application ಅಡಿಯ RasClient ಘಟನೆಗಳು ವಿಫಲವಾದ ಘಟಕವನ್ನು ಹೆಸರಿಸುತ್ತವೆ. ಸಂವಾದ ತೀರಾ ಅಸ್ಪಷ್ಟವಾದಾಗ netsh ras set tracing * enable ಸಕ್ರಿಯಗೊಳಿಸಿ.
ಸೆರೆಹಿಡಿಯುವಿಕೆಗೆ ಒಂದು ಎಚ್ಚರಿಕೆ ಬೇಕು. ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಮೋಡ್ IPsec ನಲ್ಲಿ ಒಳಗಿನ UDP 1701 ಗೂಢಲಿಪೀಕರಿಸಲ್ಪಟ್ಟಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೊರ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಸೆರೆ ESP ತೋರಿಸುತ್ತದೆ, ಅಥವಾ NAT-T ಅಡಿಯಲ್ಲಿ UDP 4500, ಮತ್ತು L2TP ಯಾವುದೂ ಇಲ್ಲ. ಸೆರೆಯಲ್ಲಿ 1701 ಇಲ್ಲದಿರುವುದು ನಿರೀಕ್ಷಿತವಾದದ್ದು ಮತ್ತು ತಡೆಹಿಡಿದ ಪೋರ್ಟ್‌ನ ಸಾಕ್ಷ್ಯವಲ್ಲ; ESP ಅಥವಾ 4500 ಕೌಂಟರ್‌ಗಳು ಚಲಿಸುತ್ತವೆಯೇ ನೋಡಿ.
NAT, MTU ಮತ್ತು ಮಾರ್ಗಗಳು: ಸ್ಟಾಕ್ ನಿಮ್ಮನ್ನು ಎಲ್ಲಿ ದಾರಿತಪ್ಪಿಸುತ್ತದೆ
ಏನನ್ನೂ ದೃಢೀಕರಿಸುವ ಮೊದಲೇ NAT ಊಹೆಗಳನ್ನು ಮುರಿಯುತ್ತದೆ. ESP ತನ್ನದೇ IP ಪ್ರೋಟೋಕಾಲ್, ಆದ್ದರಿಂದ ಭಾಷಾಂತರಿಸುವ ಸಾಧನವು ಸಹವರ್ತಿಗಳು ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟ್ ಮಾಡದಿದ್ದರೆ ಅದನ್ನು ಬಿಸಾಡುತ್ತದೆ; UDP 4500 ಅದನ್ನೇ ಒದಗಿಸುತ್ತದೆ. ತಾನೇ ಮನೆ ರೌಟರ್ ಅಥವಾ ಕ್ಲೌಡ್ NAT ಗೇಟ್‌ವೇ ಹಿಂದೆ ಇರುವ Windows ಸರ್ವರ್‌ನಲ್ಲಿ IPsec ಹಂತ ದೋಷ 789 ನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ, PolicyAgent ಕೀ ಅಡಿಯಲ್ಲಿ AssumeUDPEncapsulationContextOnSendRule ಅನ್ನು 2 ಗೆ ಹೊಂದಿಸಿ ಯಂತ್ರ ಮರುಪ್ರಾರಂಭವಾಗುವವರೆಗೂ, ಮತ್ತು ವೈಫಲ್ಯ ಮುಚ್ಚಿದ ಪೋರ್ಟ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾಗದು. NAT ಹಿಂದಿನ ಕ್ಲೈಂಟ್‌ಗಳು ಸುಲಭ: ಸರ್ವರ್‌ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವಿದ್ದರೆ UDP 4500 ಮೇಲಿನ NAT-T ಅವರನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಆ ಮೌಲ್ಯ ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ.
PPP ಮೇಲಕ್ಕೆ ಬಂದ ನಂತರ ಕಪ್ಪು ಕುಳಿಯ MTU ಸತ್ತ ಸುರಂಗವನ್ನು ಅನುಕರಿಸುತ್ತದೆ: ಸಣ್ಣ ಪ್ಯಾಕೆಟ್‌ಗಳು ದಾಟುತ್ತವೆ, TLS ಹಸ್ತಲಾಘವ ಅಥವಾ ಪುಟ ಲೋಡ್ ನೇತಾಡುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸಂಪರ್ಕಿತ ಎಂದು ತೋರಿಸಬಹುದು. ಸರ್ವರ್‌ಗೆ ದೂಷಿಸುವ ಮೊದಲು ಇಂಟರ್‌ಫೇಸ್ MTU ಕಡಿಮೆ ಮಾಡಿ ಅಥವಾ ಗೇಟ್‌ವೇಯಲ್ಲಿ MSS ಕ್ಲ್ಯಾಂಪ್ ಮಾಡಿ. ವಿಭಜಿತ ಸುರಂಗ ಮಾರ್ಗ ನಿರ್ದೇಶನ ಇನ್ನೊಂದು ಮೋಸಗಾರ; ತಪ್ಪು ಮಾಸ್ಕ್‌ನೊಂದಿಗೆ ಕಳುಹಿಸಿದ ಉಪಜಾಲ ಸುರಂಗವನ್ನು ಆರೋಗ್ಯಕರವಾಗಿ ಮತ್ತು ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತಲುಪಲಾಗದಂತೆ ಬಿಡುತ್ತದೆ. ಖಾಸಗಿ ಹೋಸ್ಟ್‌ಹೆಸರು ತನ್ನದೇ ಹೆಜ್ಜೆ ಸೇರಿಸುತ್ತದೆ: ಪ್ರಶ್ನೆ ಸ್ಥಳೀಯ ಪರಿಹಾರಕದ ಮೂಲಕ ಹೊರಟರೆ, ಯಾವುದೇ ಮಾರ್ಗ ಪರೀಕ್ಷಿಸುವ ಮೊದಲೇ ಹೆಸರು ಪರಿಹರಿಸಲಾಗದು.
ರುಜುವಾತುಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಪರಿಶೀಲನಾ ಪಟ್ಟಿ
ಪಟ್ಟಿಯನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಮೊದಲ ವಿಫಲ ಅಂಶದಲ್ಲಿ ನಿಲ್ಲಿಸಿ. ಪ್ರತಿ ಹೆಜ್ಜೆ ಅಗ್ಗ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಸಂಪಾದನೆಗಳ ಒಂದು ಇಡೀ ವರ್ಗವನ್ನು ಹೊರಗಿಡುತ್ತದೆ.
- ಸಂಯೋಗ ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಇದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಸಂಪರ್ಕಿತ ಲೇಬಲ್ ಬದಲು ಸಹವರ್ತಿ ಗುರುತಿನಿಂದ ಹೊಂದಿಸಿ.
- UDP 1701 xl2tpd ತಲುಪುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ; ಕರೆಯಿಲ್ಲದ ಸಂಯೋಗವೇ ನಿಮ್ಮ ವೈಫಲ್ಯ.
- ಪಾಸ್‌ವರ್ಡ್ ತಪ್ಪು ಎಂದು ಭಾವಿಸುವ ಮೊದಲು PPP ತೀರ್ಪು, ಮತ್ತು ದೃಢೀಕರಿಸಿದ್ದರೆ IPCP ಫಲಿತಾಂಶ ಓದಿ.
- ಈಗಷ್ಟೇ ರುಜುವಾತುಗಳನ್ನು ಸರ್ವರ್ ನಿರೀಕ್ಷಿಸುವ ಸ್ವರೂಪದಲ್ಲಿ ಮತ್ತೆ ನಮೂದಿಸಿ, ಏಕೆಂದರೆ ಡೊಮೇನ್ ಪೂರ್ವಪ್ರತ್ಯಯ ಖಾತೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ.
- ಇನ್ನೂ ವಿಫಲವಾದರೆ ಎರಡೂ ತುದಿಗಳನ್ನು ಜೋಡಿಸಿದ ಸಮಯ ಮುದ್ರೆಗಳೊಂದಿಗೆ ಸೆರೆಹಿಡಿದು ಹಂತ ಹಂತವಾಗಿ ಹೋಲಿಸಿ.
ಎರಡನೇ ಹಂತದಲ್ಲಿ ನಿಲ್ಲುವುದು ಮಾರ್ಗ ಅಥವಾ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಸಮಸ್ಯೆ, ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್‌ನ ಯಾವ ಸಂಪಾದನೆಯೂ ಅದನ್ನು ಚಲಿಸದು. ಮೂರನೇ ಹಂತದಲ್ಲಿ ನಿಲ್ಲುವುದು ಲಾಗ್ ಈಗಾಗಲೇ ಸರಿಪಡಿಸಬೇಕಾದ ವಿಧಾನ ಅಥವಾ ವಿಳಾಸ ಪೂಲ್ ಹೆಸರಿಸಿದೆ ಎಂದರ್ಥ. ಎರಡೂ ಸಂದರ್ಭದಲ್ಲಿ ಮುಂದಿನ ಬದಲಾವಣೆ ನೀವು ಸಮರ್ಥಿಸಬಹುದಾದುದು, ಮತ್ತು ಎಂದೂ ಒಳಗೊಂಡಿರದ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಸುತ್ತ ಸುತ್ತುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೀರಿ.