Android, iOS ಮತ್ತು Windows ನಲ್ಲಿ ಪಿಂಗ್ ಇಲ್ಲದೆ VPN ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದು ಹೇಗೆ

192.0.2.10 ಗೆ ಪಿಂಗ್ ಮಾಡುವುದು ಒಂದು ವಿಳಾಸವು ICMP ಪ್ರತಿಧ್ವನಿಗೆ ಉತ್ತರಿಸಿದೆ ಎಂದು ಮಾತ್ರ ಹೇಳುತ್ತದೆ, ಅಷ್ಟೇ. ಟನೆಲ್ ಇಲ್ಲದ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲೂ ಅದು ಯಶಸ್ವಿಯಾಗಬಹುದು, ಏಕೆಂದರೆ ವಿಳಾಸವು ಸ್ಥಳೀಯ ಉಪಜಾಲದಲ್ಲಿರಬಹುದು; ಆರೋಗ್ಯಕರ ಟನೆಲ್ ಇದ್ದಾಗಲೂ ಅದು ವಿಫಲವಾಗಬಹುದು, ಏಕೆಂದರೆ ಸರ್ವರ್ HTTPS ನೀಡುತ್ತಿರುವಾಗ ICMP ಅನ್ನು ಬಿಡುತ್ತದೆ. ನಿಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಬೇಕಾದ ಪರಿಶೀಲನೆ ಎಂದರೆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸ್ಥಿತಿ ಪ್ರಶ್ನೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಮಾರ್ಗ ಪರೀಕ್ಷೆ. ಅವನ್ನು ಎರಡು ಪ್ರತ್ಯೇಕ ಕ್ಷೇತ್ರಗಳಾಗಿ ಪರಿಗಣಿಸಿ, ಎಂದಿಗೂ ಒಂದೇ ಬೂಲಿಯನ್ ಆಗಿ ಅಲ್ಲ.

ಪ್ರತಿಧ್ವನಿ ಉತ್ತರವು ನಿಜವಾಗಿ ಏನನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ

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

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

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

Android ಗೆ ಪಿಂಗ್ ಅಲ್ಲ, ಸಾಗಣೆಯನ್ನು ಕೇಳಿ

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

ಈ Java ಆವೃತ್ತಿ ಸಕ್ರಿಯ ನೆಟ್‌ವರ್ಕ್ ಇಲ್ಲದಿದ್ದಾಗ ಎಕ್ಸೆಪ್ಶನ್ ಎಸೆಯುವ ಬದಲು false ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಅದು ಸಕ್ರಿಯ ನೆಟ್‌ವರ್ಕ್ ಓದುವುದರಿಂದ, ಬಳಕೆದಾರರು ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡಿದ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ.

ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

ಬದಲಾವಣೆ ಅಧಿಸೂಚನೆಗಳಿಗೆ, ಟೈಮರ್‌ನಲ್ಲಿ ಪೋಲ್ ಮಾಡುವ ಬದಲು NetworkCallback ನೋಂದಾಯಿಸಿ. ಅದನ್ನು VpnService.prepare ಜೊತೆ ಗೊಂದಲಪಡಿಸಬೇಡಿ, ಅದು ಬಳಕೆದಾರರು VPN ಗೆ ಅನುಮತಿ ನೀಡಿದ್ದಾರೆಯೇ ಎಂದು ಮಾತ್ರ ವರದಿ ಮಾಡುತ್ತದೆ, ಪ್ಯಾಕೆಟ್‌ಗಳು ಹರಿಯುತ್ತಿವೆಯೇ ಎಂದಲ್ಲ. ರದ್ದತಿ VpnService.onRevoke ಮೂಲಕ ಬರುತ್ತದೆ, ಆದರೂ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ಪ್ರೊಫೈಲ್ ಮರೆತರೆ ಯಾವುದೇ ಪ್ರಸಾರ ಉಂಟಾಗುವುದಿಲ್ಲ.

iOS: ಇಂಟರ್‌ಫೇಸ್ ಹೆಸರುಗಳು ಅನುಮಾನ, ಒಪ್ಪಂದವಲ್ಲ

