L2TP/IPsec ವಿಫಲವಾಗಿದೆ: IPsec, ಟನೆಲ್ ದೃಢೀಕರಣ ಅಥವಾ PPP ಲಾಗಿನ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ

ಒಂದು L2TP/IPsec ಸಂಪರ್ಕದ ಒಳಗೆ ಮೂರು ವಿಷಯಗಳು ದೃಢೀಕರಣಗೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಮಾತ್ರ ಡಯಲ್ ಮಾಡುವ ವ್ಯಕ್ತಿಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. IPsec ಟನೆಲ್ನ ತುದಿಗಳನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, L2TP ನಿಯಂತ್ರಣ ಸಂಪರ್ಕವು ತನ್ನದೇ ರಹಸ್ಯದಿಂದ ಸಹವರ್ತಿಗಳನ್ನು ಮತ್ತೆ ಸಾಬೀತುಪಡಿಸಬಹುದು, ನಂತರ PPP ಸೆಷನ್ ಒಳಗಿನ ಬಳಕೆದಾರ ಖಾತೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಯಾವುದೇ ಹಂತದಲ್ಲಿ ವೈಫಲ್ಯವು ಕ್ಲೈಂಟ್ ಸಂವಾದದಲ್ಲಿ ಸಾಮಾನ್ಯ ಲಾಗಿನ್ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ ಲಾಗ್ನಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆಯಾಗಿ ಕಾಣುತ್ತದೆ. ಹಂತಗಳನ್ನು ಕ್ರಮವಾಗಿ ನಡೆಸಿ ಮತ್ತು ಮೊದಲು ವಿಫಲವಾದ ಹಂತದಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಪರೀಕ್ಷಿಸದ ಹಂತದ ಕೆಳಗಿನ ಪ್ರತಿ ಹಂತವೂ ಪರೀಕ್ಷಿಸದೆ ಇರುತ್ತದೆ.

ಮೂರು ದೃಢೀಕರಣ ಹಂತಗಳು, ಮೂರು ಬೇರೆ ಬೇರೆ ಗುರುತುಗಳು

IPsec ಮೊದಲೇ ಹಂಚಿದ ಕೀಲಿ ಅಥವಾ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬಳಸಿ ತುದಿಗಳು ಯಾರಿಗೆ ಸೇರಿವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಆ ಗುರುತು ಯಂತ್ರಗಳು ಅಥವಾ ಗೇಟ್ವೇಗಳಿಗೆ ಸೇರಿದ್ದು, ಕೀಲಿಮಣೆಯ ಮುಂದೆ ಇರುವ ವ್ಯಕ್ತಿಗೆ ಎಂದಿಗೂ ಸೇರಿದ್ದಲ್ಲ. ಈ ಹಂತದಲ್ಲಿ ಸಹವರ್ತಿಗಳು ಒಪ್ಪಿಗೆಗೆ ಬರಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಒಂದೂ L2TP ಪ್ಯಾಕೆಟ್ ವಿನಿಮಯವಾಗುವುದಿಲ್ಲ.

L2TP ನಿಯಂತ್ರಣ ಸಂಪರ್ಕವು ಎರಡೂ ತುದಿಗಳು ಹೊಂದಿರಬೇಕಾದ ಹಂಚಿದ ರಹಸ್ಯದಿಂದ ನಡೆಸಲ್ಪಡುವ ಎರಡನೇ, ಪ್ರತ್ಯೇಕ ಸವಾಲು-ಉತ್ತರ ವಿನಿಮಯವನ್ನು ಸೇರಿಸಬಹುದು.

RFC 2661 ಆ ನಿಯಂತ್ರಣ ಸಂಪರ್ಕದ ದೃಢೀಕರಣವನ್ನು ಐಚ್ಛಿಕಗೊಳಿಸುತ್ತದೆ, ಇದು ಅದೇ ತಪ್ಪು ಎರಡು ಸರ್ವರ್ಗಳಲ್ಲಿ ವಿಭಿನ್ನ ಲಕ್ಷಣಗಳನ್ನು ಏಕೆ ಉಂಟುಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಟನೆಲ್ ರಹಸ್ಯವನ್ನು ಎಂದಿಗೂ ಸಂರಚಿಸದ ನಿಯೋಜನೆ ಹಂತವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ; ಅದನ್ನು ಒಂದೇ ಬದಿಯಲ್ಲಿ ಸಂರಚಿಸಿದ ನಿಯೋಜನೆ PPP ನೀಡುವ ಮೊದಲೇ ವಿಫಲವಾಗುತ್ತದೆ. ನಂತರ PPP ಬಳಕೆದಾರರನ್ನು PAP, CHAP ಅಥವಾ MSCHAPv2 ನಿಂದ ದೃಢೀಕರಿಸಿ ಹೆಸರನ್ನು ಸ್ಥಳೀಯ, chap-secrets ಅಥವಾ RADIUS ನಲ್ಲಿರಬಹುದಾದ ಖಾತೆ ಸಂಗ್ರಹಕ್ಕೆ ನೀಡುತ್ತದೆ. ಆ ಹಂತದಲ್ಲಿ ತಪ್ಪು ಪಾಸ್ವರ್ಡ್ ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಟನೆಲ್ ಮತ್ತು ವಿಫಲವಾದ ಸೆಷನ್ ಜೊತೆ ನಿಮ್ಮನ್ನು ಬಿಡುತ್ತದೆ.

ಸಂರಚನೆಯನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ನಿಲ್ಲುವ ಸ್ಥಳವನ್ನು ಓದಿ

ಸ್ಥಿತಿ ಔಟ್ಪುಟ್ strongSwan ಗೆ ಸೇರಿದೆಯೇ ಅಥವಾ Libreswan ಗೆ ಎಂದು ತಿಳಿಯಲು ipsec --version ನಿಂದ ಪ್ರಾರಂಭಿಸಿ. ನಂತರ ಕ್ಲೈಂಟ್ ಸಂವಾದವಲ್ಲ, ಸರ್ವರ್ ಲಾಗ್ ಓದಿ, ಏಕೆಂದರೆ ಯಾವ ಹಂತ ನಿರಾಕರಿಸಿತು ಎಂದು ಸರ್ವರ್ ದಾಖಲಿಸುತ್ತದೆ.

ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಸಾಲು ಟಿಕೆಟ್ ಅನ್ನು ನಿರ್ಣಯಿಸುತ್ತದೆ: IKE ಅಥವಾ ಪ್ರಸ್ತಾವದ ದೂರು ಮೊದಲ ಹಂತ, ನಿಯಂತ್ರಣ ಸಂಪರ್ಕದ ಸಂದೇಶ ಎರಡನೇ ಹಂತ, ಮತ್ತು PPP ವಿಧಾನ ಅಥವಾ ಖಾತೆ ನಿರಾಕರಣೆ ಮೂರನೇ ಹಂತ. ಆ ಸಾಲನ್ನು ಸಮಯ ಮುದ್ರೆಯೊಂದಿಗೆ ಟಿಕೆಟ್ಗೆ ನಕಲಿಸಿ. ಕ್ಲೈಂಟ್ ಕಡೆಯಿಂದ ಊಹಿಸುವುದು ನಿಮ್ಮ ಬಳಿ ಈಗಾಗಲೇ ಇರುವ ಏಕೈಕ ಸಾಕ್ಷ್ಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.

ಕೀಲಿ ಸಾಮಗ್ರಿ ಮತ್ತು ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಆ ಅಂಟಿಸುವಿಕೆಯಿಂದ ಹೊರಗಿಡಿ; ಹಂತದ ಹೆಸರು ಕೆಲಸವನ್ನು ನಿರ್ದೇಶಿಸುತ್ತದೆ, ಮತ್ತು ಸೋರಿದ ಮೊದಲೇ ಹಂಚಿದ ಕೀಲಿ ಕೆಟ್ಟ ಪರಿಣಾಮಗಳೊಂದಿಗೆ ಟಿಕೆಟ್ ಅನ್ನು ಮತ್ತೆ ತೆರೆಯುತ್ತದೆ.

ಮೊದಲ ಹಂತ: IPsec ಗೆ ಸಂಘವಿದೆಯೇ?

strongSwan ನಲ್ಲಿ ipsec statusall ಅಥವಾ Libreswan ನಲ್ಲಿ ipsec whack --status ಚಲಾಯಿಸಿ ಮತ್ತು ಶೂನ್ಯವಲ್ಲದ ಕೌಂಟರ್ಗಳಿರುವ ಸ್ಥಾಪಿತ ಶಿಶು ಸಂಘವನ್ನು ಹುಡುಕಿ. ip xfrm state ಎರಡರಲ್ಲೂ ಕರ್ನಲ್ ದೃಶ್ಯವನ್ನು ತೋರಿಸುತ್ತದೆ. ಕೌಂಟರ್ ಏರುತ್ತಿರುವ ಸ್ಥಾಪಿತ SA ಜೋಡಿ ಎಂದರೆ ಮೊದಲ ಹಂತ ಮುಗಿದಿದೆ ಮತ್ತು ನೀವು ಮುಂದುವರಿಯಬಹುದು.

