TCP ಮರುಹೊಂದಿಸುವಿಕೆ ನಿಮ್ಮ VPN ನಿರ್ಬಂಧಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ

ಕ್ಲೈಂಟ್ ಲಾಗ್ನಲ್ಲಿ “ಸಂಪರ್ಕ ಮರುಹೊಂದಿಸಲಾಗಿದೆ, ಮರುಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ” ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ತೀರ್ಮಾನವು ಸಾಕ್ಷ್ಯಕ್ಕಿಂತ ಮೊದಲೇ ಬರುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ VPN ಅನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತಿದೆ, ಅಥವಾ ಪ್ರಮಾಣಪತ್ರ ತಪ್ಪಾಗಿದೆ, ಅಥವಾ ನಿರ್ದಿಷ್ಟ ದೇಶವು ಹಸ್ತಕ್ಷೇಪ ಮಾಡುತ್ತಿದೆ ಎಂದು ಯಾರೋ ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಮರುಹೊಂದಿಸುವಿಕೆ ಎಂಬುದು ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸುವ TCP ಪ್ಯಾಕೆಟ್, ಮತ್ತು ಲಾಗ್ ಸಾಲು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಒಂದನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಎಂದು ದಾಖಲಿಸುತ್ತದೆ. ಅದು ಕಳುಹಿಸಿದ ಸಾಧನವನ್ನಾಗಲೀ ಕಾರಣವನ್ನಾಗಲೀ ಹೆಸರಿಸುವುದಿಲ್ಲ.

ಮರುಹೊಂದಿಸುವಿಕೆ ಪ್ಯಾಕೆಟ್, ತೀರ್ಪಲ್ಲ

TCP ಮರುಹೊಂದಿಸುವಿಕೆಯ ಸಂಸ್ಕರಣೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ: RST ಧ್ವಜವಿರುವ ಸೆಗ್ಮೆಂಟ್ ಸಂಪರ್ಕವನ್ನು ತಕ್ಷಣ ಕೊನೆಗೊಳಿಸುತ್ತದೆ. ಸ್ವೀಕರಿಸುವವರು ಮಾತುಕತೆ ನಡೆಸುವುದಿಲ್ಲ, ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ ಮತ್ತು ಏಕೆ ಎಂದು ಕೇಳುವುದಿಲ್ಲ. ಅದು ಮರುಹೊಂದಿಸುವಿಕೆಯನ್ನು ವರದಿ ಮಾಡಿ ಮುಂದೆ ಸಾಗುತ್ತದೆ.

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

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

ಯಾವ ಸಂಪರ್ಕ ಮರುಹೊಂದಿಸಲ್ಪಟ್ಟಿತು ಎಂದು ಖಚಿತಪಡಿಸಿ

ಮೊದಲು ಸಕ್ರಿಯ ಪ್ರೊಫೈಲ್ ನಿಜವಾಗಿಯೂ TCP ಬಳಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. UDP ಸುರಂಗದಲ್ಲಿ ಮರುಹೊಂದಿಸುವಿಕೆಗೆ ಅರ್ಥವಿಲ್ಲ, ಮತ್ತು HTTP ಪ್ರಾಕ್ಸಿಯ ಲಾಗ್ VPN ಗಿಂತ ಬೇರೆ TCP ಭಾಗಕ್ಕೆ ಸಂಬಂಧಿಸಿರಬಹುದು.

ಗಮ್ಯಸ್ಥಾನ, ಪೋರ್ಟ್, ಪ್ರಯತ್ನದ ಸಮಯ ಮತ್ತು ಕ್ಲೈಂಟ್ ತಲುಪಿದ ಹಂತವನ್ನು ದಾಖಲಿಸಿ.

