iOS VPN API: NEVPNManager, ಟನೆಲ್ ಪೂರೈಕೆದಾರ ಅಥವಾ ಪ್ರೊಫೈಲ್?

ಮೂರು ವಿಭಿನ್ನ ಉತ್ಪನ್ನಗಳು 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 ನೀಡುತ್ತದೆ, ಮತ್ತು ಖಾಸಗಿ ಕೀ ಮಾರ್ಗಗಳಿಗೆ ಕೈಚಾಚುವ ಕೋಡ್ ಬಿಡುಗಡೆಗಳ ನಡುವೆ ಮುರಿಯುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಹಿನ್ನೆಲೆಯಲ್ಲಿದ್ದಾಗಲೂ provider ಚಲಿಸುತ್ತಲೇ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ container ಅಪ್ಲಿಕೇಶನ್ಗೆ ಅದಕ್ಕಾಗಿ ಯಾವುದೇ ಹಿನ್ನೆಲೆ ಮೋಡ್ ಬೇಕಿಲ್ಲ.

ಹಂತ 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 ಅನ್ನು ಪೂರಕ ಸಾಕ್ಷ್ಯವೆಂದು ಪರಿಗಣಿಸಿ.