PPTP ವಿಭಜಿತ ಟನೆಲಿಂಗ್ ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ: ಮೊದಲು GRE ಮಾರ್ಗ ಸರಿಪಡಿಸಿ

PPTP ಸಂಪರ್ಕ ಮೇಲಕ್ಕೆ ಬರುವುದನ್ನು ನೋಡಿ ಮತ್ತು ಕಷ್ಟದ ಭಾಗ ಮುಗಿದಿದೆ ಎಂದು ನಂಬುವುದು ಸುಲಭ: ಕ್ಲೈಂಟ್ ದೃಢೀಕರಣ ಮಾಡುತ್ತದೆ, ppp0 ಅಡಾಪ್ಟರ್ ಅಥವಾ WAN Miniport ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಸ್ಥಿತಿ ವಿಂಡೋ ಹಸಿರಾಗುತ್ತದೆ. ನಂತರ ಒಳ ಹೋಸ್ಟ್‌ಗೆ ಮೊದಲ ವಿನಂತಿ ಸಮಯ ಮೀರಿ ಹೋಗುತ್ತದೆ, ಮತ್ತು ಪ್ರೊಫೈಲ್‌ಗೆ ದೋಷ ಹೇರಲಾಗುತ್ತದೆ. ವಾಸ್ತವದಲ್ಲಿ ಎರಡು ಸ್ವತಂತ್ರ ಪದರಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಬೇಕು: TCP 1723 ಮತ್ತು GRE ಒಯ್ಯುವ ಹೊರ ಸಾಗಣೆ, ಮತ್ತು ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳು PPP ಇಂಟರ್ಫೇಸ್ ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಒಳ ನೀತಿ. ಹಸಿರು ಸ್ಥಿತಿ ಮೊದಲ ಪದರ ಮಾತುಕತೆ ನಡೆಸಿದುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಎರಡನೆಯದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಪ್ರೊಫೈಲ್‌ನಿಂದ ನಿಯಂತ್ರಣ ಸಾಕೆಟ್‌ವರೆಗೆ ಕ್ಲೈಂಟ್ ಅನ್ನು ಅನುಸರಿಸಿ

ಕ್ಲೈಂಟ್ ಲಾಗ್ ತೆರೆದು ಅದು ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುವ ಬಿಂದುವನ್ನು ಹುಡುಕಿ. PPTP ಮೊದಲು ಪೋರ್ಟ್ 1723 ಗೆ TCP ಸಂಪರ್ಕ ತೆರೆದು ಆ ಚಾನೆಲ್ ಮೂಲಕ ಟನೆಲ್ ನಿಯತಾಂಕಗಳನ್ನು ಮಾತುಕತೆ ಮಾಡುತ್ತದೆ. ಈ ಹೆಜ್ಜೆ ವಿಫಲವಾದರೆ ಮುಂದಿನ ಯಾವುದೂ ಮುಖ್ಯವಲ್ಲ, ಮತ್ತು ದೋಷ ಸಾಮಾನ್ಯವಾಗಿ ಸರ್ವರ್ ವಿಳಾಸ ಅಥವಾ ಸಮಯ ಮಿತಿಯನ್ನು ಹೆಸರಿಸುತ್ತದೆ.

ಯಾವುದೇ ಮಾರ್ಗವನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ತಂತಿಯ ಮೇಲೆ ನಿಯಂತ್ರಣ ಸಂಪರ್ಕವನ್ನು ದೃಢೀಕರಿಸಿ. ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಅಥವಾ ಕನ್ನಡಿ ಪೋರ್ಟ್‌ನಲ್ಲಿ, ಒಂದು ಸಂಪರ್ಕ ಪ್ರಯತ್ನಕ್ಕಾಗಿ TCP 1723 ಸೆರೆಹಿಡಿಯಿರಿ:

sudo tcpdump -ni any 'tcp port 1723' -c 20

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

GRE ಎರಡನೇ ಪ್ರೋಟೋಕಾಲ್, ಪೋರ್ಟ್ ಅಲ್ಲ

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

ಅದೇ ಸೆರೆಹಿಡಿಯುವಿಕೆಯಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ 47 ಅನ್ನು ಗಮನಿಸಿ, ನಂತರ ಹೊರಹೋಗುವುದನ್ನು ಹಿಂತಿರುಗುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ:

sudo tcpdump -ni any 'proto gre' -c 20

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

ಟನೆಲ್ ಒಂದು ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ

GRE ಹರಿಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, PPP ಮಾತುಕತೆ ಕ್ಲೈಂಟ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ವಿಳಾಸ ನಿಗದಿಪಡಿಸುತ್ತದೆ. ಊಹಿಸುವ ಬದಲು ನಿಗದಿಯನ್ನು ಓದಿ:

