L2TP NO_PROPOSAL_CHOSEN: ವಾಸ್ತವವಾಗಿ ಯಾವ ಹಂತ ವಿಫಲವಾಯಿತು?
ಸೂಚನೆಯು ಒಂದು ಪ್ರಸ್ತಾವವನ್ನು ತಿರಸ್ಕರಿಸಲಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಯಾವುದನ್ನು ಎಂದಲ್ಲ. ಹಂತಕ್ಕಾಗಿ ಬ್ಯಾಕೆಂಡ್ ಲಾಗ್ ಓದಿ, ನಂತರ ಗೇಟ್‌ವೇ ನಿರ್ವಹಿಸುವವರೊಂದಿಗೆ ಸೂಟ್‌ಗಳನ್ನು ಹೋಲಿಸಿ.
NO_PROPOSAL_CHOSEN ಯಾವುದೇ PPP ಬಳಕೆದಾರಹೆಸರನ್ನು ಪರಿಶೀಲಿಸುವ ಮೊದಲೇ ಬರುತ್ತದೆ, ಇದು ಉಪಯುಕ್ತ ಸಂಗತಿ ಮತ್ತು ಸಂದೇಶವು ದಾರಿತಪ್ಪಿಸುವ ಕಾರಣವೂ ಆಗಿದೆ. ಒಂದು ಬದಿ ಪ್ರಸ್ತಾವವನ್ನು ತಿರಸ್ಕರಿಸಿದೆ ಎಂದು ಅದು ವರದಿ ಮಾಡುತ್ತದೆ; ಯಾವ ನಿಯತಾಂಕ ಹೊಂದಿಕೆಯಾಗಲಿಲ್ಲ ಎಂದು ವರದಿ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ತಿರಸ್ಕಾರವು IKE ಸಂಬಂಧವನ್ನು ನಿರ್ಮಿಸುವಾಗ ಸಂಭವಿಸಿತೇ ಅಥವಾ ನಂತರ ಸಂಚಾರ ಸಂರಕ್ಷಣೆಯ ಮೇಲಿನ ಮಾತುಕತೆಯ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸಿತೇ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಈ ಎರಡು ಸಾಧ್ಯತೆಗಳ ಹಿಂದೆ ಎರಡು ಬೇರೆ ಬೇರೆ ಸರಿಪಡಿಸುವಿಕೆಗಳಿವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಮಾತ್ರ ಜನರು ಮೊದಲು ಕೈಹಾಕುವ PFS ಚೆಕ್‌ಬಾಕ್ಸ್‌ಗೆ ಸಂಬಂಧಿಸಿದೆ.
ಒಂದು ಸಂದೇಶ, ಎರಡು ಪ್ರಸ್ತಾವ ಸಂಗ್ರಹಗಳು
IKEv1 L2TP/IPsec ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಎರಡು ಮಾತುಕತೆಗಳು ಅನುಕ್ರಮವಾಗಿ ನಡೆಯುತ್ತವೆ. ಹಂತ 1 ಎನ್‌ಕ್ರಿಪ್ಷನ್ ಅಲ್ಗಾರಿದಮ್, ಸಮಗ್ರತೆ ಅಲ್ಗಾರಿದಮ್ ಮತ್ತು Diffie-Hellman ಗುಂಪಿನಿಂದ IKE ಭದ್ರತಾ ಸಂಬಂಧವನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ. ನಂತರ ಹಂತ 2 ಸಂಚಾರವನ್ನು ಹೇಗೆ ಸಂರಕ್ಷಿಸುವುದು ಎಂದು ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ, ಮತ್ತು PFS ಅಗತ್ಯವು ಆ ಎರಡನೇ ಸಂಭಾಷಣೆಗೆ ಸೇರಿದೆ.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
ಹಂತಗಳು ಅನುಕ್ರಮವಾಗಿರುವುದರಿಂದ, ವೈಫಲ್ಯದ ಸ್ಥಾನವು ಯಾವ ಪಟ್ಟಿಯನ್ನು ಹೋಲಿಸಬೇಕೆಂದು ಹೇಳುತ್ತದೆ. ಸಂದೇಶದ ಸಂಪೂರ್ಣ ರೋಗನಿರ್ಣಯ ಮೌಲ್ಯ ಅದರಲ್ಲಿದೆ, ಮತ್ತು ಯಾವುದೇ ಸೆಟ್ಟಿಂಗ್ ಮುಟ್ಟುವ ಮೊದಲು ಅದನ್ನು ಹೊರತೆಗೆಯುವುದು ಯೋಗ್ಯ.
PFS ಚೆಕ್‌ಬಾಕ್ಸ್ ಹಂತ 1 ಅನ್ನು ಏಕೆ ಸರಿಪಡಿಸಲಾರದು
PFS ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಹಂತ 2 ರ ಗುಣಲಕ್ಷಣವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಪಕ್ಷಗಳು ಹಂತ 1 ರಲ್ಲಿ ಎಂದೂ ಒಪ್ಪಿಕೊಳ್ಳದಿದ್ದರೆ, ESP ಸಂಭಾಷಣೆ ಎಂದೂ ನಡೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಚೆಕ್‌ಬಾಕ್ಸ್ ತಿರಸ್ಕಾರದ ಮೇಲೆ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಅದನ್ನು ಬದಲಿಸುವುದು ಅದೇ ದೋಷವನ್ನು ಬೇರೆ ಸಮಯಮುದ್ರೆಯೊಂದಿಗೆ ನೀಡುತ್ತದೆ.
ವಿರುದ್ಧ ದೋಷವೂ ಸಮಾನವಾಗಿ ಸಾಮಾನ್ಯ. ಯಶಸ್ವಿ IKE ಸಂಬಂಧವು ESP ಪ್ರಸ್ತಾವ ಸ್ವೀಕಾರಾರ್ಹ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಹಂತ 2 ರ ಗುಂಪು ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಎಂದು ಖಂಡಿತವಾಗಿಯೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಸ್ಥಾಪಿತ ನಿರ್ವಹಣಾ ಸುರಂಗವನ್ನು ಹಂತ 1 ರ ಬಗ್ಗೆ ಮಾತ್ರ ಪುರಾವೆಯಾಗಿ ಪರಿಗಣಿಸಿ. ಜನರು ಹಸಿರು ಸಾಲನ್ನು «ಸುರಂಗ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ» ಎಂದು ಓದುತ್ತಾರೆ, ನಂತರ ಎರಡನೇ ಮಾತುಕತೆ ಪ್ರಾರಂಭವಾಗಿಲ್ಲ ಎಂದು ಯಾರೂ ಹೇಳದ ಕಾರಣ ತಪ್ಪು ಹಂತದಲ್ಲಿ ಒಂದು ಗಂಟೆ ಕಳೆಯುತ್ತಾರೆ.
ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಲಾಗ್ ಓದಿ
ತಿರಸ್ಕಾರಕ್ಕೆ ತಕ್ಷಣ ಮುಂಚಿನ ಸಂದೇಶಗಳನ್ನು ಸಂಪರ್ಕವನ್ನು ನಿಜವಾಗಿ ನಿರ್ವಹಿಸುವ ಬ್ಯಾಕೆಂಡ್‌ನಿಂದ ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ಅದೇ ಪ್ರಯತ್ನಕ್ಕೆ ಸಂಬಂಧಿಸಿ. ಆ ಸಂಬಂಧವಿಲ್ಲದೆ ನೀವು ಇನ್ನೊಂದು ಸಂಪರ್ಕದ ಇತಿಹಾಸವನ್ನು ಓದುತ್ತಿದ್ದೀರಿ ಮತ್ತು ಅದರಿಂದ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆಯುತ್ತಿದ್ದೀರಿ.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanಆ ಸಾಲುಗಳಿಂದ ಎರಡು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಿ: ಹಂತ 1 ರ ಸಂಬಂಧ ಸ್ಥಾಪಿತವಾಯಿತೇ, ಮತ್ತು ಯಾವ ವಿನಿಮಯ ವಿಫಲವಾಯಿತು. ಆ ಎರಡು ಉತ್ತರಗಳು ಹುಡುಕಾಟವನ್ನು ಒಂದು ಗುಣಲಕ್ಷಣ ಪಟ್ಟಿಗೆ ಸಂಕುಚಿಸುತ್ತವೆ. ಸುತ್ತಮುತ್ತಲಿನ ಸಂದರ್ಭವಿಲ್ಲದ ಬರೀ ಸೂಚನೆ ಅದನ್ನು ಮಾಡಲಾರದು, ಫೋರಮ್ ಥ್ರೆಡ್‌ನಿಂದ ಪ್ರಸ್ತಾವವನ್ನು ಪ್ರಯತ್ನಿಸುವುದು ಎಷ್ಟೇ ಆಮಿಷವಾದರೂ. ಬೇರೆ ಬ್ಯಾಕೆಂಡ್ ಇರುವ ಯಂತ್ರದಿಂದ ಕೆಲಸ ಮಾಡುವ ಸ್ಟ್ರಿಂಗ್ ನಕಲಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ತಿರಸ್ಕಾರವನ್ನು ಇನ್ನೊಂದರಿಂದ ಬದಲಾಯಿಸುತ್ತದೆ, ಸ್ವಲ್ಪ ತಡವಾಗಿ.
ಬ್ಯಾಕೆಂಡ್‌ನ ವಾಕ್ಯರಚನೆ ಪ್ರಯಾಣಿಸುವುದಿಲ್ಲ
ಏನನ್ನೂ ಹೋಲಿಸುವ ಮೊದಲು NetworkManager-l2tp ಆವೃತ್ತಿ ಮತ್ತು IPsec ಬ್ಯಾಕೆಂಡ್ ಆವೃತ್ತಿಯನ್ನು ದಾಖಲಿಸಿ. Libreswan ಮತ್ತು strongSwan ಪ್ರಸ್ತಾವ ವಾಕ್ಯರಚನೆಯನ್ನಾಗಲೀ ಒಂದೇ ಅಲ್ಗಾರಿದಮ್ ಸಂಗ್ರಹಗಳನ್ನಾಗಲೀ ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಒಂದರಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಸ್ಟ್ರಿಂಗ್ ಇನ್ನೊಂದರಲ್ಲಿ ವಾಕ್ಯರಚನಾ ದೋಷ. ಸ್ಥಾಪಿತ ಬ್ಯಾಕೆಂಡ್ ನೀತಿಯ ಪ್ರಕಾರ IKEv1 ಅನ್ನೂ ನಿರಾಕರಿಸಬಹುದು, ಆಗ ಯಾವುದೇ ಪ್ರಸ್ತಾವ ಎಂದೂ ಸ್ವೀಕೃತವಾಗುವುದಿಲ್ಲ.
ಯೋಜನೆಯ README ಆ ಬ್ಯಾಕೆಂಡ್ ವ್ಯತ್ಯಾಸಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಮತ್ತು ಹಂತ 1 ಹಾಗೂ ಹಂತ 2 ಕ್ಷೇತ್ರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸುತ್ತದೆ. ಅದನ್ನು ರಚನೆಯ ದಾಖಲೆಯಾಗಿ ಓದಿ, ಪ್ರತಿ ಐತಿಹಾಸಿಕ ಸೈಫರ್ ಮತ್ತು ದುರ್ಬಲ ಗುಂಪನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಆಮಂತ್ರಣವಾಗಿ ಅಲ್ಲ, ಏಕೆಂದರೆ ಹಾಗೆ ಮಾಡಿಯೇ ಯಶಸ್ವಿಯಾಗುವ ಸಂಪರ್ಕವು ನಿಮ್ಮನ್ನು ನಿರ್ಮಿಸಲು ಕೇಳಿದ ಸಂಪರ್ಕವಲ್ಲ.
ಸೂಟ್‌ನಲ್ಲಿ ಒಪ್ಪಿಗೆ ತನ್ನಿ, ನಂತರ ಹಂತಗಳನ್ನು ಪರಿಶೀಲಿಸಿ
ಗೇಟ್‌ವೇ ನಿರ್ವಾಹಕರಿಗೆ ಯಾವ IKE ಮತ್ತು ESP ಸೂಟ್‌ಗಳು ಬೆಂಬಲಿತ ಮತ್ತು ಅನುಮೋದಿತ ಎಂದು ಕೇಳಿ, ನಂತರ ಆ ಉತ್ತರವನ್ನು ಕ್ಲೈಂಟ್‌ನ ಸಂರಚನಾ ಕಡತದೊಂದಿಗಲ್ಲ, ಅದರ ಪರಿಣಾಮಕಾರಿ ಪ್ರಸ್ತಾವಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. ಭಿನ್ನಾಭಿಪ್ರಾಯವು ನಿರ್ದಿಷ್ಟವಾಗಿ ಹಂತ 2 ರ PFS ಬಗ್ಗೆ ಇದ್ದರೆ, ಬೆಂಬಲಿತ ಗುಂಪು ಅಥವಾ ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮೋದಿತ PFS-ರಹಿತ ನೀತಿಯ ಮೇಲೆ ನಿರ್ಧರಿಸಿ. ದೋಷದ ಹೆಸರಿನಿಂದ ನೀತಿಯನ್ನು ಊಹಿಸಬೇಡಿ.
ಏಕೈಕ ಅತಿಕ್ರಮಣವು ಸಂಸ್ಥೆಯು ಇನ್ನು ಮುಂದೆ ಸ್ವೀಕರಿಸದ ಗೂಢಲಿಪೀಕರಣವನ್ನು ಬೇಡಿದಾಗ, ನಿರ್ಧಾರ ಗೇಟ್‌ವೇದ್ದು ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್ ಸ್ಥಳಾಂತರದ್ದು. ಏನಾದರೂ ಮಾತುಕತೆ ನಡೆಸುವವರೆಗೆ ಕ್ಲೈಂಟ್ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಅಗಲಗೊಳಿಸುವುದು ತಿಳಿದಿರುವ ದೌರ್ಬಲ್ಯವನ್ನು ಪಕ್ಕದಲ್ಲಿ ಹಸಿರು ಟಿಕ್ ಜೊತೆಗೆ ತಲುಪಿಸುವ ವಿಧಾನ.
ನಿಜವಾದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಸರಿಪಡಿಸಿದ ನಂತರ, L2TP ಮತ್ತು PPP ತನಿಖೆ ಮಾಡುವ ಮೊದಲು IPsec ಸ್ಥಾಪನೆಯನ್ನು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ನಂತರದ ಯಾವುದೇ ದೃಢೀಕರಣ ತಿರಸ್ಕಾರವನ್ನು ಮುಂದಿನ ಹಂತಕ್ಕೆ ಸೇರಿದ್ದೆಂದು ಪರಿಗಣಿಸಿ. ನಂತರ ಅನುಮೋದಿತ ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನವೀಕರಣವನ್ನು ಪ್ರಯತ್ನಿಸಿ, ಏಕೆಂದರೆ ಮೊದಲ ಸಂಬಂಧದ ಸ್ಥಾಪನೆ ಅದರ ಉಳಿದ ಜೀವಿತಾವಧಿ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.