NEVPNManager ಉಳಿಸುತ್ತಿಲ್ಲವೇ? ಕ್ರಮ ಲೋಡ್, ಸಕ್ರಿಯಗೊಳಿಸು, ಉಳಿಸು, ಸಂಪರ್ಕಿಸು

iOS ನಲ್ಲಿ Network Extension VPN ಗಾಗಿ ಮೊದಲ ಪ್ರಯತ್ನಗಳ ಬಹುಪಾಲನ್ನು ಎರಡು ದೋಷ ಸಂಕೇತಗಳು ವಿವರಿಸುತ್ತವೆ: NEVPNErrorDomain Code=4 ಮತ್ತು Code=5. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಸರ್ವರ್ನ ದೂರು ಅಲ್ಲ. ಒಂದು ಡಿಸ್ಕ್ನಿಂದ ಎಂದೂ ಓದದ ವಸ್ತುವಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬರೆಯುವಾಗ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಇನ್ನೊಂದು ಬರವಣಿಗೆಯೇ ವಿಫಲವಾದಾಗ, ಹೆಚ್ಚಾಗಿ ಪ್ರೊಫೈಲ್ ಇನ್ನೂ ನಿಷ್ಕ್ರಿಯವಾಗಿರುವಾಗ ಉಳಿಸಲ್ಪಡುವ ಕಾರಣ. ಎರಡನ್ನೂ ನಾಲ್ಕು ಕರೆಗಳ ಕ್ರಮವನ್ನು ಬದಲಿಸಿ ಸರಿಪಡಿಸಬಹುದು, IKEv2 ನಿಯತಾಂಕಗಳನ್ನು ಮುಟ್ಟದೆ.

ಮೊದಲು ಲೋಡ್ ಮಾಡಿ, ಇಲ್ಲದಿದ್ದರೆ ಉಳಿಸುವಿಕೆಗೆ ಹೋಲಿಸಲು ಏನೂ ಇಲ್ಲ

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

let mgr = NEVPNManager.shared()
mgr.loadFromPreferences { loadErr in
    guard loadErr == nil else { return }
    let proto = NEVPNProtocolIKEv2()
    proto.serverAddress = "vpn.example.net"
    proto.username = "alice"
    proto.useExtendedAuthentication = true
    mgr.protocolConfiguration = proto
    mgr.isEnabled = true
    mgr.saveToPreferences { saveErr in
        // do not start here; reload, then connect
    }
}

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

ಸಕ್ರಿಯಗೊಳಿಸುವ ಧ್ವಜ ಉಳಿಸುವಿಕೆಯ ಭಾಗವೇ

ಸಂಗ್ರಹಿತ ಪ್ರೊಫೈಲ್ ಆನ್ ಆಗುವವರೆಗೆ ನಿಷ್ಕ್ರಿಯ. isEnabled = true ಅನ್ನು ಅದೇ ಬರವಣಿಗೆಯಲ್ಲಿ ಹೊಂದಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಪ್ರೊಫೈಲ್ ನಿಷ್ಕ್ರಿಯವಾಗಿ ಡಿಸ್ಕ್ಗೆ ಇಳಿಯುತ್ತದೆ ಮತ್ತು ಸೆಟ್ಟಿಂಗ್ಗಳು ಪೂರ್ಣವಾಗಿ ಕಾಣುವ ಸಂರಚನೆಯನ್ನು ತೋರಿಸಿದರೂ startVPNTunnel ನಿರಾಕರಿಸುತ್ತದೆ.

