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

ವಿಫಲವಾಗುವ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿ, ನಂತರ ಬ್ರೌಸರ್ ಬದಲು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ನೋಡಿ.

ಸೈಟ್‌ನ ಹೆಸರಲ್ಲ, ವಿಳಾಸವನ್ನು ಹೋಲಿಸಿ

ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಪ್ರಯತ್ನಿಸಿದ ವಿಳಾಸವನ್ನು ಹುಡುಕಿ, ನಂತರ ಯಾವ ಮಾರ್ಗವು ಅದಕ್ಕೆ ಹೊಂದುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. 45.61.20.10 ಒಳಗಿನ ಗಮ್ಯಸ್ಥಾನವು 45.0.0.0/8 ಅಡಿಯಲ್ಲಿ ಬರುತ್ತದೆ, ಆ ಪ್ರಿಫಿಕ್ಸ್ ಇದ್ದರೆ, ಸೈಟ್‌ಗೆ ಸುರಂಗದೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲದಿದ್ದರೂ. ವಿಫಲವಾದ ವಿಳಾಸವನ್ನು ಸ್ಥಾಪಿತ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಸುವುದು ಕಳೆಯುವ ಸಮಸ್ಯೆ, ಊಹೆಯಲ್ಲ.

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

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

ಅತ್ಯಂತ ನಿರ್ದಿಷ್ಟ ಹೊಂದಿಕೆಯ ಪ್ರಿಫಿಕ್ಸ್ ಓದಿ, ಪರಿಚಿತವೆನಿಸುವ ಮೊದಲ ಸಾಲಲ್ಲ. ಕೋಷ್ಟಕದಲ್ಲಿರುವ ಮಾರ್ಗವು ಹುಡುಕಾಟವನ್ನು ಗೆದ್ದಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ; ಉದ್ದವಾದ ಹೊಂದಾಣಿಕೆ ಅದನ್ನು ಮಾಡುತ್ತದೆ. ಎರಡು ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಒಂದು ವಿಳಾಸಕ್ಕೆ ಹೊಂದಬಹುದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಪ್ಯಾಕೆಟ್ ಪಡೆಯುತ್ತದೆ. ಸೋತವನು ಕೋಷ್ಟಕದಲ್ಲಿ ಉಳಿಯುತ್ತಾನೆ ಮತ್ತು ಪಟ್ಟಿಯಲ್ಲಿ ಸಮಾನವಾಗಿ ನಿಜವೆನಿಸುತ್ತಾನೆ.

ಪ್ರಿಫಿಕ್ಸ್, ಅದರ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಪರಿಹರಿಸಿದ ವಿಳಾಸವನ್ನು ಬರೆಯಿರಿ. ಆ ಮೂರು ಮೌಲ್ಯಗಳೇ ಸಂಪೂರ್ಣ ನಿದಾನ.

ಮಾರ್ಗವನ್ನು ಯಾರು ಸ್ಥಾಪಿಸಿದರು ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ

ಮಾರ್ಗಗಳು ನಾಲ್ಕು ಸ್ಥಳಗಳಿಂದ ಬರುತ್ತವೆ: ಸ್ಥಳೀಯ VPN ಪ್ರೊಫೈಲ್, ನಿರ್ವಹಣಾ ನೀತಿ, ಸಂಪರ್ಕ ಸ್ಕ್ರಿಪ್ಟ್ ಅಥವಾ ಸಂಪೂರ್ಣ ಬೇರೆ ಕ್ಲೈಂಟ್. ಜೀವಂತ ನಮೂದನ್ನು ಅಳಿಸುವುದು ಅದರ ಪ್ರಸ್ತುತತೆಯನ್ನು ದೃಢೀಕರಿಸಬಹುದು, ಆದರೆ ಮುಂದಿನ ಸಂಪರ್ಕವು ಅದನ್ನು ಉಳಿಸಿದ ಸಂರಚನೆಯಿಂದ ಮತ್ತೆ ರಚಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೂಲವೇ ಬದಲಾಗಬೇಕು.

ಮೊದಲು ಪ್ರೊಫೈಲ್‌ನ ಮಾರ್ಗ ಪಟ್ಟಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ನಿರ್ವಹಣಾ ನೀತಿ, ನಂತರ ಸಂಪರ್ಕದಲ್ಲಿ ಚಲಿಸುವ ಯಾವುದೇ ಸ್ಕ್ರಿಪ್ಟ್. ಆ ಕ್ರಮವು ಪ್ರತಿಯೊಂದೂ ಎಷ್ಟು ಬಾರಿ ಜವಾಬ್ದಾರವಾಗುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಹೊಂದುತ್ತದೆ. ಇದು ಬದಲಾವಣೆಯನ್ನು ಮೂರರ ಬದಲು ಒಂದು ಪದರದಲ್ಲಿ ಇಡುತ್ತದೆ.

ಸ್ಥಳೀಯ ವರ್ಗ-ಆಧಾರಿತ ವರ್ತನೆಯನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಓದಿ

ಸ್ಥಳೀಯ Windows ಪ್ರೊಫೈಲ್‌ಗಳಲ್ಲಿ ದಾಖಲಿತ ಸೆಟ್ಟಿಂಗ್ ಇದೆ, NativeProfile/DisableClassBasedDefaultRoute, ಇದು ಇಂಟರ್ಫೇಸ್ ವಿಳಾಸದಿಂದ ಅಂದಾಜಿಸಲಾದ ಸ್ವಯಂಚಾಲಿತ ಮಾರ್ಗವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. 45 ರಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಪ್ರೊಫೈಲ್ ವಿಳಾಸವು ಆ ವರ್ತನೆಯಡಿ 45.0.0.0/8 ನಮೂದನ್ನು ಉತ್ಪಾದಿಸಬಹುದು, ಮತ್ತು ಹೀಗೆ ಒಂದು ಸಾರ್ವಜನಿಕ ವಿಳಾಸವು ಇಡೀ ವರ್ಗ-A ಶ್ರೇಣಿಯನ್ನು ಹಿಡಿಯುತ್ತದೆ.

ಗುಣದ ಹೆಸರು ತಪ್ಪು ಓದಿಗೆ ಆಹ್ವಾನಿಸುತ್ತದೆ: ಅದನ್ನು true ಗೆ ಹೊಂದಿಸಿದರೆ ಅಂದಾಜು ನಿಷ್ಕ್ರಿಯವಾಗುತ್ತದೆ, ಮತ್ತು false ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಇದು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದಂತೆಯೇ ಅದೇ ವಸ್ತುವಲ್ಲ, ಮತ್ತು ತಮ್ಮದೇ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸುವ ತೃತೀಯ-ಪಕ್ಷದ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಇದು ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ.

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

ಮೂಲವನ್ನು ಸರಿಪಡಿಸಿ, ನಂತರ ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ

ಬದಲಾವಣೆಯ ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ವಿಫಲವಾಗುವ ಸಾರ್ವಜನಿಕ ಸೈಟ್ ಹಾಗೂ ಸುರಂಗವನ್ನು ಬಳಸಬೇಕಾದ ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ಹುಡುಕಾಟವನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಮೊದಲನೆಯದು ಈಗ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಪರಿಹರಿಸಬೇಕು, ಮತ್ತು ಎರಡನೆಯದು ಇನ್ನೂ VPN ಆಯ್ಕೆ ಮಾಡಬೇಕು. ಮೊದಲ ಯಶಸ್ಸಿನಲ್ಲಿ ನಿಲ್ಲಬೇಡಿ; ಖಾಸಗಿ ಪ್ರವೇಶವನ್ನೂ ಮುರಿಯುವ ಸರಿಪಡಿಸುವಿಕೆ ಒಂದು ದೋಷವನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ವಿನಿಮಯ ಮಾಡಿದೆ.

ಅದೇ ಸಮಯದಲ್ಲಿ ಸರ್ವರ್‌ನ ವಿಳಾಸ ಯೋಜನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಸಾರ್ವಜನಿಕ ಜಾಗದೊಂದಿಗೆ ಅತಿಕ್ರಮಿಸುವ ಪೂಲ್ ಈ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಪದೇ ಪದೇ ಉಂಟುಮಾಡುತ್ತದೆ. ನಿರ್ವಾಹಕರು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ ಶ್ರೇಣಿ ಬೇರೆ ಸಂಭಾಷಣೆಗೆ ಅರ್ಹವಾಗಿದೆ, ಸ್ವಯಂ ಮರುಸಂಖ್ಯೆಗೆ ಅಲ್ಲ.

MTU ಹೆಚ್ಚಿಸುವುದು ಅಥವಾ DNS ತೆರವು ಮಾಡುವುದು ಆ ವಿಳಾಸವನ್ನು ಇನ್ನೂ ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸುವ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಮೊದಲು ಆಯ್ಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಮಾರ್ಗವನ್ನು.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು