Linux ನಲ್ಲಿ IPsec ಇಲ್ಲದೆ L2TP: xl2tpd, pppd ಮತ್ತು NAT

ಸಾಮಾನ್ಯ L2TP ಎಂಬುದು ಲಕೋಟೆಯೊಳಗಿನ PPP, ಬೇರೇನೂ ಅಲ್ಲ. ಅದು ನಿಮ್ಮ ಫ್ರೇಮ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ; ಅವನ್ನು ಗುಪ್ತಲೇಖನ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿ ಯಾರು ಕುಳಿತಿದ್ದಾರೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಬಹುತೇಕ ಪ್ರತಿಯೊಂದು ನಿಯೋಜನೆ ಅದರ ಕೆಳಗೆ IPsec ಹಾಕುತ್ತದೆ. ಬರಿಯ ಆವೃತ್ತಿಯನ್ನು ನಡೆಸಲು ಪ್ರಾಮಾಣಿಕ ಕಾರಣಗಳು ಇನ್ನೂ ಇವೆ: ಪ್ರಯೋಗಾಲಯದ ಬೆಂಚ್, ವಲಸೆಯ ಹಂತ, ಅಥವಾ ಈಗಾಗಲೇ ಇನ್ನೊಂದು ಸಂರಕ್ಷಿತ ಮಾರ್ಗದ ಒಳಗಿರುವ ಸಂಪರ್ಕ.

ನೀವು ಮುಂದುವರಿದರೆ, ಆ ಎಚ್ಚರಿಕೆಯನ್ನು ವಿನ್ಯಾಸ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಬರೆದು ಅಲ್ಲಿಯೇ ಇಡಿ. ಮುಂದಿರುವುದು Debian ಮತ್ತು RHEL ಕುಟುಂಬದ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ನಾನು ಬಳಸುವ ಕಾರ್ಯಾಚರಣಾ ಮಾರ್ಗ: ಯಾವ ಫೈಲ್ ಯಾವುದಕ್ಕೆ ಹೊಣೆ, ಸಾಂಪ್ರದಾಯಿಕ ನಿಲುಗಡೆಯನ್ನು ತಡೆಯುವ MTU, ಮತ್ತು ಸುರಂಗವನ್ನು ಉಪಯುಕ್ತವಾಗಿಸುವ ಮುಂದೂಡಿಕೆ ನಿಯಮಗಳು.

ಮೂರು ಫೈಲ್‌ಗಳು ಕೆಲಸ ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ

xl2tpd ನಿಯಂತ್ರಣ ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸಿ ಪ್ರತಿ ಸೆಷನ್ ಅನ್ನು PPP ಡೀಮನ್‌ಗೆ ಒಪ್ಪಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂರಚನೆ ಒಂದರ ಇನ್ನೊಂದರ ಫೈಲ್‌ಗಳನ್ನು ಎಂದೂ ಓದದ ಎರಡು ಪ್ರೋಗ್ರಾಮ್‌ಗಳ ನಡುವೆ ಹಂಚಿಹೋಗಿದೆ. ಕೇಳುಗ /etc/xl2tpd/xl2tpd.conf ನಲ್ಲಿ, [lns default] ವಿಭಾಗದ ಒಳಗೆ ಇರುತ್ತದೆ, ಅದು ವಿಳಾಸ ಕೊಳವನ್ನು ip range ಯಿಂದ, ಸರ್ವರ್ ತುದಿಯನ್ನು local ip ಯಿಂದ ಮತ್ತು PPP ಗೆ ಒಪ್ಪಿಸುವುದನ್ನು pppoptfile ಯಿಂದ ಹೆಸರಿಸುತ್ತದೆ. require authentication = yes ಆನ್ ಮಾಡಿ, length bit ಮತ್ತು flow bit ಸಕ್ರಿಯವಾಗಿರಲಿ, ಮತ್ತು ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಬೇರೇನೂ ಬಳಸದ ಕೊಳವನ್ನು ಆರಿಸಿ.

PPP ನೀತಿ ಆ ಆಯ್ಕೆ ಹೆಸರಿಸುವ ಫೈಲ್‌ನದು, ಸಾಮಾನ್ಯವಾಗಿ /etc/ppp/options.xl2tpd: auth, pap, chap ಮತ್ತು mschap ಗಾಗಿ ನಿರಾಕರಣೆಗಳು, require-mschap-v2, 1460 ರ MTU ಮತ್ತು MRU, ಮತ್ತು ಸಂಪರ್ಕ ಏರಿದ ನಂತರ ಕ್ಲೈಂಟ್ ತಲುಪಬಹುದಾದ DNS ವಿಳಾಸ. ರುಜುವಾತುಗಳು ಮತ್ತೆ ಮೂರನೇ ಫೈಲ್, /etc/ppp/chap-secrets, ಅಲ್ಲಿ ಎರಡನೇ ಕ್ಷೇತ್ರ LNS ವಿಭಾಗದ ಹೆಸರಿಗೆ ಹೊಂದಬೇಕು ಮತ್ತು ನಾಲ್ಕನೇ ಕ್ಷೇತ್ರ ಕೊಳದಿಂದ ನಿರ್ದಿಷ್ಟ ವಿಳಾಸವನ್ನು ಪಿನ್ ಮಾಡಬಹುದು.

ಸುರಂಗ ಸಂಪರ್ಕಗೊಂಡು ಏಕೆ ನಿಲ್ಲುತ್ತದೆ

1500 ಬೈಟ್‌ನ Ethernet ಫ್ರೇಮ್ ತನ್ನದೇ ಹೆಡರ್‌ಗಳಿಗೆ ಬೈಟ್‌ಗಳನ್ನು ವ್ಯಯಿಸುವ ಮಾರ್ಗದೊಳಗೆ ಸಿಗುವುದಿಲ್ಲ. ಹೊರಗಿನ IPv4 ಹೆಡರ್ 20 ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, UDP 8, ಮತ್ತು L2TP ಹೆಡರ್ ಸುಮಾರು 12, ಇದು PPP ಮತ್ತು ಅದರ ಪೇಲೋಡ್‌ಗೆ 1460 ಬಿಡುತ್ತದೆ. PPP ನಲ್ಲಿ ಆ ಚಿಕ್ಕ ಸಂಖ್ಯೆಯನ್ನು ಘೋಷಿಸುವುದೇ ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್‌ಗಳು ತುಂಡಾಗದಂತೆ ಅಥವಾ ನಡುವೆ ಎಲ್ಲೋ ಮೌನವಾಗಿ ಬೀಳದಂತೆ ತಡೆಯುತ್ತದೆ.

ಲಕ್ಷಣ ಎಂದರೆ ನಿಜವಾದ ಸಂಚಾರ ಬರುವವರೆಗೆ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುವ ಸುರಂಗ: ಪಿಂಗ್‌ಗಳು ಮತ್ತು ನಿಯಂತ್ರಣ ಸಂದೇಶಗಳು ಹಾದುಹೋಗುತ್ತವೆ, ಫೈಲ್ ನಕಲು ನಿಲ್ಲುತ್ತದೆ, ಲಾಗ್‌ನಲ್ಲಿ ಏನೂ ಅದನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ. ಎರಡೂ ತುದಿಗಳಲ್ಲಿ MTU ಮತ್ತು MRU ಒಟ್ಟಿಗೆ ಕಡಿಮೆ ಮಾಡಿ. ಕ್ಲೈಂಟ್ ಮಾತ್ರ ಸರಿಹೊಂದಿಸಿದರೆ ಗಟ್ಟಿಯಾದ ನಿಲುಗಡೆ ಮಧ್ಯಂತರ ನಿಲುಗಡೆಯಾಗಿ ಬದಲಾಗುತ್ತದೆ, ಅದನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಕೆಟ್ಟದು.

ಒಂದು ಪೋರ್ಟ್ ಎರಡು ಸಂಭಾಷಣೆ ಸಾಗಿಸುತ್ತದೆ

