pptpd ನಲ್ಲಿ GRE ಬರವಣಿಗೆ ವೈಫಲ್ಯಗಳು ಪಾಸ್ವರ್ಡ್ ಸಮಸ್ಯೆ ಅಲ್ಲ

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

ಎರಡು ಸಂದೇಶಗಳು, ಎರಡು ವಿಭಿನ್ನ ವೈಫಲ್ಯಗಳು

ಓದುವ ವೈಫಲ್ಯ ಎಂದರೆ GRE ಪ್ಯಾಕೆಟ್ಗಳು ಡೀಮನ್ ಅನ್ನು ತಲುಪುವುದೇ ಇಲ್ಲ, ಅಥವಾ ಒಳಗೆ ಬರುವಾಗ ಬಿಸಾಡಲ್ಪಡುತ್ತವೆ. ನಿಯಂತ್ರಣ ಸಂಪರ್ಕ ಸಂಪೂರ್ಣವಾಗಿ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣಬಹುದು, ಆದರೆ ಡೇಟಾ ಮಾರ್ಗದಲ್ಲಿ ಏನೂ ದಾಟುವುದಿಲ್ಲ. ದೃಢೀಕರಣವು ಸ್ಪಷ್ಟವಾಗಿ ಕೆಲಸ ಮಾಡಿದ ಏಕೈಕ ವಿಷಯ.

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

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಎರಡರಲ್ಲಿ ಯಾವುದು ಕಾಣಿಸುತ್ತದೆ ಎಂದು ಓದಿ. ಅವು ನಿಮ್ಮನ್ನು ವಿಭಿನ್ನ ಪದರಗಳಿಗೆ ಕಳುಹಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಒಂದೇ ಲಕ್ಷಣವಾಗಿ ಪರಿಗಣಿಸುವುದೇ ಒಂದೇ ಸರ್ವರ್ ಸಂಬಂಧವಿಲ್ಲದ ಕಾರಣಗಳಿಗೆ ಎರಡು ಬಾರಿ ಪ್ಯಾಚ್ ಆಗುವ ಕಾರಣ. ಲಾಗ್ ಸಾಲು ನೀವು ಪಡೆಯುವ ಏಕೈಕ ಉಚಿತ ಕಾರ್ಯನಿರ್ಣಯ.

ಪ್ರೋಟೋಕಾಲ್ 47 ಪೋರ್ಟ್ 47 ಅಲ್ಲ

PPTP ಕರೆ ಸ್ಥಾಪಿಸಲು TCP 1723 ಮತ್ತು ಪೇಲೋಡ್ ಸಾಗಿಸಲು GRE ಬಳಸುತ್ತದೆ. GRE ಎಂಬುದು IP ಪ್ರೋಟೋಕಾಲ್ 47, ಪೋರ್ಟ್ ಸಂಖ್ಯೆ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಪೋರ್ಟ್ 47 ತೆರೆಯುವ ಫೈರ್ವಾಲ್ ನಿಯಮ ಯಾವುದೇ ಉಪಯುಕ್ತ ವಿಷಯಕ್ಕೆ ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ.

ಮಾರ್ಗದಲ್ಲಿರುವ ರೌಟರ್ಗೆ PPTP passthrough ವೈಶಿಷ್ಟ್ಯ ಅಥವಾ ಸ್ಪಷ್ಟ GRE ಅನುಮತಿ ಬೇಕು. ಅದಿಲ್ಲದೆ TCP ಹ್ಯಾಂಡ್ಶೇಕ್ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಸುರಂಗ ಎಂದಿಗೂ ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸುವುದಿಲ್ಲ, ಇದು ಮೇಲಿನ ಓದುವ ವೈಫಲ್ಯವನ್ನೇ ಉಂಟುಮಾಡುತ್ತದೆ. ಫೈರ್ವಾಲ್ನಲ್ಲಿ ಪೋರ್ಟ್ 47 ನಿಯಮಗಳು ಈ ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ ಅತ್ಯಂತ ಹೆಚ್ಚು ವ್ಯರ್ಥವಾದ ಮಧ್ಯಾಹ್ನ.

ಯಾವ ಬದಿ ಸಂಚಾರವನ್ನು ಬಿಸಾಡುತ್ತಿದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಸರ್ವರ್ನಲ್ಲಿ ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಒಟ್ಟಿಗೆ ಗಮನಿಸಿ: tcpdump -ni any port 1723 or proto gre.

1723 ಕರೆ ಸ್ಥಾಪನೆಯನ್ನು ತೋರಿಸಿ GRE ಸದ್ದಿಲ್ಲದೆ ಇದ್ದರೆ, ನಿರ್ಬಂಧವು ಹೋಸ್ಟ್ನ ಮೇಲಿದೆ. GRE ಬಂದರೂ ಡೀಮನ್ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಸಮಸ್ಯೆ ಸ್ಥಳೀಯವಾಗಿದೆ ಮತ್ತು ಆಯ್ಕೆಗಳೇ ಮುಂದೆ ನೋಡಬೇಕಾದ ಸ್ಥಳ.

ಹೋಸ್ಟ್ ನಿಜವಾಗಿ ಮುಂದುಮಾಡುವಲ್ಲಿ GRE ಗೆ ಅನುಮತಿ ನೀಡಿ