ಸಂಘವೇ ಇಲ್ಲದಿರುವುದು ಪೀರ್ ವಿಳಾಸ, ಪ್ರಸ್ತಾವ ಸಮೂಹ ಅಥವಾ ಮೊದಲೇ ಹಂಚಿದ ಕೀಲಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ UDP 500 ಅನ್ನು ಮತ್ತೆ ಬರೆದು UDP 4500 ಅನ್ನು ಬಿಡುವ ಸಾಧನವನ್ನೂ ಸೂಚಿಸುತ್ತದೆ. ಸ್ಥಾಪಿತವಾಗಿ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ ಮಾಯವಾಗುವ ಸಂಘ ಸಾಮಾನ್ಯವಾಗಿ ರುಜುವಾತುಗಳ ಸಮಸ್ಯೆಯಲ್ಲ, ಎರಡೂ ತುದಿಗಳ ಜೀವಿತಾವಧಿಯ ಹೊಂದಾಣಿಕೆಯಲ್ಲ. ಏನನ್ನಾದರೂ ಮತ್ತೆ ಟೈಪ್ ಮಾಡುವ ಮೊದಲು ಎರಡೂ ಬದಿಗಳು ಒಂದೇ ಎನ್ಕ್ರಿಪ್ಷನ್ ಮತ್ತು ಹ್ಯಾಶ್ ಪ್ರಸ್ತಾವಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ, ಯಾವುದೇ ಕೀಲಿ ಎಂದಿಗೂ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.

ಸಂಘ ಕಾಣೆಯಾಗಿರುವಾಗ ನಿಲ್ಲಿಸಿ. ಆ ಹಂತದಲ್ಲಿ PPP ಆಯ್ಕೆಗಳನ್ನು ಸಂಪಾದಿಸುವುದು ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ನಿಜವಾದ ದೋಷವನ್ನು ಮುಂದಿನ ವ್ಯಕ್ತಿಯಿಂದ ಮರೆಮಾಡುತ್ತದೆ.

ಎರಡನೇ ಹಂತ: L2TP ನಿಯಂತ್ರಣ ಸಂಪರ್ಕವು ದೃಢೀಕರಣಗೊಂಡಿತೇ?

IPsec ಎದ್ದ ನಂತರ, ಸ್ಥಾಪಿತ ಸ್ಥಿತಿ ತಲುಪುವ ನಿಯಂತ್ರಣ ಸಂಪರ್ಕಕ್ಕಾಗಿ L2TP ಡೀಮನ್ ಅನ್ನು ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಅದಕ್ಕೆ ಮೊದಲು PPP ಪ್ರಾರಂಭವಾಗಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಿಯಂತ್ರಣ ಸಂಪರ್ಕದಲ್ಲಿ ನಿರಾಕರಣೆ ಎಂದರೆ ತುದಿಗಳ ನಡುವೆ ಟನೆಲ್ ರಹಸ್ಯ ಭಿನ್ನವಾಗಿದೆ, ಅಥವಾ ಒಂದು ತುದಿ ಇನ್ನೊಂದು ಎಂದಿಗೂ ಕಳುಹಿಸದ ರಹಸ್ಯವನ್ನು ಕೇಳುತ್ತದೆ. ಕ್ಲೈಂಟ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ shared secret ಎಂಬ ಲೇಬಲ್ ಇರುವ ಒಂದೇ ಕ್ಷೇತ್ರವನ್ನು ತೋರಿಸುತ್ತವೆ, ಮತ್ತು ಅದು ಸಾಮಾನ್ಯವಾಗಿ L2TP ಗೆ ಅಲ್ಲ, IPsec ಗೆ ಸೇರಿದ್ದು. ಅದನ್ನು ತುಂಬುವುದು ಟನೆಲ್ ರಹಸ್ಯವನ್ನು ಸಂರಚಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಖಾಲಿ ಮಾಡುವುದು ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ.

ಎರಡೂ ಬದಿಗಳು ಟನೆಲ್ ರಹಸ್ಯವನ್ನು ಸಂರಚಿಸದಿದ್ದರೆ, ಈ ಹಂತವನ್ನು ಬಿಟ್ಟುಬಿಡಿ ಮತ್ತು ನಿಯಂತ್ರಣ ಸಂಪರ್ಕದ ವೈಫಲ್ಯವನ್ನು ಬದಲಿಗೆ ತಲುಪುವಿಕೆಯ ಸಮಸ್ಯೆ ಎಂದು ಪರಿಗಣಿಸಿ. UDP 1701 ಡೀಮನ್ ತಲುಪುತ್ತದೆ ಮತ್ತು ಎರಡೂ ತುದಿಗಳು ಒಂದೇ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ನಲ್ಲಿ ಒಪ್ಪುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಆ ಎರಡು ಷರತ್ತುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಬರೆದ ಫೈರ್ವಾಲ್ ನಿಯಮ ಅರ್ಧ ತೆರೆಯುವ ಸಂಪರ್ಕದ ಸಾಮಾನ್ಯ ಕಾರಣ.

PPP ಮಾತುಕತೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ಸೆಷನ್ ಮಾತ್ರ ಟನೆಲ್ ಹಂತವನ್ನು ನಿಜವಾಗಿ ದಾಟಿದೆ.

ಮೂರನೇ ಹಂತ: PPP ಖಾತೆಯನ್ನು ನಿರಾಕರಿಸುತ್ತಿದೆಯೇ?

PPP ವೈಫಲ್ಯ ಹೊರಗಿನಿಂದ ಬೇರೆಯಾಗಿ ಕಾಣುತ್ತದೆ: ಟನೆಲ್ ಸ್ಥಾಪಿತವಾಗಿದೆ, ಸೆಷನ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಮತ್ತು ಡೀಮನ್ ದೃಢೀಕರಣ ವಿಧಾನದ ವೈಫಲ್ಯ ಅಥವಾ ಖಾತೆ ನಿರಾಕರಣೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಆ ಸಂದೇಶದಲ್ಲಿ ಹೆಸರಿಸಿದ ವಿಧಾನವನ್ನು ಓದಿ. PAP ಮತ್ತು CHAP ಬೇರೆ ಬೇರೆ ಕಾರಣಗಳಿಂದ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಒಂದನ್ನು ನಿರಾಕರಿಸುವ ಸರ್ವರ್ ಅದನ್ನೇ ನೀಡುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ.

Linux ಸರ್ವರ್ನಲ್ಲಿ, ಡೀಮನ್ PPP ಗೆ ನೀಡುವ ಆಯ್ಕೆ ಕಡತವನ್ನು, ಸಾಮಾನ್ಯವಾಗಿ /etc/ppp/options.xl2tpd, ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಯಾವ ವಿಧಾನಗಳು ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತವೆ ಮತ್ತು ಖಾತೆಗಳು ಎಲ್ಲಿ ಬಗೆಹರಿಯುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. RADIUS ನಲ್ಲಿದ್ದು ಸ್ಥಳೀಯ ರಹಸ್ಯ ಕಡತದಲ್ಲಿಲ್ಲದ ಹೆಸರು ಸ್ವಚ್ಛವಾಗಿ ವಿಫಲವಾಗಿ ತಪ್ಪು ಪಾಸ್ವರ್ಡ್ನಂತೆ ಕಾಣುತ್ತದೆ. ನಂತರ ಕ್ಲೈಂಟ್ ಸರ್ವರ್ ಸ್ವೀಕರಿಸುವ ವಿಧಾನವನ್ನು ನೀಡುತ್ತಿದೆಯೇ, ಸರ್ವರ್ ಮಾತುಕತೆ ನಿರಾಕರಿಸುವ ಬಲವಾದ ವಿಧಾನವನ್ನಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಈ ಹಂತವನ್ನು ಸರಿಪಡಿಸಲು ಮೊದಲೇ ಹಂಚಿದ ಕೀಲಿಯನ್ನು ಬದಲಿಸುವುದು ಒಂದು ಮಧ್ಯಾಹ್ನವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ ಮತ್ತು ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.

ಸೆಷನ್ ಕೊನೆಗೂ ಏರಿದಾಗ, ವಿಳಾಸ ಹಂಚಿಕೆ, DNS ಮತ್ತು ಮಾರ್ಗಗಳು ಇನ್ನೂ ಪರಿಶೀಲಿಸಲ್ಪಟ್ಟಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ರೀತಿಯಲ್ಲಿ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ. ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಮೂರು ಪದರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ: ಸರಿಯಾದ ಕೀಲಿ ಮತ್ತು ತಪ್ಪು ಖಾತೆ ಯಾವಾಗಲೂ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಒಂದು ಪದರವನ್ನು ಸರಿಪಡಿಸುವುದು ಇನ್ನೊಂದನ್ನು ಎಂದಿಗೂ ಸರಿಪಡಿಸುವುದಿಲ್ಲ.