UDP 1701 ಪ್ರೋಟೋಕಾಲ್‌ನ ಎರಡೂ ಅರ್ಧಗಳ ಕೆಳಗೆ ಇದೆ, ಮತ್ತು ಆ ಒಂದು ಸಂಗತಿ ಸಿದ್ಧತೆಯ ಯಾವುದೇ ಬೇರೆ ಭಾಗಕ್ಕಿಂತ ಹೆಚ್ಚು ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳನ್ನು ಮುರಿಯುತ್ತದೆ. ಮೊದಲು ನಿಯಂತ್ರಣ-ಸಂಪರ್ಕದ ಪ್ರಾರಂಭದ ವಿನಂತಿ ಮತ್ತು ಅದರ ಉತ್ತರ ಬರುತ್ತವೆ; ನಂತರದ ಸೆಷನ್ ವಿನಂತಿ ಮತ್ತು ದೃಢೀಕರಣ ಗುರುತಿಸುವಿಕೆ ಜೋಡಿಗಿಂತ ಹೆಚ್ಚೇನೂ ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ. ನಂತರ PPP ವಹಿಸಿಕೊಳ್ಳುತ್ತದೆ: ಲಿಂಕ್ ನಿಯಂತ್ರಣ, ನಂತರ ದೃಢೀಕರಣ, ನಂತರ ವಿಳಾಸಗಳನ್ನು ನಿಶ್ಚಯಿಸಲು IP ನಿಯಂತ್ರಣ ಪ್ರೋಟೋಕಾಲ್. ಪ್ರತಿ ಹಂತಕ್ಕೂ ಲಾಗ್‌ನಲ್ಲಿ ತನ್ನದೇ ಪದಕೋಶವಿದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ತನ್ನನ್ನು L2TP ವೈಫಲ್ಯ ಎಂದು ಘೋಷಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ.

ನಿಖರವಾಗಿ ಆ ಕ್ರಮದಲ್ಲಿ ಕ್ಯಾಪ್ಚರ್ ಓದಿದರೆ ಯಾವ ಹಂತ ವಿಫಲವಾಯಿತು ಎಂದು ತಿಳಿಯುತ್ತದೆ, ಮತ್ತು PPP ದೃಢೀಕರಣದ ವೈಫಲ್ಯ xl2tpd ಸಂಪಾದಿಸಿ ಸರಿಪಡಿಸಲಾಗದು. ಹಂಚಿದ ಪೋರ್ಟ್ ಇನ್ನೊಂದು ಸಾಮಾನ್ಯ ವೈಫಲ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ: ಹರಿವಿನ ಮೊದಲ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡುವ ನಿಯಮ ಸೆಷನ್ ಸ್ಥಾಪಿತವಾಗಲು ಬಿಟ್ಟು ನಂತರ ವರ್ಗಾವಣೆಯನ್ನು ತಡೆಯುತ್ತದೆ. ಇಡೀ ಸಂಭಾಷಣೆಗೆ 1701, ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಅನುಮತಿಸಿ.

ಸುರಂಗವನ್ನು ಉಪಯುಕ್ತಗೊಳಿಸುವುದು: ಮುಂದೂಡಿಕೆ ಮತ್ತು NAT

ಸೆಷನ್ ತಾನಾಗಿಯೇ ಸರ್ವರ್‌ಗೆ ಮಾತ್ರ ತಲುಪುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ನ ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶಕ್ಕೆ ಮುಂದೂಡಿಕೆ, ಅಪ್‌ಲಿಂಕ್‌ನಲ್ಲಿ ಕೊಳಕ್ಕಾಗಿ NAT ನಿಯಮ, ಮತ್ತು ಸಂಪರ್ಕ ಏರಿದ ನಂತರ ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಪ್ರಶ್ನಿಸಬಹುದಾದ DNS ಬೇಕು. ಕೊಳವು LAN ಶ್ರೇಣಿಯಿಂದ ಹೊರಗಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಕಳುಹಿಸಿದ ಉತ್ತರಗಳು ಸುರಂಗಕ್ಕೆ ಹಿಂತಳ್ಳುವ ಬದಲು ಸ್ಥಳೀಯವಾಗಿ ತಲುಪಿಸಲ್ಪಡುತ್ತವೆ.

ಸರ್ವರ್‌ನಲ್ಲಿ sysctl -w net.ipv4.ip_forward=1 ನಿಂದ ಮುಂದೂಡಿಕೆ ಆನ್ ಮಾಡಿ, iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE ನಿಂದ ಕೊಳವನ್ನು ಅನುವಾದಿಸಿ, ನಂತರ -i ppp0 -o eth0 ಗಾಗಿ FORWARD ನಿಯಮದಿಂದ ಹೊರಹೋಗುವ ಸುರಂಗ ಸಂಚಾರವನ್ನು ಮತ್ತು ಕನ್ನಡಿ ನಿಯಮದೊಂದಿಗೆ -m state --state RELATED,ESTABLISHED ನಿಂದ ಹಿಂತಿರುಗುವ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸಿ. ಈ ನಿಯಮಗಳನ್ನು ಮರುಬೂಟ್‌ಗಳ ನಡುವೆ ಉಳಿಸಿ, ಏಕೆಂದರೆ ಅವುಗಳಿಲ್ಲದೆ ಹಿಂತಿರುಗುವ ಸರ್ವರ್ ಮುರಿದ L2TP ಸಂರಚನೆಯಂತೆಯೇ ಕಾಣುತ್ತದೆ.