ಹಂತವೇ ಅತ್ಯಂತ ಉಪಯುಕ್ತ ಕ್ಷೇತ್ರ. TLS ಹ್ಯಾಂಡ್ಶೇಕ್ ಸಮಯದಲ್ಲಿ ಮರುಹೊಂದಿಸುವಿಕೆ ಒಂದು ಗುಂಪಿನ ಶಂಕಿತರನ್ನು ಸೂಚಿಸುತ್ತದೆ; ದೃಢೀಕರಣದ ನಂತರದ ಮರುಹೊಂದಿಸುವಿಕೆ ಇನ್ನೊಂದನ್ನು. ಹಂತವಿಲ್ಲದೆ ಪ್ರತಿ ಸಿದ್ಧಾಂತವೂ ಹೊಂದುತ್ತದೆ.

ಮಾರ್ಗದ ಎರಡೂ ತುದಿಗಳನ್ನು ಹೋಲಿಸಿ

ನೀವು ಸರ್ವರ್ ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಅದೇ ಪ್ರಯತ್ನಕ್ಕೆ ಅದರ ಘಟನೆಗಳನ್ನು ಹೋಲಿಸಿ. ಅದು ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸಿತೇ? ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮುಚ್ಚಿತೇ? ಒಂದು ಪ್ರತಿಕ್ರಿಯೆ ಒಂದು ಗಡಿಯನ್ನು ಬಿಟ್ಟು ಮುಂದಿನದನ್ನು ತಲುಪಲಿಲ್ಲವೇ?

ಸಾಧ್ಯವಾದರೆ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಎರಡರಲ್ಲೂ ಕ್ಯಾಪ್ಚರ್ ಮಾಡಿ. ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಕಾಣಿಸಿ ಸರ್ವರ್ನಲ್ಲಿ ಕಾಣದ ಮರುಹೊಂದಿಸುವಿಕೆ ಸರ್ವರ್ನಲ್ಲಿ ಹುಟ್ಟಿಲ್ಲ.

ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ RST ಸೆಗ್ಮೆಂಟ್ಗಳನ್ನು ಗಮನಿಸಿ:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

ನಿಯಂತ್ರಿತ ಹೋಲಿಕೆಯಿಂದ ಸಂಕುಚಿಸಿ

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

ಇದು ಇನ್ನೂ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಧ್ಯವರ್ತಿ ಸಾಧನವನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ. ಇದು ವ್ಯಾಪ್ತಿಯನ್ನು ಒಂದು ಮಾರ್ಗಕ್ಕೆ ಸಂಕುಚಿಸುತ್ತದೆ, ಅದು ಉಪಯುಕ್ತ ಮತ್ತು ಪ್ರಾಮಾಣಿಕ ಫಲಿತಾಂಶ.

“ಈ ಮಾರ್ಗ ವಿಫಲವಾಗುತ್ತದೆ” ಮತ್ತು “ಈ ಹೆಸರಿಸಿದ ಪಾತ್ರಧಾರಿ ಅದನ್ನು ಉಂಟುಮಾಡಿತು” ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ. ಮೊದಲನೆಯದು ಪರೀಕ್ಷಿಸಬಹುದಾದದ್ದು; ಎರಡನೆಯದು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಕ್ಲೈಂಟ್ನಿಂದ ಅಲ್ಲ.

ನಂಬಿಕೆ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬದಲಿಸದೆ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

TLS ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ, ರುಜುವಾತುಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಬೇಡಿ ಮತ್ತು ಒಂದು ಮರುಹೊಂದಿಸುವಿಕೆ ಸಾಲಿನ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಬಂಧ ನೀತಿಯನ್ನು ಘೋಷಿಸಬೇಡಿ. ಈ ಪ್ರತಿಯೊಂದು ಬದಲಾವಣೆಯೂ ಪರೀಕ್ಷೆಯಲ್ಲಿರುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಬದಲಿಸಿ ಮುಂದಿನ ಹೋಲಿಕೆಯನ್ನು ಅರ್ಥಹೀನಗೊಳಿಸುತ್ತದೆ.

ಗುರುತಿಸಲಾದ ಘಟಕವನ್ನು ಅದರ ಮಾಲೀಕರ ಮೂಲಕ ಸರಿಪಡಿಸಿ, ನಂತರ ಅದೇ ಪ್ರೊಫೈಲ್ ಮತ್ತು ಅದೇ ವೀಕ್ಷಣೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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