PPTP ಪಾಸ್ಥ್ರೂ ಇಲ್ಲ: Windows VPN ದೋಷ 807 ಸರಿಪಡಿಸಿ

TCP 1723 ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದು ಹಲವು ಬಾರಿ PPTP ಯ ಮೊದಲ ಭಾಗವನ್ನು ತೆರೆದು ಉಳಿದದ್ದನ್ನು ಮುರಿದು ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ Windows ಪ್ರಯತ್ನದಲ್ಲಿ ಇನ್ನೂ ದೋಷ 807 ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಮುಂದಿನ ಪ್ರವೃತ್ತಿ ಪೋರ್ಟ್ 47 ಗೆ ನಿಯಮ ಸೇರಿಸುವುದು, ಮತ್ತು ಆ ಹೆಜ್ಜೆಯೇ ಅರ್ಧ ದಿನ ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ: GRE ಎಂಬುದು IP ಹೆಡರ್ನಲ್ಲಿನ ಪ್ರೋಟೋಕಾಲ್ ಸಂಖ್ಯೆ, ಫಾರ್ವರ್ಡಿಂಗ್ ಟೇಬಲ್ ಹೊಂದಿಸಬಲ್ಲ ಪೋರ್ಟ್ ಅಲ್ಲ. ರೂಟರ್ ಪ್ರೋಟೋಕಾಲ್ 47 ಅನ್ನು ದಾಟಿಸಿ ಅದನ್ನು ಅದೇ ಕರೆಗೆ ಬಿಗಿದು ಮಾಡುವವರೆಗೆ ಸುರಂಗ ಆರಂಭವಾಗಲಾರದು. ಕೆಳಗಿನ ವಿಭಾಗಗಳು ಎರಡು ಚಾನೆಲ್ಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ ನಂತರ ಒಂದೊಂದಾಗಿ ಪರೀಕ್ಷಿಸುತ್ತವೆ.

ಪೋರ್ಟ್ ಟೇಬಲ್ನಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಸಂಖ್ಯೆಗೆ ಸಾಲಿಲ್ಲ

PPTP ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುವ ಎರಡು ಸಂಭಾಷಣೆಗಳನ್ನು ಬಳಸುತ್ತದೆ. TCP 1723 ನಲ್ಲಿನದು ಕರೆಯನ್ನು ಆರಂಭಿಸಿ, ಲಿಂಕ್ ಮಾಹಿತಿ ರವಾನಿಸಿ, ಬಳಕೆದಾರ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿದಾಗ ಅದನ್ನು ಮುಗಿಸುತ್ತದೆ. ಪೇಲೋಡ್ ಭಾಗ GRE ಒಳಗೆ ನಡೆಯುತ್ತದೆ, ಅದನ್ನು IP ಹೆಡರ್ ಪ್ರೋಟೋಕಾಲ್ ಸಂಖ್ಯೆ 47 ನಿಂದ ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಸುರಂಗದೊಳಗೆ PPP ಲಿಂಕ್ ಮೇಲೆ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ ಹಾಗೂ MS-CHAPv2 ರುಜುವಾತುಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

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

ಡೇಟಾ ಮಾರ್ಗ ಸತ್ತಾಗ Windows ಏನು ವರದಿ ಮಾಡುತ್ತದೆ

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

ಪಾಸ್ವರ್ಡ್ ಮುಟ್ಟುವ ಮೊದಲು ಸಾರಿಗೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡಿ. 807 ಹಿಂದೆ ಬಿದ್ದು ರುಜುವಾತುಗಳನ್ನು ಬದಲಿಸುವುದು ನಿಜವಾದ ದೋಷವನ್ನು ಅಲ್ಲಿಯೇ ಬಿಡುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಪ್ರಯತ್ನವನ್ನು ಓದಲು ಕಷ್ಟವಾಗಿಸುತ್ತದೆ.

ಎರಡನೇ ಕ್ಲೈಂಟ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಸುರಂಗವನ್ನು ಏಕೆ ಮುರಿಯುತ್ತದೆ

ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸಲು ಪೋರ್ಟ್ಗಳಿಲ್ಲದ ಕಾರಣ NAT ಸಾಧನ ಎರಡು HTTPS ಅಧಿವೇಶನಗಳನ್ನು ಬೇರ್ಪಡಿಸಿದಂತೆ ಎರಡು PPTP ಕ್ಲೈಂಟ್ಗಳನ್ನು ಬೇರ್ಪಡಿಸಲಾರದು. ಆದ್ದರಿಂದ ಅನೇಕ ಗ್ರಾಹಕ ಸಾಧನಗಳು ಒಂದೇ PPTP ಕರೆಯನ್ನು ಅನುಮತಿಸಿ ಅದನ್ನು ಮೂಲ ವಿಳಾಸದಿಂದ ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತವೆ. ಒಂಟಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಲ್ಯಾಪ್ಟಾಪ್ ಎರಡನೇ ಯಂತ್ರ ಡಯಲ್ ಮಾಡಿದ ಕ್ಷಣ ಪೂರ್ಣಗೊಳ್ಳುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಬದಿಯಿಂದ ವೈಫಲ್ಯ ಯದೃಚ್ಛಿಕವಾಗಿ ಕಾಣುತ್ತದೆ. ಈ ಮಾದರಿ ಫರ್ಮ್ವೇರ್ಗೆ ಸೇರಿದ್ದು, ಯಾವುದೇ ಪ್ರೊಫೈಲ್ ಬದಲಾವಣೆ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

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