ಸರ್ವರ್‌ನ ಸ್ವಂತ LAN ತಲುಪುವುದು ಬೇರೆ ಕೆಲಸ: LAN ರೌಟರ್‌ನಲ್ಲಿ ಕೊಳಕ್ಕಾಗಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಸೇರಿಸಿ, ಅಥವಾ ಸರ್ವರ್‌ನಲ್ಲಿ proxy ARP ಬಳಸಿ. LAN ಒಳಗಿನ ಯಾವುದೋ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಸಂಬೋಧಿಸಬೇಕಾದಾಗ ಅವರನ್ನು NAT ಹಿಂದೆ ಮರೆಮಾಡುವುದು ನಂತರಕ್ಕೆ ಎರಡನೇ ಡೀಬಗ್ ಸೆಷನ್ ಅನ್ನು ಅಂದುಕೊಳ್ಳುವಷ್ಟೇ.

ಬರಿಯ ಸ್ಟಾಕ್ ಏನು ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು

ಈ ಸ್ಟಾಕ್‌ನ ಯಾವುದೇ ಭಾಗ PPP ಫ್ರೇಮ್‌ಗಳನ್ನು ಗುಪ್ತಲೇಖನ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಅದರಲ್ಲಿ ಯಾವುದೂ ದೂರದ ತುದಿಯನ್ನು ನೀವು ನಿಜವಾಗಿ ಆರಿಸಿದ ಸರ್ವರ್ ಎಂದು ದೃಢೀಕರಿಸುವುದಿಲ್ಲ. MS-CHAPv2 ಕೇವಲ ನೋಡುವ ಕೇಳುಗರಿಂದ ರುಜುವಾತು ವಿನಿಮಯವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ, ಆದರೂ ಮಾರ್ಗದಲ್ಲಿ ಕುಳಿತ ಆಕ್ರಮಣಕಾರ ಸೆಷನ್‌ಗೆ ಇನ್ನೂ ಅಡ್ಡಿಪಡಿಸಬಹುದು. Windows ನ ಸ್ಥಳೀಯ ಕ್ಲೈಂಟ್ L2TP ಅನ್ನು IPsec ಜೊತೆಗೆ ಮಾತ್ರ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ Linux, ರೌಟರ್ ಫರ್ಮ್‌ವೇರ್ ಮತ್ತು ತೃತೀಯ ಪಕ್ಷದ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ನಿಮ್ಮ ಸಹವರ್ತಿಗಳಾಗಿ ಎಣಿಸಿ. ಬರಿಯ ಸಂರಚನೆಯನ್ನು ರೋಗನಿರ್ಣಯದ ಮೆಟ್ಟಿಲಾಗಿ ಪರಿಗಣಿಸಿ, ಎಂದೂ ನಿಲ್ಲುವ ಸ್ಥಳವಾಗಿ ಅಲ್ಲ.

ನಿಗದಿತ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ: xl2tpd -D ಅನ್ನು ಮುಂಭಾಗದಲ್ಲಿ ಚಲಾಯಿಸಿ, PPP ಹಂತಕ್ಕಾಗಿ ಜರ್ನಲ್ ವೀಕ್ಷಿಸಿ, ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ip addr ನಿಂದ ಹಂಚಿದ ವಿಳಾಸ ಓದಿ, ನಂತರ ಸೆಷನ್ ಏರಿದ ಮೇಲೆ ಡೇಟಾ ಹರಿಯುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಲು UDP 1701 ಸೆರೆಹಿಡಿಯಿರಿ. ನಾಲ್ಕೂ ಹೊಂದಿಕೆಯಾಗಿ ಸಂಚಾರ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ದೋಷ ರೌಟಿಂಗ್, NAT ಅಥವಾ MTU ನಲ್ಲಿದೆ, L2TP ನಲ್ಲಲ್ಲ.