PPTP ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನಂತರ Linux NAT ಹಿಂದೆ ನೇತಾಡುತ್ತದೆ: GRE ಸಹಾಯಕ

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

ಫಾರ್ವರ್ಡ್ ಎಂದೂ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ

ಪೋರ್ಟ್-ಫಾರ್ವರ್ಡ್ ನಿಯಮ TCP ಅಥವಾ UDP ಸಂಚಾರವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸೆಷನ್ ಮಧ್ಯದಲ್ಲಿ ಬೇರೆ IP ಪ್ರೋಟೋಕಾಲ್ಗೆ ಬದಲಾಗುವ ಪೇಲೋಡ್ ಅನ್ನು ಅದು ವಿವರಿಸಲಾರದು, ಮತ್ತು PPTP ನಿಖರವಾಗಿ ಅದನ್ನೇ ಮಾಡುತ್ತದೆ.

ಆದ್ದರಿಂದ ಸಂಪರ್ಕವು ನೇತಾಡುವ ಕ್ಷಣದವರೆಗೆ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ. ಪೋರ್ಟ್ ನಿಯಮ ನಿಯಂತ್ರಿಸಬಲ್ಲ ಭಾಗ ಯಶಸ್ವಿಯಾಯಿತು, ಮತ್ತು ನಿಯಂತ್ರಿಸಲಾರದ ಭಾಗವೇ ವಿಫಲವಾದ ಭಾಗ.

ನಿಯಂತ್ರಣಕ್ಕೆ TCP, ಡೇಟಾಗೆ GRE

ಕರೆ TCP 1723 ಮೇಲೆ ಮಾತುಕತೆಯಾಗುತ್ತದೆ. ಅದು ಎದ್ದ ನಂತರ ಪೇಲೋಡ್ GRE ಗೆ, IP ಪ್ರೋಟೋಕಾಲ್ 47 ಗೆ ಹೋಗುತ್ತದೆ, ಅದು ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳನ್ನೇ ಹೊತ್ತುಕೊಳ್ಳುವುದಿಲ್ಲ. ಪೋರ್ಟ್ಗಳ ಮೇಲೆ ಅವಲಂಬಿತ ನಿಯಮಕ್ಕೆ ಹೊಂದಿಸಲು ಏನೂ ಇಲ್ಲ.

GRE ಹೊತ್ತುಕೊಳ್ಳುವುದು ಅದರ ಹೆಡರ್ನಲ್ಲಿನ ಕರೆ ಗುರುತಿಸುವಿಕೆ, ಮತ್ತು NAT ಅನುವಾದಕ ಆ ಕ್ಷೇತ್ರವನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಸ್ಥಿರವಾಗಿ ಮರುಬರೆಯಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಸೆಷನ್ನ ಎರಡು ಅರ್ಧಗಳು ಪರಸ್ಪರ ಒಪ್ಪಿಕೊಳ್ಳುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ. ಒಂದು ದಿಕ್ಕು ಮರುಬರೆದು ಇನ್ನೊಂದು ಇಲ್ಲದಿದ್ದರೆ ದೃಢೀಕರಿಸಿ ನಂತರ ಪ್ರತಿ ಡೇಟಾ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಬಿಸಾಡುವ ಸೆಷನ್ ಉಂಟಾಗುತ್ತದೆ. ರೋಗಲಕ್ಷಣದ ಆಕಾರ ನಿಖರವಾಗಿ ಇದೇ: ಯಶಸ್ಸು, ನಂತರ ಮೌನ.

PPTP ಇಲ್ಲದ ಬರಿ GRE ಗೆ ಅಂತಹ ಮರುಬರವು ಬೇಕಿಲ್ಲ, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ GRE ಸುರಂಗವು ಅದೇ ಮಾರ್ಗದಲ್ಲಿ PPTP ಕ್ಲೈಂಟ್ಗೆ ವಿಫಲವಾಗುವ ರೌಟರ್ ಮೂಲಕ ಕೆಲಸ ಮಾಡಬಹುದು.

ನಾಲ್ಕು ಮಾಡ್ಯೂಲ್ಗಳು ಮತ್ತು ಅವನ್ನು ಆಫ್ ಮಾಡಿದ sysctl

ಎರಡು ಮಾಡ್ಯೂಲ್ಗಳು ಫ್ರೇಮಿಂಗ್ ನಿರ್ವಹಿಸುತ್ತವೆ, nf_conntrack_proto_gre ಮತ್ತು nf_nat_proto_gre. ಇನ್ನೆರಡು ಕರೆ ಗುರುತಿಸುವಿಕೆ ನಿರ್ವಹಿಸುತ್ತವೆ, nf_conntrack_pptp ಮತ್ತು nf_nat_pptp. ಕೊನೆಯದನ್ನು ಲೋಡ್ ಮಾಡಿದರೆ ಉಳಿದವು ಅವಲಂಬನೆಗಳ ಮೂಲಕ ಬರುತ್ತವೆ, ಆದ್ದರಿಂದ ಮಾಡ್ಯೂಲ್ ಪಟ್ಟಿ ನಾಲ್ಕನ್ನೂ ತೋರಿಸಬೇಕು.

ಹಳೆಯ ಸೂಚನೆಗಳು 2.6 ಯುಗದ ip_ ಪೂರ್ವಪ್ರತ್ಯಯ ಬಳಸುತ್ತವೆ. ಆ ಆದೇಶಗಳು ಏನನ್ನೂ ಲೋಡ್ ಮಾಡದೆಯೇ ಚಲಿಸುತ್ತಿರುವಂತೆ ಕಾಣಬಹುದು, ಆದ್ದರಿಂದ ನಿರ್ಗಮನ ಸ್ಥಿತಿಯ ಬದಲು ಲೋಡ್ ಆದ ಪಟ್ಟಿಯನ್ನು ಪರಿಶೀಲಿಸಿ.

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

ಒಂದೋ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆಯನ್ನು ಜಾಗತಿಕವಾಗಿ ಮತ್ತೆ ಆನ್ ಮಾಡಿ, ಅಥವಾ ಸಹಾಯಕವನ್ನು ಅದು ಬೇಕಾದ ಹರಿವುಗಳಿಗೆ ಜೋಡಿಸಿ ಉಳಿದೆಲ್ಲವನ್ನು ಹಾಗೆಯೇ ಬಿಡಿ:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

ಎರಡನೇ ಆಯ್ಕೆಯೇ ಉತ್ತಮ. ಇಡೀ ರೌಟರ್ನಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆಯನ್ನು ಮತ್ತೆ ಸಕ್ರಿಯಗೊಳಿಸುವ ಬದಲು ಅದು ವರ್ತನೆಯನ್ನು PPTP ಸಂಚಾರಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ.

ಪೋರ್ಟ್ಗಳಿಲ್ಲದ ಪ್ರೋಟೋಕಾಲ್ ತೆರೆಯುವುದು

1723 ಅನ್ನು ಅನುಮತಿಸುವ ಫೈರ್ವಾಲ್ ನಿಯಮ 47 ಪ್ರೋಟೋಕಾಲ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. firewalld ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಕಡೆಗಿನ ವಲಯದಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಅನುಮತಿಸಿ. ಸಾಮಾನ್ಯ iptables ನಲ್ಲಿ ಇನ್ಪುಟ್ ಸರಪಳಿಯಲ್ಲಿ gre ಪ್ರೋಟೋಕಾಲ್ ಸ್ವೀಕರಿಸಿ.

ನಂತರ ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ. ಕ್ಲೈಂಟ್ ಬಿಡುವ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಉತ್ತರಗಳು ಬಾರದಿದ್ದರೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಫಿಲ್ಟರ್ ಆಗಿದೆ, ಮತ್ತು ಅದು ತಿರಸ್ಕೃತ ರುಜುವಾತಿಗಿಂತ ಬೇರೆ ದೋಷ.

ಸಂಪರ್ಕಗೊಂಡ ನಂತರ ಗಾತ್ರದ ಮಿತಿ

GRE ಹೆಡರ್ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಒಳಗಿನ PPP ಇನ್ನಷ್ಟು ಸೇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಲಿಂಕ್ 1500 ಕ್ಕಿಂತ ಬಹಳ ಕಡಿಮೆ MTU ವರದಿ ಮಾಡುತ್ತದೆ. ಚಿಕ್ಕ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಲೋಡ್ ಆಗುತ್ತವೆ ಮತ್ತು ದೊಡ್ಡವು ನೇತಾಡುತ್ತವೆ, ಇದು ಮೊದಲ ಸಮಸ್ಯೆ ಬಗೆಹರಿದ ಕ್ಷಣದಲ್ಲಿ ಕಾಣಿಸುವ ಎರಡನೇ, ಅಸಂಬಂಧಿತ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ.

ಕ್ಲೈಂಟ್ನ PPP ಅಡಾಪ್ಟರ್ನಲ್ಲಿ MTU ಓದಿ ಮತ್ತು ಅದನ್ನು ರೌಟರ್ನ ಸ್ವಂತ ಲೆಕ್ಕಾಚಾರದೊಂದಿಗೆ ಹೊಂದಿಸಿ ಏನಾದರೂ ಕೆಲಸ ಮಾಡುವವರೆಗೆ ಸಂಖ್ಯೆಗಳನ್ನು ಇಳಿಸುವ ಬದಲು. ಪೂರ್ಣ ಗಾತ್ರದ ಪ್ಯಾಕೆಟ್ಗಳು ಹೊರಟು ಏನೂ ಹಿಂತಿರುಗದಿದ್ದರೆ ಅದು ಅನುವಾದದ ಕಡೆಗಲ್ಲ, ಆ ಮಿತಿಯ ಕಡೆಗೆ ಸೂಚಿಸುತ್ತದೆ.

ಮಾರ್ಗ ಸರಿಪಡಿಸುವುದು ಬಳಕೆದಾರನನ್ನು ಕೆಲಸಕ್ಕೆ ತರುತ್ತದೆ, ಮತ್ತು ಅದು PPTP ಅನ್ನು ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿಸುವುದಿಲ್ಲ. MS-CHAPv2 ಮತ್ತು RC4 ಬಹಳ ಹಿಂದೆಯೇ ಬಳಕೆಯಲ್ಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಮಾಡ್ಯೂಲ್ ಲೋಡ್ ಮಾಡುವುದನ್ನು ತಾತ್ಕಾಲಿಕ ಸರಿಪಡಿಸುವಿಕೆ ಎಂದು ಪರಿಗಣಿಸಿ ಮತ್ತು ನಿರ್ವಹಿತ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಹೋಗುವ ಯೋಜನೆ ಮಾಡಿ.