ಅನೇಕ iOS ತುಣುಕುಗಳು ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, __SCOPED__ ನಿಘಂಟನ್ನು ಕಂಡುಕೊಂಡು, tap, tun, utun2, ppp ಅಥವಾ ipsec ನಂತಹ ಇಂಟರ್‌ಫೇಸ್ ಕೀಗಳನ್ನು ಹುಡುಕುತ್ತವೆ. ಆ ವಿಧಾನ ನಾಮಕರಣ ಸಂಪ್ರದಾಯ, ದಾಖಲಿತ ಭರವಸೆ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಇಂಟರ್‌ಫೇಸ್ ಹೆಸರು ಬದಲಿಸುವ OS ನವೀಕರಣ ಅದನ್ನು ಮುರಿಯಬಹುದು. ಟನೆಲ್‌ಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುವ ಹಳೆಯ ನಮೂದುಗಳಿಗೆ true ವರದಿ ಮಾಡುವ ಪ್ರವೃತ್ತಿಯೂ ಅದಕ್ಕಿದೆ.

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

ಸ್ಥಿತಿ ಓದುವ ಮೊದಲು ಆದ್ಯತೆಗಳನ್ನು ಮರುಲೋಡ್ ಮಾಡಿ, ಏಕೆಂದರೆ ಟನೆಲ್ ಬರುವ ಮತ್ತು ಹೋಗುವಾಗ ಮೌಲ್ಯ ಬದಲಾಗುತ್ತದೆ:

let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
    let up = manager.connection.status == .connected
    print(up)
}

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

Windows ಪ್ರೊಫೈಲ್‌ಗಳು ನಿಜವಾದ ಸ್ಥಿತಿ ಕ್ಷೇತ್ರವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತವೆ

Windows VPN ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಅಡಾಪ್ಟರ್‌ಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು Get-VpnConnection ತಿಳಿದಿರುವ ಪ್ರತಿ ಪ್ರೊಫೈಲ್‌ಗೂ ConnectionStatus ತೋರಿಸುತ್ತದೆ. Windows ಕ್ಲೈಂಟ್ ಅಥವಾ ಒದಗಿಸುವ ಪ್ಯಾಕೇಜ್ ಮೂಲಕ ರಚಿಸಿದ ಪ್ರೊಫೈಲ್‌ಗಳು ಇಲ್ಲಿ ಕಾಣಿಸುತ್ತವೆ. ಈ cmdlet ಸಾಮಾನ್ಯ ಟನೆಲ್ ಪತ್ತೆದಾರವಲ್ಲ.

ಹೆಸರಿಸಿದ ಪ್ರೊಫೈಲ್‌ಗಾಗಿ ಕ್ಷೇತ್ರವನ್ನು ಓದಿ, ಪ್ರೊಫೈಲ್ ಎಲ್ಲಾ ಬಳಕೆದಾರರದ್ದಾಗಿದ್ದರೆ -AllUserConnection ಸೇರಿಸಿ:

Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress

ತೃತೀಯ ಪಕ್ಷದ ಕ್ಲೈಂಟ್‌ಗಳು ತಮ್ಮ ಟನೆಲ್ ಸಕ್ರಿಯವಾಗಿದ್ದರೂ ಈ cmdlet ಗೆ ಕಾಣದೆ ಇರುತ್ತವೆ, ಆದ್ದರಿಂದ ಖಾಲಿ ಫಲಿತಾಂಶ ಎಂದರೆ ಅಜ್ಞಾತ, ಸಂಪರ್ಕ ಕಡಿತವಲ್ಲ. ಅಡಾಪ್ಟರ್ ಪಟ್ಟಿಗಳೂ ಅಷ್ಟೇ ದಾರಿತಪ್ಪಿಸುತ್ತವೆ: ತಯಾರಕರ ಅಡಾಪ್ಟರ್ ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದರೂ ಉಳಿಯಬಹುದು, ಮತ್ತು ಕೆಲವು ಅಡಾಪ್ಟರ್‌ಗಳು ಸೆಷನ್ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ಇರುತ್ತವೆ. Windows ಒಡೆತನದ ಪ್ರೊಫೈಲ್‌ಗೆ rasdial ಶಾಖೆ ಮಾಡಬಹುದಾದ ನಿರ್ಗಮನ ಸಂಕೇತವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಇವೆಲ್ಲವೂ ಸ್ಥಳೀಯ ನಂಬಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ, ಸಹಚರರ ತಲುಪುವಿಕೆಯನ್ನಲ್ಲ.