ಬಾಹ್ಯ ಸಂಪಾದನೆಗಳು ಇದರ ಇನ್ನೊಂದು ಅರ್ಧ. ಬಳಕೆದಾರರು ಸೆಟ್ಟಿಂಗ್ಗಳಲ್ಲಿ ಏನನ್ನಾದರೂ ಬದಲಿಸಿದರೆ, ಅಥವಾ ಸಾಧನವು ಜಾಲಗಳ ನಡುವೆ ಸರಿದರೆ, ನೆನಪಿನಲ್ಲಿಟ್ಟಿರುವ ಮೌಲ್ಯಗಳನ್ನು ನಂಬುವ ಮೊದಲು ಮತ್ತೆ ಓದಿ. ಆ ಬದಲಾವಣೆಗಳನ್ನು ವಸ್ತು ನಿಮಗಾಗಿ ಗಮನಿಸುವುದಿಲ್ಲ. ಹಳೆಯ ಪ್ರತಿಯೇ ಬಳಕೆದಾರರ ಸಂಪಾದನೆಯನ್ನು ಮೌನವಾಗಿ ಹಿಂತಿರುಗಿಸುವ ಪ್ರೊಫೈಲ್ ಬರೆಯುವ ದಾರಿ. ಪಕ್ಕದ ಎರಡು ಕ್ಷೇತ್ರಗಳು ಅದೇ ಕ್ಷಣದಲ್ಲಿ ಮೌನ ತೊಂದರೆ ಉಂಟುಮಾಡುತ್ತವೆ: on-demand ನಿಯಮಗಳು ಖಾಲಿ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ ಅಲ್ಲದೆ ನಿಯಮ ವಸ್ತುಗಳ ಸರಣಿಯಾಗಿರಬೇಕು, ಮತ್ತು disconnectOnSleep ನಕಲಿಸಿದ ಡೀಫಾಲ್ಟ್ ಬದಲು ನೀವು ಆರಿಸಿದ ವರ್ತನೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸಬೇಕು.

ತೃತೀಯ-ಪಕ್ಷದ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ಕೇವಲ ಎರಡು ಪ್ರೋಟೋಕಾಲ್ಗಳು ಲಭ್ಯ

Network Extension ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ IPsec ಮತ್ತು IKEv2 ನೀಡುತ್ತದೆ. L2TP ಮತ್ತು PPTP ವ್ಯವಸ್ಥೆಯ ಒಳಗೆಯೇ ಉಳಿಯುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವು ಬೇಕಾದ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಅವು ಸಿಗುವುದಿಲ್ಲ, ಮತ್ತು ವಾಸ್ತವಿಕ ಉತ್ತರಗಳು IKEv2 ಸಮರ್ಥ ಗೇಟ್ವೇ ಅಥವಾ ನಿರ್ವಹಿತ ಸಂರಚನಾ ಪ್ರೊಫೈಲ್.

ರುಜುವಾತುಗಳು ಅದೇ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸುತ್ತವೆ. ಪಾಸ್ವರ್ಡ್ ಅನ್ನು Keychain ನಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಸ್ಟ್ರಿಂಗ್ ಬದಲು ಶಾಶ್ವತ ಉಲ್ಲೇಖವನ್ನು ರವಾನಿಸಿ. ಉಳಿಸುವಾಗ ಶೂನ್ಯ ಉಲ್ಲೇಖ ಸಾಮಾನ್ಯವಾಗಿ ಐಟಂ ಬರೆಯುವ ಮೊದಲೇ ಹುಡುಕಾಟ ನಡೆದಿದೆ ಎಂದರ್ಥ, ನಿರ್ವಾಹಕ ಕೆಟ್ಟಿದೆ ಎಂದಲ್ಲ.

ಎರಡೂ ವಿನ್ಯಾಸ ನಿರ್ಣಯಗಳು, ಪರ್ಯಾಯ ದಾರಿಗಳಲ್ಲ. ತನ್ನದೇ ಆದ್ಯತೆಗಳಲ್ಲಿ ಪಾಸ್ವರ್ಡ್ ಇಡುವ ಅಪ್ಲಿಕೇಶನ್ ಚೌಕಟ್ಟು ಪ್ರೋತ್ಸಾಹಿಸದ ದಾರಿಯನ್ನು ಆರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಉತ್ಪಾದಿಸುವ ವೈಫಲ್ಯ ಉಳಿಸುವ ದೋಷದಂತೆ ಓದಲ್ಪಡುತ್ತದೆ.

