Docker ನಲ್ಲಿ PPTP ದೃಢೀಕರಣ ಮಾಡುತ್ತದೆ ಆದರೆ ಯಾವುದೇ ಸಂಚಾರ ಸಾಗಿಸುವುದಿಲ್ಲ

ಕ್ಲೈಂಟ್ ದೃಢೀಕರಣ ಮಾಡುತ್ತದೆ, PPP ಒಂದು ವಿಳಾಸಕ್ಕೆ ಸಮಾಲೋಚಿಸುತ್ತದೆ, ನಂತರ ಏನೂ ಚಲಿಸುವುದಿಲ್ಲ. Ping ವಿಫಲವಾಗುತ್ತದೆ, ಬ್ರೌಸರ್ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಕಂಟೇನರ್ ಸಾರ್ವಕಾಲಿಕ ಸಂಪರ್ಕಿತವಾಗಿ ಕಾಣುತ್ತದೆ. ಈ ಮಾದರಿ ರೂಟಿಂಗ್ ಟೇಬಲ್ನ ಸಮಸ್ಯೆ ಅಲ್ಲ, ಏಕೆಂದರೆ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ನಿಯಂತ್ರಣ ಸಂಪರ್ಕವನ್ನೂ ಮುರಿಯುತ್ತವೆ. ಇದು ಪೇಲೋಡ್ನ ಮಾರ್ಗ, ಮತ್ತು PPTP ಯಲ್ಲಿ ಪೇಲೋಡ್ ಈಗತಾನೇ ಯಶಸ್ವಿಯಾದ ಪ್ರೋಟೋಕಾಲ್ಗಿಂತ ಬೇರೆ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ.

ಐದು ಪರಿಶೀಲನೆಗಳು, ಹೆಚ್ಚು ಸಮಯ ಉಳಿಸುವ ಕ್ರಮದಲ್ಲಿ.

ಪರಿಶೀಲನೆ 1: ನಿಯಂತ್ರಣ ಚಾನಲ್ ಅನ್ನು ಪೇಲೋಡ್ನಿಂದ ಬೇರ್ಪಡಿಸಿ

PPTP TCP 1723 ಮೇಲೆ ದೃಢೀಕರಣ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ PPP ಪೇಲೋಡ್ ಅನ್ನು GRE, IP ಪ್ರೋಟೋಕಾಲ್ 47 ಒಳಗೆ ಸಾಗಿಸುತ್ತದೆ. GRE TCP ಅಲ್ಲ, UDP ಕೂಡ ಅಲ್ಲ, ಆದ್ದರಿಂದ ನಿಯಂತ್ರಣ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಪ್ರತಿಯೊಂದು ನಿಯಮವೂ ಅದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. 1723 ಪಾಸ್ ಮಾಡುವ NAT ಅಥವಾ ಫೈರ್ವಾಲ್ 47 ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ದೂರಿಲ್ಲದೆ ಬಿಡಬಹುದು, ಮತ್ತು ಸೆಷನ್ ಯಶಸ್ಸಿನಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ಅರ್ಧ ನಿರ್ಮಿತವಾಗಿ ಉಳಿಯುತ್ತದೆ.

ಲಾಗಿನ್ ಕೆಲಸ ಮಾಡಿ ಯಾವುದೇ ಪ್ಯಾಕೆಟ್ ಹಿಂತಿರುಗದಿದ್ದರೆ, ಮೊದಲು GRE ಎಂದು ಭಾವಿಸಿ, ನಂತರ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿ.

