ಕೆಲವು ವೆಬ್ಸೈಟ್ಗಳು VPN ಆನ್ ಇದ್ದಾಗ ಮಾತ್ರ ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ?

ಒಂದು ಸೈಟ್ ವಿಫಲವಾಗುತ್ತಿರುವಾಗ ಉಳಿದೆಲ್ಲವೂ ಲೋಡ್ ಆಗುವುದು ಟನೆಲ್ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುತ್ತಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಇದು ಹಲವರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಸಮಸ್ಯೆಯನ್ನು ಹೆಚ್ಚು ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ. ಮೂರು ಅವಲೋಕನಗಳು ಉಳಿದದ್ದನ್ನು ಜೋಡಿಸುತ್ತವೆ: ನಿಮಗೆ HTTP ಪ್ರತಿಕ್ರಿಯೆ ಬಂದಿತೇ, ಹೋಸ್ಟ್ನಾಮ್ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಲ್ಪಟ್ಟಿತೇ, ಮತ್ತು ಸಣ್ಣ ವಿನಂತಿಗಳು ದಾಟುತ್ತಿರುವಾಗ ದೊಡ್ಡವು ನಿಲ್ಲುತ್ತಿವೆಯೇ. ಈ ಉತ್ತರಗಳ ಮೊದಲು VPN ಬಗ್ಗೆ ಊಹಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ದೋಷವನ್ನು ತೆಗೆಯುವ ಬದಲು ಸ್ಥಳವನ್ನು ಬದಲಿಸುತ್ತದೆ.

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

ದೋಷ ಸಂದೇಶವೇ ಕೊಂಬೆಯನ್ನು ಆರಿಸಿಕೊಳ್ಳಲಿ

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

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

ಪ್ರತಿಕ್ರಿಯಿಸುವ ಸೈಟ್ ಮುರಿದ ಟನೆಲ್ ಸಾಬೀತುಪಡಿಸಿಲ್ಲ

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

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

ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳು ಮಾತ್ರ ನಿಂತಾಗ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವನ್ನು ನೋಡಿ

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

ಆ ಕಲ್ಪನೆಯನ್ನು ಒಂದು ping ಬದಲು ಗಾತ್ರ ಸ್ಕ್ಯಾನ್ನಿಂದ ಪರೀಕ್ಷಿಸಿ. ಸ್ಥಿರ ಪೇಲೋಡ್ ಗಾತ್ರದಲ್ಲಿ ಆರಂಭವಾಗುವ ವೈಫಲ್ಯ ಬಲವಾದ ಸಾಕ್ಷ್ಯ, ಅಲೆದಾಡುವ ವೈಫಲ್ಯ ಅಲ್ಲ.

ವಿಫಲವಾದ ವಿನಂತಿಯಲ್ಲೇ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಖಚಿತಪಡಿಸಿ

ಮೂಲ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ, ಮುಖಪುಟವನ್ನಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಯಾಶ್ ಮಾಡಿದ ಚಿಪ್ಪು ಚಿತ್ರಿಸಬಹುದು, ಸೈನ್-ಇನ್ ಹಿಂದಿನ API ಕರೆ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತಿರಬಹುದು. ಕೆಳಗಿನ ಆದೇಶಗಳು ಅದೇ ಹೋಸ್ಟ್ನಲ್ಲಿ ಹೆಸರು ವಿಭಜನೆ, ಸಣ್ಣ ವಿನಂತಿ ಮತ್ತು ದೊಡ್ಡ ವಿನಂತಿಯನ್ನು ಬೇರ್ಪಡಿಸುತ್ತವೆ. ಹೋಸ್ಟ್ನಾಮ್ ಮತ್ತು ಮಾರ್ಗವನ್ನು ನಿಜವಾಗಿ ಮುರಿದ ವಿನಂತಿಯ ಮೌಲ್ಯಗಳಿಂದ ಬದಲಿಸಿ.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

dig ನ ಉತ್ತರ ಬ್ರೌಸರ್ ಬಳಸಿದ್ದಕ್ಕಿಂತ ಭಿನ್ನವಾದರೆ, ರಿಸಾಲ್ವರ್ ಬದಲಾಗುವ ಅಂಶ, ಮತ್ತು ಬ್ರೌಸರ್ನ ಸ್ವಂತ DNS ಸೆಟ್ಟಿಂಗೇ ನೋಡಬೇಕಾದ ಜಾಗ. ಸಣ್ಣ ವಿನಂತಿ ಸ್ಥಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತಿರುವಾಗ ದೊಡ್ಡದು ನಿಂತರೆ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರದ ಕೊಂಬೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ. ಎರಡೂ ಸಮಯ ಮುಗಿಸಿದರೆ, ನಿರ್ಗಮನ ಮಾರ್ಗ ಮತ್ತು ಆ ವಿಳಾಸದ ಬಗ್ಗೆ ಸೈಟ್ನ ವರ್ತನೆ ಮತ್ತೆ ಮೇಜಿನ ಮೇಲಿವೆ.

ಮೂಲ ವಿನಂತಿಯನ್ನು ಯಶಸ್ವಿಗೊಳಿಸಿದ ಬದಲಾವಣೆಯನ್ನು ಉಳಿಸಿ ಉಳಿದದ್ದನ್ನು ಹಿಂತಿರುಗಿಸಿ. ಬ್ರೌಸರ್, ರಿಸಾಲ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಒಟ್ಟಿಗೆ ಮಾಡಿದ ಬದಲಾವಣೆಗಳ ರಾಶಿ ಯಾವುದು ಮುಖ್ಯವಾಗಿತ್ತು ಎಂದು ಹೇಳಲಾಗದಂತೆ ಮಾಡುತ್ತದೆ.