ಯಾವ ಅರ್ಧ ವಿಫಲವಾಗುತ್ತಿದೆ ಎಂದು ಸಾಬೀತು ಮಾಡಿ

ರೂಟರ್ನಲ್ಲಿ ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು TCP 1723 ತಲುಪುತ್ತಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಆ ಉತ್ತರವೇ ನೀವು ಯಾವ ಅರ್ಧವನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಇವನ್ನು Windows ಕ್ಲೈಂಟ್ನಿಂದ ನಿಮ್ಮದೇ ಸರ್ವರ್ ಹೆಸರಿನ ವಿರುದ್ಧ ಚಲಾಯಿಸಿ. ಮೊದಲನೆಯದು ಪೋರ್ಟ್ ಉತ್ತರಿಸಿತೇ ಎಂದು ಮುದ್ರಿಸುತ್ತದೆ, ಎರಡನೆಯದು ಸಂವಾದವಿಲ್ಲದೆ ಡಯಲ್ ಮಾಡುತ್ತದೆ, ಇದು ಪುನರಾವರ್ತಿತ ಪ್ರಯತ್ನಗಳನ್ನು ಹೋಲಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

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

tcpdump -ni any proto 47

Wireshark ನಲ್ಲಿ ಸಮಾನವಾದದ್ದು ಪ್ರದರ್ಶನ ಫಿಲ್ಟರ್ ip proto 47, ಇದನ್ನು ಆಜ್ಞಾ ಸಾಲಿನಲ್ಲಿ ಆರಾಮವಿಲ್ಲದವರಿಗೆ ನೀಡುವುದು ಸುಲಭ. ಉತ್ತರದಲ್ಲಿ ಏನೂ ಹೊರಹೋಗದೆ GRE ಬಂದರೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಸರಿಪಡಿಸಬೇಕು ಎಂದರ್ಥ.

ದೋಷವನ್ನು ನಿಜವಾಗಿ ಏನು ಸರಿಪಡಿಸುತ್ತದೆ

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

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP ಬದಲಿಸುವುದು ಇನ್ನೊಂದು ಆಯ್ಕೆ ಮತ್ತು ಹಲವು ಬಾರಿ ಅಗ್ಗದ್ದು. VPN ಅನ್ನು ತಾನೇ ಕೊನೆಗೊಳಿಸುವ ರೂಟರ್ ಒಳಬರುವ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಎರಡುಪಟ್ಟು NAT ತಪ್ಪಿಸುತ್ತದೆ, ಮತ್ತು ಪೋರ್ಟ್ ಆಧಾರಿತ NAT ಈಗಾಗಲೇ ನಿರ್ವಹಿಸುವ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಪಾಸ್ಥ್ರೂ ಬೇಕೇ ಇಲ್ಲ: UDP ಮೇಲೆ OpenVPN, TCP 443 ಮೇಲೆ SSTP, ಅಥವಾ ESP ಅನ್ನು UDP 4500 ಒಳಗೆ ಸುತ್ತುವ NAT-T ಜೊತೆ L2TP/IPsec. PPTP MS-CHAPv2 ಅನ್ನು ಅವಲಂಬಿಸಿದೆ, ಅದರ ದಾಖಲಿತ ದೌರ್ಬಲ್ಯಗಳು ದೋಷ ನಿವಾರಣೆಯಾದ ನಂತರವೂ ಹೊಸ ನಿಯೋಜನೆಗೆ ಕೆಟ್ಟ ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ.

ಯಾವ ನಿಯಮ ವ್ಯತ್ಯಾಸ ಮಾಡಿತು ಎಂದು ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಎರಡನೇ ಬಳಕೆದಾರ ಪ್ರವೇಶ ಕೇಳಿದಾಗ ಅದೇ ಸೈಟ್ ಅದೇ ಮಿತಿಯನ್ನು ಎದುರಿಸುತ್ತದೆ. ಪ್ರೋಟೋಕಾಲ್ ಮಟ್ಟದ ಪರಿಹಾರ ನೆಟ್ವರ್ಕ್ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿರಬೇಕು, ಮುಂದಿನ ಇಂಜಿನಿಯರ್ ಅಲ್ಲಿಯೇ ನೋಡುತ್ತಾನೆ.