ಪರಿಶೀಲನೆ 2: ಹೋಸ್ಟ್ ಕರ್ನಲ್ನಲ್ಲಿ ಸಹಾಯಕವನ್ನು ಖಚಿತಪಡಿಸಿ

ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್ ಸಹಾಯಕವಿಲ್ಲದೆ TCP ನಿಯಂತ್ರಣ ಸಂಪರ್ಕವನ್ನು GRE ಹರಿವಿಗೆ ಜೋಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮಾಡ್ಯೂಲ್ nf_conntrack_pptp ಆಗಿದೆ, ಅದು ಹೋಸ್ಟ್ ಕರ್ನಲ್ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ, ಮತ್ತು ಕಂಟೇನರ್ ಇಮೇಜ್ನ ಒಳಗೆ ಅದನ್ನು ಲೋಡ್ ಮಾಡುವುದರಿಂದ ಏನೂ ಆಗುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಮಾಡ್ಯೂಲ್ಗಳು ಇಡೀ ಹೋಸ್ಟ್ಗೆ ಅನ್ವಯಿಸುತ್ತವೆ. Docker ಹೋಸ್ಟ್ನಲ್ಲಿ lsmod | grep nf_conntrack_pptp ಎಂಬುದೇ ಪರಿಶೀಲನೆ. ಅದು ಇಲ್ಲದಿದ್ದರೆ, modprobe nf_conntrack_pptp ಚಾಲನೆಯಲ್ಲಿರುವ ಕರ್ನಲ್ಗೆ ಅದನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಬೂಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದನ್ನು ಹೋಸ್ಟ್ ಸಂರಚನೆಗೂ ಸೇರಿಸಿ.

ಮರುಬೂಟ್ನಲ್ಲಿ ಮಾಯವಾಗುವ ಮಾಡ್ಯೂಲ್ ಮುಂದಿನ ತಿಂಗಳು ಅದೇ ಟಿಕೆಟ್ ಆಗುತ್ತದೆ.

ಪರಿಶೀಲನೆ 3: ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಕರ್ನಲ್ ನೀತಿಯನ್ನು ಓದಿ

ಮಾಡ್ಯೂಲ್ ಇದ್ದರೂ, 4.7 ರಿಂದ ಕರ್ನಲ್ಗಳು net.netfilter.nf_conntrack_helper ಅನ್ನು ಡೀಫಾಲ್ಟ್ ಆಗಿ 0 ಗೆ ಹೊಂದಿಸುತ್ತವೆ, ಇದು ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಸ್ವಯಂಚಾಲಿತ ಸಹಾಯಕ ನಿಯೋಜನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಆ ಡೀಫಾಲ್ಟ್ ಕಾರಣವೇ ಸರಿಯಾಗಿ ಸ್ಥಾಪಿತವಾದ ಮಾಡ್ಯೂಲ್ ಕೂಡ ಏನೂ ಮಾಡದಿರುವುದು: ಕೋಡ್ ಇದೆ ಮತ್ತು ನೀತಿ ಅದನ್ನು ಬಳಸಬೇಡ ಎಂದು ಹೇಳುತ್ತದೆ. sysctl net.netfilter.nf_conntrack_helper ಪ್ರಸ್ತುತ ಮೌಲ್ಯವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ರನ್ಟೈಮ್ನಲ್ಲಿ ಅದನ್ನು 1 ಗೆ ಹೊಂದಿಸುವುದು ಸಹಾಯಕವನ್ನು ಮತ್ತೆ ಲಭ್ಯವಾಗಿಸುತ್ತದೆ. ವಿನ್ಯಾಸ ಅನುಮತಿಸಿದರೆ ಹೋಸ್ಟ್ನ sysctl ಸಂರಚನೆಯ ಮೂಲಕ ಮೌಲ್ಯವನ್ನು ಉಳಿಸಿ.

ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆ ಸಂಚಾರಕ್ಕೆ ಸೂಚ್ಯವಾಗಿ ನಿರೀಕ್ಷೆಗಳನ್ನು ಸೃಷ್ಟಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಬದಲಾದುದಕ್ಕೆ ಅದೇ ಕಾರಣ. ಅದನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಹೋಸ್ಟ್ಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಅಥವಾ ಸಹಾಯಕವನ್ನು ಗುರಿಯಾಗಿಸುವ ಸ್ಪಷ್ಟ ನಿಯಮವನ್ನು ಬಳಸಿ.

ಪರಿಶೀಲನೆ 4: ಕಂಟೇನರ್ನ ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡಿ

ಲೋಡ್ ಆದ ಸಹಾಯಕ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಕಂಟೇನರ್ಗೆ PPTP ಸರ್ವರ್ಗೆ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಹೋಸ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ GRE ಗೆ ಅನುಮತಿ ನೀಡಬೇಕು: iptables -L FORWARD -v -n 47 ಪ್ರೋಟೋಕಾಲ್ ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತದೆಯೇ ಮತ್ತು ಕೌಂಟರ್ಗಳು ಚಲಿಸುತ್ತವೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. Docker ನ masquerade ನಿಯಮಗಳು TCP ಮತ್ತು UDP ಅನ್ನು ಅನುವಾದಿಸುತ್ತವೆ, 47 ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನಲ್ಲ, ಆದ್ದರಿಂದ ಸೇತುವೆ ಕಂಟೇನರ್ಗೆ ಸ್ಪಷ್ಟ forward ಸ್ವೀಕೃತಿ ಮತ್ತು ಕೆಲವು ಹೋಸ್ಟ್ಗಳಲ್ಲಿ ತನ್ನದೇ ಅನುವಾದ ನಿಯಮ ಬೇಕಾಗಬಹುದು. ಕಂಟೇನರ್ ತನ್ನ ಇಮೇಜ್ ನಿರೀಕ್ಷಿಸುವ PPP ಸಾಧನ ಬೆಂಬಲವನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದೂ ಖಚಿತಪಡಿಸಿ.

ನಿಯಮದ ಪಠ್ಯವಲ್ಲ, ಕೌಂಟರ್ಗಳನ್ನು ಓದಿ. ಇರುವ ಆದರೆ ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗದ ನಿಯಮ ಅಲಂಕಾರ.

ಪರಿಶೀಲನೆ 5: GRE ಟ್ರ್ಯಾಕ್ ಆಗುತ್ತಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ, ನಂತರ PPTP ಬಗ್ಗೆ ನಿರ್ಧರಿಸಿ

ಕ್ಲೈಂಟ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಟ್ರ್ಯಾಕಿಂಗ್ ಟೇಬಲ್ ಓದಿ. ಸ್ಥಾಪಿತ PPTP ನಿಯಂತ್ರಣ ನಮೂದು ಮತ್ತು ಸಂಬಂಧಿತ GRE ನಮೂದು ಎಂದರೆ ಸಹಾಯಕ ಹರಿವುಗಳನ್ನು ಜೋಡಿಸುತ್ತಿದೆ ಮತ್ತು ಉಳಿದ ದೋಷ ಬೇರೆಡೆ ಇದೆ. GRE ನಮೂದಿಲ್ಲದ ನಿಯಂತ್ರಣ ನಮೂದು ಎಂದರೆ ಪೇಲೋಡ್ ಬಿಡಲ್ಪಡುತ್ತಿದೆ ಅಥವಾ ಟ್ರ್ಯಾಕ್ ಆಗುತ್ತಿಲ್ಲ, ಇದು ನಿಮ್ಮನ್ನು ಪರಿಶೀಲನೆ 2 ಮತ್ತು 3 ಗೆ ಕರೆದೊಯ್ಯುತ್ತದೆ.

PPTP ಸ್ವತಃ ಹಳೆಯದು ಮತ್ತು MS-CHAPv2 ದುರ್ಬಲವಾಗಿದೆ. ಸರ್ವರ್ L2TP/IPsec, IKEv2 ಅಥವಾ WireGuard ಅನ್ನೂ ನೀಡಿದರೆ, ಅವುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಹೋಗುವುದು ಈ ಇಡೀ ವರ್ಗದ ಸಮಸ್ಯೆಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

PPTP ಉಳಿಯಬೇಕಾದಲ್ಲಿ, ಕಂಟೇನರ್ ಒಳಗೆ ಅಲ್ಲದೆ ಹೋಸ್ಟ್ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಚಲಾಯಿಸುವುದು NAT ಮತ್ತು ಫಿಲ್ಟರಿಂಗ್ನ ಒಂದು ಪದರವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಇದು ಹೆಚ್ಚಾಗಿ ಅಗ್ಗದ ನಿರ್ಧಾರ.