PPTP ಮತ್ತು L2TP/IPsec ಬಳಕೆದಾರ ಹೆಸರಿನ ಪ್ರಾಂಪ್ಟ್ ಮೊದಲೇ ಏಕೆ ನಿಲ್ಲುತ್ತವೆ?
ಬಳಕೆದಾರ ಹೆಸರಿನ ಪ್ರಾಂಪ್ಟ್ ಬಾರದಿರುವುದು PPP ಎಂದೂ ಪ್ರಾರಂಭವಾಗಲಿಲ್ಲ ಎಂದರ್ಥ, ಆದ್ದರಿಂದ ದೋಷ ಸಾಗಣೆ, ಕೀ ವಿನಿಮಯ ಅಥವಾ ಸುರಂಗ ಸ್ಥಾಪನೆಯಲ್ಲಿದೆ. ಮರುಸ್ಥಾಪನೆ ಮಾಡುವ ಮೊದಲು ಹಂತಗಳ ಕ್ರಮವನ್ನು ಪರಿಶೀಲಿಸಿ.
ಬಳಕೆದಾರ ಹೆಸರಿನ ಪ್ರಾಂಪ್ಟ್ ಬಾರದಿರುವುದು ಒಂದು ರೋಗನಿರ್ಣಯದ ಉಡುಗೊರೆ: PPP ಇನ್ನೂ ಪ್ರಾರಂಭವಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ಖಾತೆ, ಗುಪ್ತಪದ ಮತ್ತು ಡೊಮೇನ್ ನೀತಿಯನ್ನು ಇನ್ನೂ ಕೇಳಲಾಗಿಲ್ಲ. PPTP ಅಥವಾ L2TP/IPsec ಸಂಪರ್ಕದಲ್ಲಿ ಕ್ಲೈಂಟ್ ರುಜುವಾತುಗಳನ್ನು ಕೇಳುವುದು ಸುರಂಗ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದು ಸರ್ವರ್ PPP ಸೆಷನ್ ಆರಂಭಿಸಿದ ನಂತರವೇ. ಆ ಕ್ಷಣಕ್ಕಿಂತ ಮೊದಲು ವಿಫಲವಾಗಬಹುದಾದ ಎಲ್ಲವೂ ಸಾಗಣೆ, ಕೀ ವಿನಿಮಯ ಅಥವಾ ಸುರಂಗ ಸ್ಥಾಪನೆ, ಇದು «VPN ಕೆಟ್ಟುಹೋಗಿದೆ» ಎಂಬುದಕ್ಕಿಂತ ಬಹಳ ಚಿಕ್ಕ ಕ್ಷೇತ್ರ.
ಕಾಣದ ಪ್ರಾಂಪ್ಟ್ ದೋಷವನ್ನು ಮೂರು ಹಂತಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ
ಕಣ್ಣಿಗೆ ಕಾಣುವಂತೆ ಯಶಸ್ವಿಯಾದ ಕೊನೆಯ ಹಂತವನ್ನು ಬರೆದಿಡಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಮಾಲೀಕ ಮತ್ತು ಬೇರೆ ಪರಿಹಾರ ಇದೆ. ಎರಡು ಹಂತ ಹಿಂದೆ ಸಿಕ್ಕಿಹಾಕಿಕೊಂಡಿರುವಾಗ ಖಾತೆ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಊಹಿಸುವುದು ಒಂದು ಮಧ್ಯಾಹ್ನ ಕಳೆದುಹೋಗುವ ದಾರಿ.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
ಪ್ರಾಂಪ್ಟ್ ಇಲ್ಲದೆ ಸಮಯ ಮೀರಿದ ಕ್ಲೈಂಟ್ ಎಂದೂ IPsec ಸಂಯೋಜನೆ ಪಡೆಯಲಿಲ್ಲ, ಆದ್ದರಿಂದ ದೋಷ IKE ನಲ್ಲಿದೆ ಅಥವಾ ನಿಮ್ಮ ಪ್ಯಾಕೆಟ್ಗಳು ಗೇಟ್ವೇಯನ್ನು ತಲುಪುತ್ತವೆಯೇ ಎಂಬುದರಲ್ಲಿದೆ. ರುಜುವಾತುಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿದ್ದೇನೆ ಎಂದು ತಿಳಿಸಿ ನಂತರ ಬೀಳುವ ಕ್ಲೈಂಟ್ ಸಂದೇಶ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಮುಂದೆ ಹೋಗಿತ್ತು. ಪ್ರಾಂಪ್ಟ್ ನಂತರ ನಿರಾಕರಣೆ ಬಂದರೆ ಅದು PPP ದೃಢೀಕರಣ, ಮತ್ತು ಅದರ ಸ್ಥಾನ ಖಾತೆ ಲೇಖನದಲ್ಲಿ, ಈ ಲೇಖನದಲ್ಲಿ ಅಲ್ಲ.
ಮೊದಲ ಹಂತ: ಫೈರ್ವಾಲ್ ಸದ್ದಿಲ್ಲದೆ ಬಿಟ್ಟುಬಿಡುವ ಪ್ರೋಟೋಕಾಲ್
PPTP ಗೆ ಅದರ ನಿಯಂತ್ರಣ ಚಾನಲ್ಗೆ TCP 1723 ಮತ್ತು ಡೇಟಾ ಮಾರ್ಗಕ್ಕೆ IP ಪ್ರೋಟೋಕಾಲ್ 47 ಬೇಕು, ಮತ್ತು ಎರಡೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಚರಿಸುತ್ತವೆ. ಅನೇಕ ನೆಟ್ವರ್ಕ್ಗಳು 1723 ಅನ್ನು ಮುಂದೆ ಕಳುಹಿಸಿ ಪ್ರೋಟೋಕಾಲ್ 47 ಅನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತವೆ, ಇದರಿಂದ ಮಾತುಕತೆ ನಡೆಸಿ ನಂತರ ಏನನ್ನೂ ಸಾಗಿಸದ ಸುರಂಗ ಉಂಟಾಗುತ್ತದೆ. NAT ಮಾಡುವ ರೌಟರ್ಗೆ GRE ಬೆಂಬಲದ ಅಂಗೀಕಾರವೂ ಬೇಕು, ಮತ್ತು ಕೇವಲ IPv6 ಆಧಾರಿತ ಪ್ರವೇಶ ಮಾರ್ಗ ಯಾವ ಸಂರಚನೆಯಲ್ಲೂ PPTP ಸಾಗಿಸಲಾರದು.
IPsec ಮೇಲಿನ L2TP IKE ಗೆ ಪೋರ್ಟ್ 500 ಮತ್ತು NAT ದಾಟಲು ಪೋರ್ಟ್ 4500 ಖರ್ಚು ಮಾಡುತ್ತದೆ, ನಂತರ L2TP ಸಂಚಾರವನ್ನೇ 1701 ನಲ್ಲಿ ಸುತ್ತುತ್ತದೆ, ಮತ್ತು ಸಂಯೋಜನೆ ಉಂಟಾದ ನಂತರ ESP ರಕ್ಷಿತ ಪೇಲೋಡ್ ಸಾಗಿಸುತ್ತದೆ. ಎರಡು ನಿಯಂತ್ರಣ ಪೋರ್ಟ್ಗಳಿಗೆ ಅನುಮತಿ ನೀಡಿ ESP ಗೆ ನೀಡದಿದ್ದರೆ, ನಿಖರವಾಗಿ ಶೀರ್ಷಿಕೆಯ ಲಕ್ಷಣ ಸಿಗುತ್ತದೆ: ಕಾಣುವ ಪ್ರಗತಿ, ನಂತರ ಯಾವುದೇ ರುಜುವಾತು ಸಂವಾದಕ್ಕಿಂತ ಮೊದಲೇ ಸತ್ತ ಕ್ಲೈಂಟ್. ಫೋನ್ ಹಾಟ್ಸ್ಪಾಟ್ನಿಂದ ಪರೀಕ್ಷಿಸುವುದು ಕ್ಲೈಂಟ್ ಸಮಸ್ಯೆಯನ್ನು ಮಾರ್ಗದ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸುವ ಅಗ್ಗದ ದಾರಿ.
ಎರಡನೇ ಹಂತ: ಕೀ ಅಲ್ಲದ ಕೀ, ನೀಡದ ಪ್ರಸ್ತಾಪ
ಹೊಂದಿಕೆಯಾಗದ ಪೂರ್ವ-ಹಂಚಿಕೆ ಕೀ ಬೇಗ ಮತ್ತು ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯ ರೂಪ ಪರದೆಯಲ್ಲಿ ಸರಿ ಕಾಣುವ ಆದರೆ ಅಂಟಿಸಿದ ಸಾಲು ಒಡಿತ ಅಥವಾ ಕೊನೆಯಲ್ಲಿ ಜಾಗ ಹೊತ್ತಿರುವ ಕೀ. Linux ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಸಂವಾದವೇ ಸತ್ಯದ ಮೂಲ ಎಂದಲ್ಲ: NetworkManager ನ L2TP ಪ್ಲಗಿನ್ ರಹಸ್ಯಗಳನ್ನು /etc/ipsec.d/ ಅಡಿಯಲ್ಲಿನ ಫೈಲ್ಗಳಲ್ಲಿ ಇಡುತ್ತದೆ, ಮತ್ತು /etc/ipsec.secrets ಇನ್ನೂ ಸೇರಿಸುವ ಹಳೆಯ ಪ್ರತಿ-ಸಂಪರ್ಕ ಫೈಲ್ ನೀವು ಈಗ ಟೈಪ್ ಮಾಡಿದ ಫೈಲಿನ ಬದಲು ಬಳಕೆಯಾಗುತ್ತದೆ. ಆ ಫೈಲನ್ನು ಸುರಕ್ಷಿತ ಸ್ಥಳಕ್ಕೆ ನಕಲಿಸಿ, ಸೇರಿಸುವ ಮಾರ್ಗದಿಂದ ಹೊರತೆಗೆದು, ನಂತರ ಕೀಯನ್ನು ಕೈಯಿಂದ ಮತ್ತೆ ಟೈಪ್ ಮಾಡಿ.
ಈ ಹಂತದ ಇನ್ನೊಂದು ಅರ್ಧ ಪ್ರಸ್ತಾಪ. ಎರಡೂ ತುದಿಗಳು ಒಂದೇ 1ನೇ ಹಂತದ ಅಲ್ಗಾರಿದಮ್ ಗುಂಪಿನಲ್ಲಿ — ಗೂಢಲಿಪೀಕರಣ, ಸಮಗ್ರತೆ ಮತ್ತು Diffie-Hellman ಗುಂಪು — ಮತ್ತು 2ನೇ ಹಂತಕ್ಕೆ ಹೊಂದುವ ESP ರೂಪಾಂತರಗಳಲ್ಲಿ ಒಪ್ಪಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಸಂಯೋಜನೆ ಉಂಟೇ ಆಗುವುದಿಲ್ಲ. ಕೇವಲ 3DES, SHA1 ಮತ್ತು MODP1024 ನೀಡುವ ಗೇಟ್ವೇ ಬಲವಾದ ಅಲ್ಗಾರಿದಮ್ಗಳಿಗೆ ಸಿದ್ಧಪಡಿಸಿದ ಕ್ಲೈಂಟನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಲಾಗ್ ನಿರಾಕರಿಸಿದ ರೂಪಾಂತರವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಸೇವೆಯನ್ನು ಮತ್ತೆ ಮರುಪ್ರಾರಂಭಿಸುವ ಬದಲು ಲಾಗ್ ಓದಿದರೆ ಲಾಗ್ ವ್ಯತ್ಯಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಫೋರಂ ಥ್ರೆಡ್ನಿಂದ ಅಲ್ಗಾರಿದಮ್ ಸರಣಿಯನ್ನು ನಕಲಿಸುವ ಬದಲು ಗೇಟ್ವೇಯನ್ನು ಅದು ನಿಜವಾಗಿ ಯಾವ ರೂಪಾಂತರಗಳ ಬಗ್ಗೆ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ ಎಂದು ಕೇಳಿ: ಅದರ ವಿಳಾಸಕ್ಕೆ ಗುರಿಪಡಿಸಿದ ike-scan ಅದು ಮಾತುಕತೆ ನಡೆಸುವ ರೂಪಾಂತರಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಒಂದೇ ಕೊಡುಗೆ ನಿಮ್ಮ ನೀತಿ ಇನ್ನು ಅನುಮತಿಸದ ಗೂಢಲಿಪೀಕರಣವಾದರೆ, ಸರಿಪಡಿಸುವುದು ಕ್ಲೈಂಟನ್ನು ಕೆಳಕ್ಕಿಳಿಸುವುದಲ್ಲ, ಗೇಟ್ವೇಯಲ್ಲ.
Windows ನಲ್ಲಿ ಕೀ ಮತ್ತು ದೃಢೀಕರಣ ವಿಧಾನ VPN ಪ್ರೊಫೈಲ್ನಲ್ಲಿರುತ್ತವೆ, ಮತ್ತು ವ್ಯತ್ಯಾಸ ರುಜುವಾತು ಪ್ರಾಂಪ್ಟ್ನ ಮೊದಲೇ ಕಾಣಿಸುತ್ತದೆ, ನಂತರವಲ್ಲ. ಸ್ವೀಕರಿಸುವವರು Windows Server ಆಗಿದ್ದರೆ, ದೂರಸ್ಥ ಪ್ರವೇಶ ಪಾತ್ರ ಸ್ಥಾಪಿತವಾಗಿದೆ ಎಂದೂ, ಪ್ರಮಾಣಪತ್ರವು ಕ್ಲೈಂಟ್ಗಳು ಸಂಪರ್ಕಿಸುವ ಹೆಸರಿಗೆ ಹೊಂದುತ್ತದೆ ಎಂದೂ, ಯಾವುದೇ ಪೋರ್ಟ್ ಫಿಲ್ಟರ್ ಮೇಲಿನ ಪ್ರೋಟೋಕಾಲ್ಗಳಿಗಿಂತ ಕಿರಿದಲ್ಲ ಎಂದೂ ಖಚಿತಪಡಿಸಿ.
ಮೂರನೇ ಹಂತ: ಸುರಂಗ ಇದೆ ಮತ್ತು PPP ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ
IKE ಮುಗಿದರೂ ಪ್ರಾಂಪ್ಟ್ ಬಾರದಿದ್ದರೆ ಫೈರ್ವಾಲ್ ಅಲ್ಲ, ಸುರಂಗ ಡೀಮನ್ ನೋಡಿ. L2TP ಗೆ UDP 1701 ನಲ್ಲಿ ಆಲಿಸುವ ಯಾವುದೋ ಬೇಕು — Linux ನಲ್ಲಿ xl2tpd ಅಥವಾ kl2tpd, Windows ನಲ್ಲಿ ದೂರಸ್ಥ ಪ್ರವೇಶ ಸೇವೆ — ಮತ್ತು ಸ್ಥಾಪಿತ ಆದರೆ ನಿಲ್ಲಿಸಿದ ಸೇವೆ ಕ್ಲೈಂಟ್ನ ಕಡೆಯಿಂದ ಬಿಟ್ಟ ಪ್ಯಾಕೆಟ್ನಂತೆಯೇ ಕಾಣುತ್ತದೆ. ನೀವು ಈಗಾಗಲೇ ಪರಿಶೀಲಿಸಿದ ನಿಯಮಗಳನ್ನು ಮತ್ತೆ ತೆರೆಯುವ ಮೊದಲು ಆಲಿಸುವವನ್ನು ಪರೀಕ್ಷಿಸಿ. ನಂತರ PPP ಮಾತುಕತೆ ನಡೆಸಬೇಕು, ಮತ್ತು ಮೊದಲ LCP ವಿನಿಮಯವೇ ಸದ್ದಿಲ್ಲದ ವೈಫಲ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಇಳಿಯುವ ಸ್ಥಳ.
ಈ ಹಂತದ ಒಂದು ಬಲೆ ನೆಟ್ವರ್ಕ್ ದೋಷವೇ ಅಲ್ಲ: Windows ಒಂದು ನಿರ್ದಿಷ್ಟ VPN ಪ್ರಕಾರದ ಒಂದೇ ಸಂಪರ್ಕವನ್ನು ಒಮ್ಮೆಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡನೇ ಪ್ರಯತ್ನ ದೋಷ 937 ಹಿಂತಿರುಗಿಸುತ್ತದೆ, «ಈ ಪ್ರಕಾರದ ಇನ್ನೊಂದು ಸಂಪರ್ಕ ಬಳಕೆಯಲ್ಲಿದೆ». ಇದು ಸ್ಥಳೀಯ ನಿಯಮ, ಮತ್ತು ಇದನ್ನು ಬಳಸಿಕೊಳ್ಳದಿರುವ ದಾರಿ ಬೇರೆ ಸಾಧನ, ಬೇರೆ ಸುರಂಗ ಪ್ರಕಾರ, ಅಥವಾ ಈಗಾಗಲೇ ಇರುವ ಒಂದೇ ಸಂಪರ್ಕವನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದು.
ಊಹಿಸುವ ಬದಲು ಹಂತಗಳ ಕ್ರಮದಲ್ಲಿ ಲಾಗ್ ಓದಿ
ಕ್ಲೈಂಟ್ ನಿಲ್ಲಿಸಿ, ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಿ, ಮತ್ತು ಘಟಕಗಳನ್ನು ಅವು ಲಾಗ್ ಬರೆಯುವ ಕ್ರಮದಲ್ಲಿ ಓದಿ. ಅಂದರೆ ಮೊದಲು IPsec ಡೀಮನ್ — strongSwan ಅಥವಾ Libreswan, ಮತ್ತು ipsec --version ಯಾವುದೆಂದು ಹೇಳುತ್ತದೆ — ನಂತರ L2TP ಡೀಮನ್, ನಂತರ pppd. ವೈಫಲ್ಯದ ಮೊದಲು ಕೊನೆಯದಾಗಿ ಬರೆದ ಘಟಕವೇ ಪರಿಶೀಲಿಸಬೇಕಾದ ಹಂತವನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಕ್ರಮದಲ್ಲಿ ಅದರ ನಂತರ ಬರುವ ಯಾವುದೂ ಓಡಲಿಲ್ಲ.
ಉಳಿಸಿದ ಸೆಷನ್ ಬದಲು ಹೊಸ ಸಂಪರ್ಕದಿಂದ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಕ್ಯಾಶ್ನಿಂದ ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವ ಕ್ಲೈಂಟ್ ವಿನಿಮಯದ ಭಾಗಗಳನ್ನು ಬಿಟ್ಟು ಹಳೆಯ ಫಲಿತಾಂಶವನ್ನು ಮರುಸೃಷ್ಟಿಸಬಹುದು. ತಲುಪುವಿಕೆ, ಕೀ ವಿನಿಮಯ, ಸುರಂಗ ಮತ್ತು PPP ಅನ್ನು ಒಂದೊಂದಾಗಿ, ಅದೇ ಕ್ರಮದಲ್ಲಿ ದೃಢೀಕರಿಸಿ. ಆಗ ಕಾಣದ ಪ್ರಾಂಪ್ಟ್ ಒಗಟಾಗಿರುವುದನ್ನು ನಿಲ್ಲಿಸಿ ನಿಜವಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದಾದ ಪಟ್ಟಿಯ ಎರಡನೇ ಸಾಲಾಗುತ್ತದೆ. ಆ ಪಟ್ಟಿಯೇ ನೀವು ನೆಟ್ವರ್ಕ್ ತಂಡಕ್ಕೆ ಕೊಡುವುದು, ಇಲ್ಲದಿದ್ದರೆ ಪ್ರಾರಂಭವಾಗದ ಡೀಮನ್ನಲ್ಲಿ ವಾಸಿಸುವ ದೋಷಕ್ಕಾಗಿ ಫೈರ್ವಾಲ್ ಪರಿಶೀಲಿಸಲು ಹೇಳಲಾಗುತ್ತಿತ್ತು.