ip -4 addr show ppp0

ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಕೊಂಡಿಯ ಗಮ್ಯಸ್ಥಾನವಾಗಿ ತೋರಿಸಿದ ಪೀರ್ ವಿಳಾಸಕ್ಕೆ ಪಿಂಗ್ ಮಾಡಿ. ಈ ಹಂತದಲ್ಲಿ ಉತ್ತರ ಬಂದರೆ ಸುತ್ತುವರಿದ ಮಾರ್ಗ ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ ಟನೆಲ್ ಒಳಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತಾಗುತ್ತದೆ. ಪೀರ್ ಉತ್ತರಿಸಿ ಒಳ ಹೋಸ್ಟ್‌ಗಳು ಉತ್ತರಿಸದಿದ್ದರೆ, ಹೊರ ಸಾಗಣೆ ಸರಿಯಾಗಿದೆ ಮತ್ತು ವೈಫಲ್ಯ ಒಳಗೆ ಸರಿದಿದೆ.

ಯಾವುದೇ ವಿಭಜಿತ ಮಾರ್ಗ ಸೇರಿಸುವ ಮೊದಲು ಇದನ್ನು ಮಾಡಿ. ಸಾಗಣೆ ಮುರಿದಿರುವಾಗ ಮಾಡಿದ ಮಾರ್ಗ ಬದಲಾವಣೆ ಎರಡನೇ ಚರಾಕ್ಷರವನ್ನು ಸೃಷ್ಟಿಸಿ ಮೊದಲನೆಯದನ್ನು ಮರೆಮಾಡುತ್ತದೆ.

ವಿಭಜಿತ ನೀತಿ ಬರೆಯಿರಿ, DNS ಸೇರಿದಂತೆ

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

ಪ್ರತಿ ವರ್ಗದಲ್ಲಿ ಒಂದು ವಿಳಾಸಕ್ಕೆ ಕರ್ನೆಲ್ ತೆಗೆದುಕೊಳ್ಳುವ ನಿರ್ಧಾರವನ್ನು ಪರಿಶೀಲಿಸಿ:

ip route get 10.20.5.10
ip route get 203.0.113.25

ಮೊದಲನೆಯದು ppp0, ಎರಡನೆಯದು ಸಾಮಾನ್ಯ ಗೇಟ್‌ವೇ ಎಂದು ಹೆಸರಿಸಬೇಕು. ಎರಡೂ ಒಂದೇ ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿಸಿದರೆ, ನೀತಿ ಸ್ವಲ್ಪವೂ ವಿಭಜಿತವಾಗಿಲ್ಲ. DNS ಸರ್ವರ್‌ನ ಸ್ವಂತ ವಿಳಾಸವನ್ನು ಟನೆಲ್ ಪಟ್ಟಿಗೆ ಸೇರಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಒಳ ಹೋಸ್ಟ್‌ಗಳಿಗೆ ಹೆಸರಿನ ಪರಿಹಾರ ಸ್ಥಳೀಯ ಪರಿಹಾರಕದ ಮೂಲಕ ಹೊರಹೋಗಿ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಹಿಂತಿರುಗಿಸುವುದಿಲ್ಲ.

ಐದು ಹಂತಗಳಲ್ಲಿ ಪುನರಾವರ್ತಿಸಬಹುದಾದ ಪರಿಶೀಲನೆ

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

Linux ಕ್ಲೈಂಟ್‌ಗಾಗಿ ಸಂಕ್ಷಿಪ್ತ ಆವೃತ್ತಿ ಹೀಗೆ ಕಾಣುತ್ತದೆ:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Windows ನಲ್ಲಿ ಅದೇ ಕ್ರಮ route print ಮತ್ತು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ತೋರಿಸಿದ ಅಡಾಪ್ಟರ್ ಸ್ಥಿತಿಯೊಂದಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. PPTP ಹಳೆಯ ಪ್ರೋಟೋಕಾಲ್, ಮತ್ತು ಸರ್ವರ್ SSTP ಅಥವಾ IKEv2 ನೀಡಿದರೆ, ಪ್ರತಿ ಹಾಪ್‌ನಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ 47 ದಾಟುವುದನ್ನು ಅವಲಂಬಿಸಿರುವ ಮಾರ್ಗವನ್ನು ಟ್ಯೂನ್ ಮಾಡುವುದಕ್ಕಿಂತ ಸ್ಥಳಾಂತರಗೊಳ್ಳುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಸಮಯದ ಉತ್ತಮ ಬಳಕೆ. ಹಳೆಯ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಹೊಸ ಆವೃತ್ತಿಗೆ ನಕಲಿಸುವ ಬದಲು ಬದಲಿಯ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ದೃಢೀಕರಣ ಒಪ್ಪಂದವನ್ನು ಪರಿಶೀಲಿಸಿ.