ಸ್ಥಿತಿ ಜೊತೆಗೆ ಮಾರ್ಗ: ಎರಡು ಭಾಗದ ಪರಿಶೀಲನೆ

ಸಂಪರ್ಕಗೊಂಡ ಪ್ರೊಫೈಲ್ ಪ್ಯಾಕೆಟ್‌ಗಳು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ ಎಂದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ವಿಭಜಿತ ಟನೆಲಿಂಗ್ ಟನೆಲ್ ಸಕ್ರಿಯವಾಗಿಟ್ಟುಕೊಂಡು ನಿಮಗೆ ಮುಖ್ಯವಾದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹೊರಗಿಡಬಹುದು. always-on ಪ್ರೊಫೈಲ್‌ಗಳು ಸತ್ತ ಸರ್ವರ್‌ನೊಂದಿಗೂ ಸಂಪರ್ಕಗೊಂಡಿರುತ್ತವೆ, ಮತ್ತು ಟನೆಲ್ ಬಿದ್ದಾಗ kill switch ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಂಚಾರವನ್ನು ತಡೆಯುತ್ತದೆ.

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

ip route get 192.0.2.10
resolvectl query intranet.example.test

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

ಕ್ರಮದಲ್ಲಿ ಚಲಾಯಿಸಬಹುದಾದ ಪರೀಕ್ಷೆ

ಯಾವುದೇ ನೆಟ್‌ವರ್ಕ್ ಸ್ಥಿತಿ ಬದಲಿಸುವ ಮೊದಲು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸ್ಥಿತಿಯನ್ನು ಮೊದಲು ದಾಖಲಿಸಿ. ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ಪರಿಹರಿಸಿ ಮತ್ತು ವಿಳಾಸ ಕುಟುಂಬವನ್ನು ಗಮನಿಸಿ, ಏಕೆಂದರೆ AAAA ದಾಖಲೆ A ದಾಖಲೆಗಿಂತ ಬೇರೆ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಸೇವಾ ಪೋರ್ಟ್ ತೆರೆದು ಬರೀ ಹಸ್ತಲಾಘವದ ಬದಲು ಅಪ್ಲಿಕೇಶನ್ ಉತ್ತರವನ್ನು ಒತ್ತಾಯಿಸಿ. ಪ್ರತಿ ವೀಕ್ಷಣೆಯನ್ನು ಅದರದೇ ಲಾಗ್ ಕ್ಷೇತ್ರದಲ್ಲಿ ಇರಿಸಿ.

dig ಮತ್ತು curl ಇರುವ Linux ಯಂತ್ರದಲ್ಲಿ, ಮೂರು ಆಜ್ಞೆಗಳು ಪರಿಹಾರ, ಮಾರ್ಗ ಮತ್ತು ಸೇವೆಯನ್ನೇ ಒಳಗೊಳ್ಳುತ್ತವೆ. ಟನೆಲ್ ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ ಮತ್ತು ನಂತರ ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದಾಗ ಅವನ್ನು ಚಲಾಯಿಸಿ:

dig +short intranet.example.test
ip route get 198.51.100.20
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 https://intranet.example.test/health

ನಾಲ್ಕು ಪ್ರತ್ಯೇಕ ಕ್ಷೇತ್ರಗಳು ಒಂದು ಬೂಲಿಯನ್‌ಗಿಂತ ಉತ್ತಮ, ಏಕೆಂದರೆ ಸ್ಥಿತಿ, DNS, ಮಾರ್ಗ ಮತ್ತು ನೀತಿ ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗಿ ಬೇರೆ ಬೇರೆ ತಂಡಗಳನ್ನು ತಲುಪುತ್ತವೆ. ಟರ್ಮಿನಲ್ ಪಿಂಗ್ ಉತ್ತಮ ಕೈಯಿಂದ ಪರಿಶೀಲನೆಯಾಗಿ ಉಳಿಯುತ್ತದೆ. ಸ್ವಯಂಚಾಲನೆಗೆ ಅದು ಸಂಪರ್ಕದ ಕಳಪೆ ವ್ಯಾಖ್ಯಾನ, ಅಲ್ಲಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ API ಮತ್ತು ಮಾರ್ಗ ಪರೀಕ್ಷೆ ನಿಜವಾದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತವೆ.