ಹಾಟ್ಸ್ಪಾಟ್ ಮೂಲಕ PPTP: TCP 1723 ಕೇವಲ ಅರ್ಧ
PPTP ನಿಯಂತ್ರಣ TCP 1723 ಮೇಲೆ ಹೋಗುತ್ತದೆ, ಡೇಟಾ GRE ಮೇಲೆ ಹೋಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಹಾಟ್ಸ್ಪಾಟ್ ಒಂದನ್ನು ದಾಟಿಸಿ ಇನ್ನೊಂದನ್ನು ಬೀಳಿಸಬಹುದು. ಆಪರೇಟರ್ ಆಗಿ ದೂಷಿಸುವ ಮೊದಲು ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ: ನಿಯಂತ್ರಣ ಸಂಪರ್ಕ ತೆರೆಯುತ್ತದೆಯೇ, GRE ಮಾರ್ಗದಲ್ಲಿ ಉಳಿಯುತ್ತದೆಯೇ, ಸರ್ವರ್ ಕರೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆಯೇ, ಮತ್ತು ದೃಢೀಕರಣ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆಯೇ. PPTP ಕ್ಲೈಂಟ್ಗೆ 1723 ರಲ್ಲಿ TCP ಸೆಷನ್ ಮತ್ತು ಡೇಟಾವನ್ನು ಸಾಗಿಸುವ GRE ಮಾರ್ಗ ಎರಡೂ ಬೇಕು, ಮತ್ತು ಹಾಟ್ಸ್ಪಾಟ್ ಒಂದನ್ನು ದಾಟಿಸಿ ಇನ್ನೊಂದನ್ನು ಬೀಳಿಸಬಹುದು. ಅವನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡುವುದು ಊಹಿಸುವ ಬದಲು ಯಾವ ಗಡಿಯನ್ನು ತನಿಖೆ ಮಾಡಬೇಕೆಂದು ಹೇಳುತ್ತದೆ. Windows ನ ದೋಷ ಸಂಖ್ಯೆಗಳು ಅದನ್ನು ನಿಮಗಾಗಿ ಮಾಡುವುದಿಲ್ಲ.
GRE ಎಂಬುದು IP ಪ್ರೋಟೋಕಾಲ್ 47. ಅದು TCP ಅಥವಾ UDP ಪೋರ್ಟ್ 47 ಅಲ್ಲ, ಮತ್ತು ಈ ವ್ಯತ್ಯಾಸವೇ ಫೈರ್ವಾಲ್ ಬಗ್ಗೆ ಇರುವ ಬಹುಪಾಲು ಗೊಂದಲವನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಎರಡು ಮಾರ್ಗಗಳು, ಒಂದು ಸಂಪರ್ಕ
ನಿಯಂತ್ರಣ ಸಂಪರ್ಕವು ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್ 1723 ಗೆ ಸಾಮಾನ್ಯ TCP ಸೆಷನ್, ಅದನ್ನು ಬಹುಪಾಲು ನೆಟ್ವರ್ಕ್ಗಳು ದೂರಿಲ್ಲದೆ ಅನುಮತಿಸುತ್ತವೆ. ಡೇಟಾ ಮಾರ್ಗ GRE, ಪ್ರೋಟೋಕಾಲ್ 47, ಮತ್ತು ಮೊದಲನೆಯದನ್ನು ಅನುಮತಿಸುವ ಫೈರ್ವಾಲ್ ಎರಡನೆಯದರ ಬಗ್ಗೆ ಸಂಪೂರ್ಣ ಅಜ್ಞಾನವಾಗಿರಬಹುದು. ಈ ಸಂಯೋಜನೆಯು ಪ್ರಾರಂಭವಾದಂತೆ ಕಾಣಿಸಿ ನಂತರ ಏನನ್ನೂ ಸಾಗಿಸದ ಕ್ಲೈಂಟ್ ಸೃಷ್ಟಿಸುತ್ತದೆ, ಇದು ನಿರಾಕರಿಸಿದ ಸಂಪರ್ಕಕ್ಕಿಂತ ಬಹಳ ಕಡಿಮೆ ಮಾಹಿತಿಯುಕ್ತ ಲಕ್ಷಣ. ಆಪರೇಟರ್ ಬಗ್ಗೆ ಏನನ್ನಾದರೂ ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ.
ಅನುವಾದ ತನ್ನದೇ ಷರತ್ತನ್ನು ಸೇರಿಸುತ್ತದೆ. ಪೋರ್ಟ್ ಹಂಚಿಕೊಳ್ಳುವ ಗೇಟ್ವೇಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ PPTP ಅರ್ಥ ಮಾಡಿಕೊಳ್ಳುವ ALG ಬೇಕಾಗುತ್ತದೆ, ಕರೆ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ವಿಳಾಸಗಳೊಂದಿಗೆ ಮರುಬರೆಯಲು, ಮತ್ತು ಅದಿಲ್ಲದ ಒಂದು ಸೆಷನ್ ಅನ್ನು ಪ್ಯಾಕೆಟ್ ನಷ್ಟದಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ಹಾಳುಮಾಡಬಹುದು. ಈ ನಡವಳಿಕೆ ಸಾಮಾನ್ಯ ಆದರೆ ಅನುಷ್ಠಾನ-ಅವಲಂಬಿತ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಮಾರಾಟಗಾರನ ಮಿತಿಯನ್ನು ಪ್ರತಿ ಹಾಟ್ಸ್ಪಾಟ್ನ ಗುಣವಲ್ಲ, ಉದಾಹರಣೆ ಎಂದು ಪರಿಗಣಿಸಿ.
ಹಾಟ್ಸ್ಪಾಟ್ ಇನ್ನೂ ಎರಡು ಗಡಿಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ
ಕ್ಲೈಂಟ್ ಸಂಚಾರ ಸಾಮಾನ್ಯವಾಗಿ ಫೋನ್ ನ ಸ್ವಂತ ಹಂಚಿಕೆ NAT ಮತ್ತು ನಂತರ ಸರ್ವರ್ ತಲುಪುವ ಮೊದಲು ಆಪರೇಟರ್-ಮಟ್ಟದ ಅನುವಾದದ ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಕಚೇರಿ ರೌಟರ್ ನ ನಿಯಮ ಬೇರೊಬ್ಬರ ಮಧ್ಯ-ಪೆಟ್ಟಿಗೆಯನ್ನು ಸರಿಪಡಿಸಲಾರದು, ಆದ್ದರಿಂದ ಮನೆಯ ಬದಿಯ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಅಪರೂಪಕ್ಕೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಹೊರಹೋಗುವ ಕ್ಲೈಂಟ್ಗೆ ಒಳಬರುವ ಪೋರ್ಟ್ ತೆರೆಯುವ ಅಗತ್ಯವೂ ಇಲ್ಲ; ಅನುವಾದಿತ ಸಂಪರ್ಕದ ಉತ್ತರಗಳು ಗೇಟ್ವೇ ಸೃಷ್ಟಿಸಿದ ಸ್ಥಿತಿಯ ಮೂಲಕ ಹಿಂತಿರುಗುತ್ತವೆ. NAT ಹಿಂದೆ ಹೋಸ್ಟ್ ಮಾಡಿದ ಸರ್ವರ್ಗೆ ಸಂಪೂರ್ಣ ಬೇರೆ ಅಗತ್ಯಗಳ ಗುಂಪಿದೆ.
PPTP passthrough ಎಂಬ ಮೆನು ಐಟಂ, ಎಲ್ಲಿ ಇದೆಯೋ ಅಲ್ಲಿ, ಆ ಸಾಧನ ಈ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಇದು ಫೋನ್ ನಲ್ಲಿ VPN ಹೋಸ್ಟ್ ಮಾಡುವ ಅಥವಾ ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಷರತ್ತಿಲ್ಲದೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಅದೇ ವೈಶಿಷ್ಟ್ಯವಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು GRE ದಾಟಿಸಲು ಸಾಮಾನ್ಯ ಅನುಮತಿಯಲ್ಲ.
807 ಅನ್ನು ತೀರ್ಪಲ್ಲ, ಅಡಚಣೆ ಎಂದು ಓದಿ
Windows 807 ಅನ್ನು ಅಡಚಣೆಯಾದ ಸಂಪರ್ಕ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಅದು ಕಾರಣವನ್ನಲ್ಲ ಫಲಿತಾಂಶವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅದರ ದೋಷ ಕೋಷ್ಟಕ 806 ಅನ್ನು GRE-ಸಂಬಂಧಿತ ವರ್ಗವಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ, ಮತ್ತು ಸಿದ್ಧಾಂತ ಕಟ್ಟುವ ಮೊದಲು ಈ ವ್ಯತ್ಯಾಸ ತಿಳಿಯುವುದು ಯೋಗ್ಯ. ಎರಡೂ ಸಂಖ್ಯೆಗಳಲ್ಲಿ ಯಾವುದೂ ಆಪರೇಟರ್ ಪ್ರೋಟೋಕಾಲ್ 47 ಫಿಲ್ಟರ್ ಮಾಡಿದೆಯೇ, ಸರ್ವರ್ ಸಾಮರ್ಥ್ಯ ಮುಗಿದೆಯೇ, ಅಥವಾ ರುಜುವಾತುಗಳು ಸರಿಯಾಗಿದ್ದವೇ ಎಂದು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ. ದೋಷ ಸೆಷನ್ ಮುಗಿದಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ; ಮಾರ್ಗ ಎಲ್ಲಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ.
ಹಾಟ್ಸ್ಪಾಟ್ನಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುವ ಬ್ರೌಸರ್ ಪರೀಕ್ಷೆ ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅದು GRE ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ವಿಫಲವಾದ ಹಂತವನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ
ಲ್ಯಾಪ್ಟಾಪ್, ಸರ್ವರ್ ಮತ್ತು ಪ್ರೊಫೈಲ್ ಸ್ಥಿರವಾಗಿಡಿ, ನಂತರ ಕೇವಲ ಪ್ರವೇಶ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಇನ್ನೊಂದು ಅನುಮೋದಿತ ನೆಟ್ವರ್ಕ್ಗೆ ಬದಲಿಸಿ. ಫಲಿತಾಂಶ ಬದಲಾದರೆ, ನೀವು ನಿಯಂತ್ರಿಸುವ ಗಡಿಗಳಲ್ಲಿ TCP ಮತ್ತು GRE ವಿನಿಮಯಗಳನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ ಮತ್ತು ಎಂದೂ ಸಂಭವಿಸದ ಆರಂಭಿಕ ಹಂತವನ್ನು ಹುಡುಕಿ: ನಿಯಂತ್ರಣ ಸ್ಥಾಪನೆ, ಕರೆ ಸೆಟಪ್, ಡೇಟಾ ವಿತರಣೆ, ಅಥವಾ PPP ದೃಢೀಕರಣ. ಪ್ರತಿಯೊಂದೂ ಸೆರೆಹಿಡಿಯುವಿಕೆಯಲ್ಲಿ ಬೇರೆ ಸಹಿ ಬಿಡುತ್ತದೆ. ಕೆಲಸ ಮಾಡುವ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ವಿಫಲವಾಗುವ ಒಂದಕ್ಕೆ ಹೋಲಿಸುವುದು ದೋಷ ಪಠ್ಯವನ್ನು ಮತ್ತೆ ಓದುವುದಕ್ಕಿಂತ ಬಹಳ ಮಾಹಿತಿಯುಕ್ತ.
ಇದೆಲ್ಲವೂ ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಿಯೋಜನೆಯನ್ನು ರೋಗನಿರ್ಣಯ ಮಾಡುತ್ತದೆ. ಇದು ಹೊಸ PPTP ಸೇವೆಯನ್ನು ನಿಲ್ಲಿಸಲು ವಾದವಲ್ಲ, ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮಾತುಕತೆಯಿಂದ ಬಳಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ: ಬೇರೆ ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸುವುದು ಬದಲಾಗದ ಸರ್ವರ್ ಬೇರೆ ಏನಾದರೂ ಮಾತನಾಡುವಂತೆ ಮಾಡುವುದಿಲ್ಲ.
ನಿರಂತರ ಪ್ರವೇಶಕ್ಕಾಗಿ, VPN ಮಾಲೀಕರೊಂದಿಗೆ ಬೆಂಬಲಿತ ಸ್ಥಳಾಂತರವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಿ. ಪರಿಶೀಲನಾ ಪಟ್ಟಿ ಪರಿಹಾರದ ಬದಲು ನಿರ್ಧಾರದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.