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 ਅਤੇ ਮਾਰਗ ਪਰਖ ਅਸਲ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ।