iOS VPN API: NEVPNManager, ਟਨਲ ਪ੍ਰਦਾਤਾ ਜਾਂ ਪ੍ਰੋਫ਼ਾਈਲ?

ਜਿਸ ਟਰਾਂਸਪੋਰਟ ਨਾਲ ਤੁਹਾਨੂੰ ਬੋਲਣਾ ਹੈ ਉਸ ਦੇ ਆਧਾਰ 'ਤੇ API ਚੁਣੋ, ਫਿਰ ਸਾਬਤ ਕਰੋ ਕਿ ਟਨਲ ਟ੍ਰੈਫ਼ਿਕ ਢੋਂਦਾ ਹੈ: save-load-start ਕ੍ਰਮ, provider entitlements ਅਤੇ on-demand ਨਿਯਮ।

ਤਿੰਨ ਵੱਖਰੇ ਉਤਪਾਦ iOS VPN ਨਾਮ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਉਹ ਇੱਕੋ API ਸਾਂਝਾ ਨਹੀਂ ਕਰਦੇ। Personal VPN ਸਿਸਟਮ ਦੇ ਅੰਦਰਲੇ IPsec ਅਤੇ IKEv2 ਟਰਾਂਸਪੋਰਟਾਂ 'ਤੇ ਚੱਲਦਾ ਹੈ। Custom tunnel ਤੁਹਾਡਾ ਆਪਣਾ ਪ੍ਰੋਟੋਕੋਲ network extension ਦੇ ਅੰਦਰ ਚਲਾਉਂਦਾ ਹੈ। Configuration profile ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਨੂੰ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ ਅਤੇ on-demand ਵਿਵਹਾਰ ਜੋੜ ਸਕਦਾ ਹੈ। ਜਿਸ ਟਰਾਂਸਪੋਰਟ ਨਾਲ ਤੁਹਾਨੂੰ ਬੋਲਣਾ ਹੈ ਉਸ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣਨਾ, ਪਹਿਲਾਂ ਕੰਪਾਇਲ ਹੋਏ ਟਿਊਟੋਰਿਅਲ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣਨ ਨਾਲੋਂ ਤੇਜ਼ ਹੈ।

ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਚਲਾਓ, ਕਿਉਂਕਿ ਹਰ ਕਦਮ ਮੰਨਦਾ ਹੈ ਕਿ ਪਿਛਲੇ ਕਦਮ ਨੇ ਵੈਧ ਸੰਰਚਨਾ ਤਿਆਰ ਕੀਤੀ।

ਕਦਮ 1: ਟਰਾਂਸਪੋਰਟ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣੋ

ਜੇ ਸਰਵਰ IKEv2 ਜਾਂ Cisco ਸ਼ੈਲੀ ਦਾ IPsec ਹੈ, ਤਾਂ NEVPNManager ਕਾਫ਼ੀ ਹੈ ਅਤੇ ਸਿਸਟਮ ਟਰਾਂਸਪੋਰਟ ਮੁਫ਼ਤ ਆਉਂਦੇ ਹਨ। ਜੇ ਸਰਵਰ OpenVPN, WireGuard ਜਾਂ ਹੋਰ ਕੁਝ ਬੋਲਦਾ ਹੈ, ਤਾਂ NEVPNManager ਮਦਦ ਨਹੀਂ ਕਰ ਸਕਦਾ: ਤੀਜੀ ਧਿਰ ਦੇ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਇਸ ਕੋਲ ਕੋਈ ਹੁੱਕ ਨਹੀਂ। ਉਸ ਸਥਿਤੀ ਲਈ ਪ੍ਰੋਟੋਕੋਲ ਲਾਗੂ ਕਰਨ ਵਾਲੇ packet tunnel provider ਨਾਲ NETunnelProviderManager ਚਾਹੀਦਾ ਹੈ। ਪ੍ਰੋਫ਼ਾਈਲ ਸਿਰਫ਼ ਸੰਰਚਨਾ ਵੰਡਦਾ ਹੈ, ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕੋਲ ਨਾ ਹੋਣ ਵਾਲਾ ਟਰਾਂਸਪੋਰਟ ਇਹ ਨਹੀਂ ਜੋੜ ਸਕਦਾ।

ਮੌਜੂਦਾ ਸਿਸਟਮਾਂ 'ਤੇ PPTP ਨਿਸ਼ਾਨਾ ਨਹੀਂ ਹੈ। Shared-secret IPsec ਅਜੇ ਵੀ remoteIdentifier ਵਿੱਚ ਸਮੂਹ ਦਾ ਨਾਮ, ਭੇਤ ਰੱਖਣ ਵਾਲੀ keychain ਵਸਤੂ, ਅਤੇ ਸਰਵਰ ਵੱਲੋਂ ਵਰਤੋਂਕਾਰ ਨਾਮ ਮੰਗਣ 'ਤੇ ਵਿਸਤ੍ਰਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਆਸ ਰੱਖਦਾ ਹੈ। ਹਰ ਗੁੰਮ ਹਿੱਸਾ ਉਸੇ ਆਮ ਸੰਰਚਨਾ ਗਲਤੀ ਵਜੋਂ ਦਿਸਦਾ ਹੈ, ਇਸ ਲਈ ਹੋਰ ਕੁਝ ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸਭ ਜੋੜੋ।

ਕਦਮ 2: ਸੰਭਾਲ, ਲੋਡ, ਸ਼ੁਰੂ ਕ੍ਰਮ ਦੀ ਪਾਲਣਾ ਕਰੋ

NEVPNManager preferences ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਵਾਪਸ ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਹੀ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ manager ਵਸਤੂਆਂ ਭਰੋ, saveToPreferences ਕਾਲ ਕਰੋ, loadFromPreferences ਕਾਲ ਕਰੋ, ਅਤੇ load completion handler ਤੋਂ startVPNTunnel ਕਾਲ ਕਰੋ। ਲੋਡ ਦੇ ਵਾਪਸ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਕਰਨਾ ਬਾਕੀ ਸਹੀ ਸੰਰਚਨਾ 'ਤੇ configuration-invalid ਗਲਤੀ, NEVPNErrorDomain code 1, ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਆਕਾਰ ਇੱਕ ਥਾਂ 'ਤੇ ਰੱਖਣ ਲਈ ਕਾਫ਼ੀ ਛੋਟਾ ਹੈ:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

startVPNTunnel ਬੇਨਤੀ ਸਵੀਕਾਰ ਹੋਣ 'ਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਟਨਲ ਉੱਪਰ ਆਉਣ 'ਤੇ ਨਹੀਂ। NEVPNStatusDidChange ਦੇਖੋ ਅਤੇ ਅਸਲ ਸਥਿਤੀ ਲਈ connection.status ਪੜ੍ਹੋ। ਕਾਲ ਵਾਲੀ ਥਾਂ 'ਤੇ ਸਫਲਤਾ ਮੰਨਣ ਵਾਲੀ ਐਪ extension ਦੇ ਅਜੇ ਗੱਲਬਾਤ ਕਰਦੇ ਹੋਏ ਵੀ VPN ਜੁੜਿਆ ਦੱਸਦੀ ਹੈ। Connecting ਸਥਿਤੀ ਪਲ ਭਰ ਲਈ ਆਮ ਹੈ; ਉਸ ਤੋਂ ਕਦੇ ਨਾ ਨਿਕਲਣ ਵਾਲੀ ਸਥਿਤੀ ਹੀ ਲੌਗ ਕਰਨ ਯੋਗ ਅਸਫਲਤਾ ਹੈ।

ਕਦਮ 3: provider ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਹ ਦਿਓ ਜੋ ਉਸ ਨੂੰ ਚਾਹੀਦਾ ਹੈ

Custom transport ਆਪਣੇ bundle identifier ਅਤੇ ਆਪਣੇ entitlement ਵਾਲੀ ਵੱਖਰੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਚੱਲਦਾ ਹੈ। container ਐਪ ਅਤੇ provider ਦੋਵਾਂ ਨੂੰ ਦਸਤਖ਼ਤ ਕਰਦੇ ਸਮੇਂ network-extension entitlement ਚਾਹੀਦਾ ਹੈ, ਅਤੇ App Store ਤੋਂ ਬਾਹਰਲੇ Developer ID build ਨੂੰ ਵੀ ਇਹ provisioning profile ਵਿੱਚ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ। ਗੁੰਮ entitlement ਪ੍ਰੋਟੋਕੋਲ ਬੱਗ ਵਾਂਗ ਦਿਸਦਾ ਹੈ ਕਿਉਂਕਿ extension ਸ਼ੁਰੂ ਹੀ ਨਹੀਂ ਹੁੰਦਾ।

ਉਧਾਰ ਲੈਣ ਲਈ ਕੋਈ ਜਨਤਕ socket descriptor ਨਹੀਂ ਹੈ। NEPacketTunnelProvider ਤੁਹਾਨੂੰ read, write ਅਤੇ cancel ਵਾਲਾ NEPacketTunnelFlow ਦਿੰਦਾ ਹੈ, ਅਤੇ ਨਿੱਜੀ ਕੁੰਜੀ ਮਾਰਗਾਂ ਵੱਲ ਵਧਣ ਵਾਲਾ ਕੋਡ ਰਿਲੀਜ਼ਾਂ ਵਿਚਕਾਰ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਐਪ background ਵਿੱਚ ਹੋਣ 'ਤੇ ਵੀ provider ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ container ਐਪ ਨੂੰ ਇਸ ਲਈ ਕੋਈ background ਮੋਡ ਨਹੀਂ ਚਾਹੀਦਾ।

