ಪುಟಗಳು ಲೋಡ್ ಆಗುತ್ತವೆ ಆದರೆ VPN ನಲ್ಲಿ ಅಪ್ಲೋಡ್ಗಳು ನಿಲ್ಲುತ್ತವೆ: ಯಾವ ಕಾರಣ ಗೆಲ್ಲುತ್ತದೆ
ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿದ ನಿಲ್ಲುವಿಕೆ ಮಾರ್ಗ MTU ದೋಷಕ್ಕೆ ಹೊಂದುತ್ತದೆ, ಜೊತೆಗೆ DNS, ಅಪ್ಲಿಕೇಶನ್ ಮಿತಿ ಅಥವಾ ಅಸ್ಥಿರ ಸುರಂಗಕ್ಕೂ ಹೊಂದುತ್ತದೆ. ನಾಲ್ಕು ಅವಲೋಕನಗಳು ಯಾವುದೆಂದು ನಿರ್ಧರಿಸುತ್ತವೆ.
ಪುಟಗಳು ಲೋಡ್ ಆಗುತ್ತವೆ, VPN ಸಂಪರ್ಕವಿದೆ ಎಂದು ತಿಳಿಸುತ್ತದೆ, ಮತ್ತು ಫೈಲ್ ಅಪ್ಲೋಡ್ ಪ್ರತಿ ಬಾರಿ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ಹೆಪ್ಪುಗಟ್ಟುತ್ತದೆ. ಈ ವಿವರಣೆಗೆ ನಾಲ್ಕು ವಿವರಣೆಗಳು ಹೊಂದುತ್ತವೆ: ಪ್ಯಾಕೆಟ್ ಗಾತ್ರದ ಸಮಸ್ಯೆ, ಹೆಸರು ಪರಿಹಾರದ ಸಮಸ್ಯೆ, ಅಪ್ಲಿಕೇಶನ್ ಮಿತಿ ಮತ್ತು ಪದೇ ಪದೇ ಮರುಹೊಂದಿಸುವ ಸುರಂಗ. ಪ್ರತಿಯೊಂದನ್ನು ಬೇರೆ ಅವಲೋಕನದಿಂದ ದೃಢೀಕರಿಸಬಹುದು ಅಥವಾ ತಳ್ಳಿಹಾಕಬಹುದು, ಆದ್ದರಿಂದ ನಿರ್ಧಾರವು ಕಾರಣವನ್ನು ಊಹಿಸುವುದಲ್ಲ, ಸರಿಯಾದ ಪರೀಕ್ಷೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು.
ನಾಲ್ಕು ಅಭ್ಯರ್ಥಿಗಳು ಮತ್ತು ಒಂದು ಆಕಾರ
ವೈಫಲ್ಯದ ಆಕಾರದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಯಾವುದೇ ಉಪಕರಣ ತೆರೆಯುವ ಮೊದಲೇ ಅದು ಪಟ್ಟಿಯ ಹೆಚ್ಚಿನ ಭಾಗವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಸ್ಥಿರ ಗಾತ್ರದಲ್ಲಿ ಸಂಭವಿಸುವ ನಿಲ್ಲುವಿಕೆ ವಿರುದ್ಧವಾಗಿ ಸಾಬೀತಾಗುವವರೆಗೆ ಗಾತ್ರದ ಸಮಸ್ಯೆ. ಯಾದೃಚ್ಛಿಕ ಸ್ಥಳಗಳಲ್ಲಿ ಸಂಭವಿಸುವ ನಿಲ್ಲುವಿಕೆ ನಷ್ಟ ಅಥವಾ ಸ್ಥಿರತೆಯ ಸಮಸ್ಯೆ. ಸಂಪರ್ಕ ತೆರೆಯುವ ಮೊದಲಿನ ವೈಫಲ್ಯ ಹೆಸರಿನ ಸಮಸ್ಯೆ.
ನಾಲ್ಕನೇ ಅಭ್ಯರ್ಥಿ ಅಪ್ಲಿಕೇಶನ್. ಅಪ್ಲೋಡ್ ಮಿತಿಗಳು, ವಿನಂತಿಗಳ ಕಾಲಮಿತಿಗಳು ಮತ್ತು ಪ್ರಾಕ್ಸಿಯ ದೇಹ-ಗಾತ್ರದ ಮೇಲ್ಮಿತಿಗಳು ಬ್ರೌಸರ್ನಿಂದ ನೆಟ್ವರ್ಕ್ ದೋಷದಂತೆ ಕಾಣುವ ವೈಫಲ್ಯಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ, ಮತ್ತು ಅವು ಸಾಮಾನ್ಯವಾಗಿ ನಿಲ್ಲುವಿಕೆಯ ಬದಲು ನಿರಾಕರಣೆಯಾಗಿ ಬರುತ್ತವೆ.
ಏನನ್ನಾದರೂ ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ಕಂಡ ಆಕಾರವನ್ನು ಬರೆದಿಡಿ. "ಸುಮಾರು ಅದೇ ಬೈಟ್ ಸಂಖ್ಯೆಯಲ್ಲಿ, ಪ್ರತಿ ಬಾರಿ, ಸುರಂಗ ಮೇಲಿರುವಾಗ ನಿಲ್ಲುತ್ತದೆ" ಎಂಬುದು "ಅಪ್ಲೋಡ್ಗಳು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ" ಎಂಬುದಕ್ಕಿಂತ ಬಹಳ ಬಲವಾದ ಆರಂಭಿಕ ಬಿಂದು.
ನಂತರ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಮಾರ್ಗವನ್ನು ಸ್ಥಿರವಾಗಿಡಿ. ನಿರ್ಗಮನ, ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಸರ್ವರ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ಬದಲಾಯಿಸುವುದು ಅವುಗಳಲ್ಲಿ ಯಾವುದಕ್ಕೂ ಆರೋಪಿಸಲಾಗದ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆ. ಪ್ರತಿ ಓಟಕ್ಕೆ ಒಂದು ಚರ, ಮತ್ತು ಅದನ್ನು ಬರೆದಿಡಿ.
ನೀತಿಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಗಾತ್ರವನ್ನು ಅರ್ಧಿಸಿ
ಅಗ್ಗದ ಭೇದಕ ಒಂದು ಸಂಖ್ಯೆಯನ್ನು ಬದಲಿಸುವ ಪ್ರೋಬ್. ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಹೆಚ್ಚುತ್ತಿರುವ ಗಾತ್ರದ, ತುಂಡಾಗದಂತೆ ನಿಷೇಧಿಸಿದ ಪಿಂಗ್ಗಳನ್ನು ಕಳುಹಿಸಿ, ನೀವು ನಿಯಂತ್ರಿಸುವ ಫೈಲ್ ಅನ್ನು ಅದೇ ಸೇವೆಗೆ ಅಪ್ಲೋಡ್ ಮಾಡಿ, ನಂತರ ಪ್ರತಿಯೊಂದು ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಎಂದು ಹೋಲಿಸಿ.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadಮೊದಲ ಆಜ್ಞೆ ಪೂರ್ಣ ಗಾತ್ರದ ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗವನ್ನು ದಾಟುತ್ತದೆಯೇ ಎಂದು ತಿಳಿಸುತ್ತದೆ. 1500 ಬೈಟ್ MTU ನಲ್ಲಿ ತುಂಡಾಗದ ಅತಿದೊಡ್ಡ ICMP ಪೇಲೋಡ್ 1472 ಬೈಟ್, ಮತ್ತು ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ ಸುರಂಗ ಆ ಬಜೆಟ್ನಿಂದ ಇನ್ನಷ್ಟು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಎರಡನೆಯದು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ವರ್ಗಾವಣೆಗೆ ಗಾತ್ರ ಮತ್ತು ಅವಧಿಯನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ನಿಜವಾಗಿ ಮುಖ್ಯವಾದ ಸಂಖ್ಯೆ ಅದೇ.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ಓದಿ. ಮಿತಿಯ ಮೇಲೆ ವಿಫಲವಾಗುವ ಪ್ರೋಬ್ಗಳು ಮತ್ತು ಅದೇ ಮಿತಿಯ ಹತ್ತಿರ ನಿಲ್ಲುವ ಅಪ್ಲೋಡ್ ಸುಸಂಗತ ಕಥೆ. ಎಲ್ಲಾ ಪ್ರೋಬ್ಗಳು ಯಶಸ್ವಿಯಾದರೂ ಅಪ್ಲೋಡ್ ಮಾರ್ಗ ಸ್ಪಷ್ಟವಾಗಿ ಸಾಗಿಸುವ ಬೈಟ್ ಸಂಖ್ಯೆಯಲ್ಲಿ ನಿಲ್ಲುತ್ತಿದ್ದರೆ, ಅದು ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಸರ್ವರ್ ಕಡೆಗೆ ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು MTU ಯ ಎಷ್ಟೇ ಕೆಲಸವೂ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಆ ಋಣಾತ್ಮಕ ಫಲಿತಾಂಶ ಧನಾತ್ಮಕದಷ್ಟೇ ಮೌಲ್ಯದ್ದು. ಅದು ತನಿಖೆಯ ಅತ್ಯಂತ ದುಬಾರಿ ಶಾಖೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ನಂತರ ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಸ್ಥಿರತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ದೊಡ್ಡ ಅಪ್ಲೋಡ್ ಮಧ್ಯದಲ್ಲಿ ಕೀಲಿಯನ್ನು ನವೀಕರಿಸುವ ಸುರಂಗವು ಗಾತ್ರ-ಅವಲಂಬಿತವೆಂದು ತೋರುವ, ಆದರೆ ಅಲ್ಲದ ವೈಫಲ್ಯವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಅಪ್ಟೈಮ್ ಓದುವಿಕೆ ಅದನ್ನು ದೃಢೀಕರಿಸುವ ಅಗ್ಗದ ದಾರಿ.
ಸರಿಪಡಿಸುವಿಕೆ ಮತ್ತು ಪರ್ಯಾಯದ ನಡುವೆ ಆಯ್ಕೆಮಾಡಿ
ಸಾಕ್ಷ್ಯಗಳು ಗಾತ್ರದ ಕಡೆಗೆ ಸೂಚಿಸಿದರೆ, ಎರಡು ಪ್ರಾಮಾಣಿಕ ಉತ್ತರಗಳು ಮತ್ತು ಒಂದು ಅಪ್ರಾಮಾಣಿಕ ಉತ್ತರವಿದೆ. ಪ್ರಾಮಾಣಿಕವಾದವು: ಅಗತ್ಯವಾದ ICMP ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಅನುಮತಿಸಿ ಮಾರ್ಗ-MTU ಅನ್ವೇಷಣೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸುವುದು, ಅಥವಾ ಘೋಷಿತ ಸೆಗ್ಮೆಂಟ್ ಗಾತ್ರವನ್ನು ಮಿತಿಗೊಳಿಸಿ ಸಹಚರರು ಚಿಕ್ಕ ಸೆಗ್ಮೆಂಟ್ಗಳನ್ನು ಕಳುಹಿಸುವಂತೆ ಮಾಡುವುದು. ಅಪ್ರಾಮಾಣಿಕವಾದದ್ದು ಇಂಟರ್ಫೇಸ್ MTU ಅನ್ನು ಫೋರಂನಿಂದ ನಕಲಿಸಿದ ಮೌಲ್ಯಕ್ಕೆ ಇಳಿಸಿ ಅದು ಏನನ್ನು ಬದಲಿಸಿತು ಎಂದು ಎಂದಿಗೂ ಪರಿಶೀಲಿಸದಿರುವುದು.
ಆಯ್ಕೆ ನೀವು ಏನನ್ನು ನಿಯಂತ್ರಿಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ. ನೀವು ನಡೆಸುವ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ICMP ಸಂದೇಶಗಳನ್ನು ಅನುಮತಿಸುವುದು ಸ್ವಚ್ಛ ಸರಿಪಡಿಸುವಿಕೆ, ಏಕೆಂದರೆ ಅದು ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್ಗೂ ಕಾರ್ಯವಿಧಾನವನ್ನು ಕಾರ್ಯನಿರ್ವಹಿಸುವಂತೆ ಇಡುತ್ತದೆ. ನೀವು ನಿಯಂತ್ರಿಸದ ಮಾರ್ಗದಲ್ಲಿ ಮಿತಿಗೊಳಿಸುವುದು ಪ್ರಾಯೋಗಿಕ ಆಯ್ಕೆ, ಮತ್ತು ಅದನ್ನು ಇಡೀ ಸರ್ವರ್ಗೆ ಅಲ್ಲ, ಸಂಕುಚಿತವಾಗಿ ಅನ್ವಯಿಸಬೇಕು.
ಸಾಕ್ಷ್ಯಗಳು ಅಪ್ಲಿಕೇಶನ್ ಕಡೆಗೆ ಸೂಚಿಸಿದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಅದರ ಪ್ರಾಕ್ಸಿ ಸಂರಚನೆಯನ್ನು ಸರಿಪಡಿಸಿ. 413 ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ನೇತಾಡುವ ಸಂಪರ್ಕ ಬೇರೆ ಬೇರೆ ವೈಫಲ್ಯಗಳು, ಮತ್ತು ಎರಡನೆಯದು ಸಾಮಾನ್ಯವಾಗಿ ತನ್ನದೇ ಮಿತಿಗಳಿರುವ ಪ್ರಾಕ್ಸಿ ಒಳಗೊಂಡ ಸರಪಳಿಯಲ್ಲಿ ಎಲ್ಲೋ ಕಾಲಮಿತಿ.
ಹೇಗಾದರೂ, ಮೂಲ ಮೌಲ್ಯಗಳನ್ನು ಇಟ್ಟುಕೊಂಡು ಹಿಂತಿರುಗಿಸಿದ ನಂತರ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ. ಯಶಸ್ವಿ ವರ್ಗಾವಣೆಯೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಬದಲಾವಣೆ ಅದೇ ಕಾರಣ ಎಂಬ ಸಾಕ್ಷ್ಯವಲ್ಲ, ಮತ್ತು ಹಿಂತಿರುಗಿಸುವ ಸಾಮರ್ಥ್ಯವೇ ನಿದಾನವನ್ನು ಕಾಕತಾಳೀಯದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ.
ನಿರ್ಧಾರವನ್ನು ದಾಖಲಿಸಿ ಅದು ಮುಂದಿನ ಘಟನೆಯವರೆಗೂ ಉಳಿಯುವಂತೆ
ನಾಲ್ಕು ಸಂಗತಿಗಳು ಸಾಕು: ಕಂಡ ವೈಫಲ್ಯದ ಆಕಾರ, ಪ್ರೋಬ್ಗಳ ಫಲಿತಾಂಶಗಳು, ನೀವು ಮಾಡಿದ ಬದಲಾವಣೆ ಮತ್ತು ಮರುಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶ. ಅವುಗಳಿಂದ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಸಮಸ್ಯೆ ಅದೇನಾ ಅಥವಾ ಅದೇ ಲಕ್ಷಣದ ಹೊಸದು ಎಂದು ಹೇಳಬಹುದು.
ಮಾರ್ಗದ ಸಂದರ್ಭವನ್ನೂ ಗಮನಿಸಿ, ಏಕೆಂದರೆ MTU ಸಂಬಂಧಿತ ಕಂಡುಹಿಡಿಯುವಿಕೆ ನಿರ್ದಿಷ್ಟ ಕೊಂಡಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಮನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಹೋಟೆಲ್ನಲ್ಲಿ ವಿಫಲವಾಗುವ ಲ್ಯಾಪ್ಟಾಪ್ಗೆ ಎರಡು ಮಾರ್ಗಗಳಿವೆ, ಮತ್ತು ಒಂದರ ಮೇಲೆ ಅನ್ವಯಿಸಿದ ಸರಿಪಡಿಸುವಿಕೆ ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಕೊನೆಯದಾಗಿ, "VPN ಅಪ್ಲೋಡ್ಗಳನ್ನು ಮುರಿಯಿತು" ಎಂಬ ಸಾರಾಂಶವನ್ನು ವಿರೋಧಿಸಿ. ಸುರಂಗ ಕೆಲಸ ಮಾಡಿದ ಮತ್ತು ವಿಫಲವಾದ ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇತ್ತು; ಬದಲಾದದ್ದು ಮಾರ್ಗವು ಸಾಗಿಸಬೇಕಿದ್ದ ಪ್ಯಾಕೆಟ್ನ ಗಾತ್ರ, ಅಥವಾ ವರ್ಗಾವಣೆ ನಿಲ್ಲಿಸಿದ ಸ್ಥಳ. ನಿಜವಾದ ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೆಸರಿಸುವುದೇ ಟಿಪ್ಪಣಿಯನ್ನು ಉಪಯುಕ್ತವಾಗಿಸುತ್ತದೆ.