GRE ಗೆ forward ನಿಯಮ ಸೇರಿಸುವುದು ಸುರಂಗ ಸಂಚಾರವನ್ನು ಮುಂದುಮಾಡುವ ಹೋಸ್ಟ್ನಲ್ಲಿ ಸೂಕ್ತ ಪರೀಕ್ಷೆ, ಮತ್ತು ಅದು ನೀತಿ ಅಲ್ಲ. ಒಂದು ಪ್ರೋಟೋಕಾಲ್ನ ಎಲ್ಲವನ್ನೂ ಸ್ವೀಕರಿಸುವ ಪರೀಕ್ಷಾ ನಿಯಮ ಕಾರ್ಯನಿರ್ಣಯ, ವಿನ್ಯಾಸ ಅಲ್ಲ. ಏನನ್ನಾದರೂ ಕಲಿಯಲು ಸಾಕಷ್ಟು ಇರಿಸಿ, ನಂತರ ಅದನ್ನು ಸೀಮಿತ ನಿಯಮದಿಂದ ಬದಲಾಯಿಸಿ.

ಸರ್ವರ್ಗೆ ಹೀಗೇ ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ input ನಿಯಮ ಸೇರಿಸಿ, ಏಕೆಂದರೆ forward ಸರಪಳಿ ಅವನ್ನು ನೋಡುವುದಿಲ್ಲ. ನಂತರ ಸಂಪರ್ಕ ಪ್ರಯತ್ನದ ಮೊದಲು ಮತ್ತು ನಂತರ ನಿಯಮದ ಕೌಂಟರ್ಗಳನ್ನು ನೋಡಿ, ಇದು ಪ್ಯಾಕೆಟ್ಗಳು ಬರುತ್ತವೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ.

ಪ್ರತಿ ರೀಬೂಟ್ ನಂತರ ಮತ್ತೆ ಚಲಾಯಿಸುವ ಬದಲು ವಿತರಣೆಯ ಫೈರ್ವಾಲ್ ಸೇವೆಯ ಮೂಲಕ ನಿಯಮವನ್ನು ಶಾಶ್ವತಗೊಳಿಸಿ. nftables ಹೋಸ್ಟ್ನಲ್ಲಿ input ಮತ್ತು forward ಎರಡೂ ಸರಪಳಿಗಳಲ್ಲಿ ip protocol gre ಹೊಂದಿಸಿ.

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

ನಿಮ್ಮ ಬಳಿ ನಿಜವಾಗಿ ಇರುವ ಕ್ಲೈಂಟ್ಗೆ ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿಸಿ

ಇತರ ವರದಿಯ ಸರಿಪಡಿಸುವಿಕೆ /etc/ppp/pptpd-options ನಲ್ಲಿದೆ, ಅಲ್ಲಿ ಪಾಕವಿಧಾನ PAP, CHAP ಮತ್ತು MSCHAP ಅನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ, ಸಂಬಂಧಿತ require ಸಾಲುಗಳನ್ನು ಕಾಮೆಂಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸ್ಥಿತಿಯ MPPE ಉಳಿಸುತ್ತದೆ. ಆ ಪಾಕವಿಧಾನ ಒಂದು ಕ್ಲೈಂಟ್ ಮಿಶ್ರಣಕ್ಕೆ ಬರೆಯಲಾಗಿತ್ತು, ಮತ್ತು ಕುರುಡು ನಕಲು ಸಾಮಾನ್ಯ ಪ್ರಕರಣವನ್ನು ಮುರಿಯುತ್ತದೆ. ನಿರಾಕರಣ ಸಾಲುಗಳನ್ನು ಶಿಫಾರಸಿನಂತೆ ಅಲ್ಲ, ಲೇಖಕರ ಬಳಿ ಯಾವ ಕ್ಲೈಂಟ್ಗಳಿದ್ದವು ಎಂಬ ಹೇಳಿಕೆಯಾಗಿ ಓದಿ.

Windows ಕ್ಲೈಂಟ್ಗೆ ಸಾಮಾನ್ಯವಾಗಿ MS-CHAPv2 ಜೊತೆ MPPE-128 ಬೇಕು. ಆ ಅಗತ್ಯಗಳನ್ನು ಉಳಿಸಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಚರ್ಚಿಸಲಾಗದ ಆಯ್ಕೆಗಳನ್ನು ಮಾತ್ರ ತೆಗೆದುಹಾಕಿ.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

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

ಕ್ಲೈಂಟ್ನ ದೋಷ ಸಂಖ್ಯೆಯನ್ನು ಓದಿ

ಕ್ಲೈಂಟ್ನ ಸಂಖ್ಯೆಯ ಕೋಡ್ ಸರ್ವರ್ ಲಾಗ್ಗಿಂತ ವೇಗವಾಗಿ ಹಂತವನ್ನು ಸಂಕುಚಿಸುತ್ತದೆ. ಬೇರೆ ಏನನ್ನಾದರೂ ಓದುವ ಮೊದಲು ಅದನ್ನು ಓದಿ. 691 ಎಂದರೆ ರುಜುವಾತುಗಳು ತಿರಸ್ಕೃತವಾದವು, 721 ಎಂದರೆ ಸರ್ವರ್ ಎಂದಿಗೂ ಉತ್ತರಿಸಲಿಲ್ಲ, ಮತ್ತು 619 ಎಂದರೆ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಿತು. ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಎರಡು ನಿಮಿಷ ಸಂರಚನೆಯೊಂದಿಗೆ ಒಂದು ಗಂಟೆ ಉಳಿಸುತ್ತದೆ.

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

ಲಾಗಿನ್ ಯಶಸ್ವಿಯಾಗಿ ಯಾವುದೇ ಸಂಚಾರ ಚಲಿಸದಿದ್ದರೆ, GRE ಇನ್ನೂ ಸಂಶಯಾಸ್ಪದ. ರುಜುವಾತು ಭಂಡಾರದ ಬದಲು ಕ್ಯಾಪ್ಚರ್ಗೆ ಮರಳುವ ಕ್ಷಣ ಅದು.