ਕਦਮ 4: on-demand ਨਿਯਮਾਂ ਦਾ ਸਮੂਹ ਹੈ, ਸਵਿੱਚ ਨਹੀਂ

isOnDemandEnabled ਸਿਰਫ਼ ਨਿਯਮਾਂ ਨੂੰ ਤਿਆਰ ਕਰਦਾ ਹੈ; ਟਨਲ ਕਦੋਂ ਉੱਪਰ ਆਉਣਾ ਹੈ ਇਹ NEOnDemandRuleConnect ਅਤੇ ਉਸ ਦੇ ਭਰਾ ਫ਼ੈਸਲਾ ਕਰਦੇ ਹਨ। probe URL ਵਾਲਾ evaluate-connection ਨਿਯਮ ਉਸ URL ਜਿੰਨਾ ਹੀ ਚੰਗਾ ਹੁੰਦਾ ਹੈ। ਜੇ probe ਟਨਲ ਤੋਂ ਬਿਨਾਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਨਿਯਮ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਪਹਿਲਾਂ ਹੀ ਪਹੁੰਚਯੋਗ ਹੈ ਅਤੇ ਕਦੇ ਵੀ ਨਹੀਂ ਜੁੜਦਾ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਉਸ ਚੀਜ਼ ਵੱਲ ਸੇਧਿਤ ਕਰੋ ਜੋ ਸਿਰਫ਼ ਅੰਦਰੋਂ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।

Always-on ਇੱਕ ਵੱਖਰਾ ਵਾਅਦਾ ਹੈ। ਇਸ ਲਈ ਨਿਗਰਾਨੀ ਵਾਲਾ ਯੰਤਰ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਪ੍ਰੋਫ਼ਾਈਲ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਵਾਲਾ ਵਰਤੋਂਕਾਰ ਪ੍ਰੋਫ਼ਾਈਲ ਜਦੋਂ ਚਾਹੇ ਹਟਾ ਸਕਦਾ ਹੈ। ਜੇ ਫਲੀਟ ਦੀ ਨਿਗਰਾਨੀ ਨਹੀਂ ਹੈ ਤਾਂ always-on 'ਤੇ ਨਿਰਭਰ ਡਿਜ਼ਾਈਨ ਨਾ ਭੇਜੋ।

ਕਦਮ 5: ਲੇਬਲ ਨਹੀਂ, ਰਾਹ ਸਾਬਤ ਕਰੋ

tun, tap, ppp ਜਾਂ ipsec ਇੰਟਰਫ਼ੇਸ ਸਕੈਨ ਕਰਨਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ VPN ਸੰਰਚਿਤ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਤੁਹਾਡੀ ਬੇਨਤੀ ਨੇ ਇਸ ਨੂੰ ਵਰਤਿਆ। usesInterfaceType(.other) ਵਾਲਾ NWPathMonitor ਦੱਸਦਾ ਹੈ ਕਿ ਵਰਚੁਅਲ ਇੰਟਰਫ਼ੇਸ ਉਪਲਬਧ ਹੈ, ਅਤੇ viability handler ਇੱਕ ਹੋਸਟ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ। ਦੋਵੇਂ ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਰਾਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ਼ ਟਨਲ ਹੀ ਪਹੁੰਚ ਸਕਣ ਵਾਲੇ ਸਰੋਤ ਵੱਲ ਬੇਨਤੀ ਨਾਲ ਜੋੜੋ। ਇੰਟਰਫ਼ੇਸ ਨਾਮ ਨਿਦਾਨ ਦੇ ਸਹਾਇਕ ਹਨ, ਕਦੇ ਵੀ ਉਹ ਦਰਵਾਜ਼ਾ ਨਹੀਂ ਜਿਸ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਲਾਜ਼ਿਕ ਨੂੰ ਸ਼ਾਖਾ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ।

ਖੇਤਰੀ ਜਾਂਚ ਲਈ, ਜਨਤਕ ਪਤੇ ਦੀ ਟਨਲ ਨਾਲ ਅਤੇ ਬਿਨਾਂ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਸਫ਼ਾ ਲਿਆਓ। provider ਦੇ ਗੱਲਬਾਤ ਕਰਦੇ ਸਮੇਂ status ਕਾਲ ਜੁੜਿਆ ਦੱਸ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਸਰੋਤ ਦੇ ਨਤੀਜੇ ਨੂੰ ਫ਼ੈਸਲਾ ਕਰਨ ਦਿਓ ਅਤੇ status ਨੂੰ ਸਹਾਇਕ ਸਬੂਤ ਮੰਨੋ।

ਸੰਬੰਧਿਤ ਲੇਖ