ಕೋಡ್ ಮತ್ತೆ ಬರೆಯುವ ಮೊದಲು entitlement ಅನ್ನು ಹೊರಗಿಡಿ

loadFromPreferences ಎಂದೂ ಮರಳಿ ಕರೆಯದಿದ್ದರೆ, ಸಂಭಾವ್ಯ ಕಾರಣ ಕಾಣೆಯಾದ Network Extension ಸಾಮರ್ಥ್ಯ ಅಥವಾ ಅದನ್ನು ಹೊತ್ತಿರದ ಪ್ರೊವಿಷನಿಂಗ್ ಪ್ರೊಫೈಲ್. ಆ ವೈಫಲ್ಯ ದೋಷ ನೀಡುವ ಬದಲು ನೇತಾಡುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೇ ಕೆಲಸ ಮಾಡುವ ಕೋಡ್ ಗಂಟೆಗಟ್ಟಲೆ ಮತ್ತೆ ಬರೆಯಲ್ಪಡುತ್ತದೆ. ನೀವು ಬಿಡುಗಡೆ ಮಾಡಲು ಉದ್ದೇಶಿಸಿರುವ ಸಹಿ ಮಾಡಿದ ಬಿಲ್ಡ್ನಲ್ಲಿ entitlement ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಸಿಮ್ಯುಲೇಟರ್ ಓಟ ಮತ್ತು ಸಾಧನದ ಓಟ ಭಿನ್ನವಾಗಿರಬಹುದು ಮತ್ತು ಮುಖ್ಯ ಗುರಿ ಸಾಧನ. ಗುರಿಯ ಸಹಿ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ತೆರೆದು ಆ ನಿಖರ ಬಿಲ್ಡ್ಗೆ Network Extension ಸಾಮರ್ಥ್ಯ ಇದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.

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

ಊಹೆಗಳನ್ನಲ್ಲ, ಸ್ಥಿತಿ ಬದಲಾವಣೆಗಳನ್ನು ನೋಡಿ

NEVPNStatusDidChangeNotification ಅನ್ನು ಗಮನಿಸಿ ಮತ್ತು ಪ್ರತಿ ಹಂತದ ನಂತರ manager.connection.status ಅನ್ನು ದಾಖಲಿಸಿ. invalid ಅನ್ನು ಎಂದೂ ಬಿಡದ ಸ್ಥಿತಿ ಎಂದರೆ ಪ್ರೊಫೈಲ್ ಸಂಗ್ರಹವಾಗಿಲ್ಲ ಅಥವಾ entitlement ಇಲ್ಲ. connecting ತಲುಪಿ ಎಂದೂ ಸಂಪರ್ಕಿಸದ ಸಂಪರ್ಕವು ಪ್ರಸ್ತಾವ ಅಥವಾ ರುಜುವಾತುಗಳತ್ತ ಸೂಚಿಸುತ್ತದೆ, ಅದು ಬೇರೆ ಸಾಕ್ಷ್ಯಗಳಿರುವ ಬೇರೆ ತನಿಖೆ.

ಪ್ರೊಫೈಲ್ ಸೆಟ್ಟಿಂಗ್ಗಳು, ಸಾಮಾನ್ಯ, VPN ಅಡಿಯಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ ಮತ್ತು ಪ್ರತಿ ಕ್ಲೋಸರ್ನ ದೋಷವನ್ನು ದಾಖಲಿಸಿ. ಆ ಎರಡು ಸಂಗತಿಗಳು ಊಹೆಯಿಲ್ಲದೆ ಕ್ರಮದ ದೋಷವನ್ನು ಅನುಮತಿ ದೋಷದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ.