NEVPNManager iOS ನಲ್ಲಿ ಏನನ್ನು ರಚಿಸಬಹುದು (ಮತ್ತು ಏನನ್ನು ಸಾಧ್ಯವಿಲ್ಲ)

iOS ಅಪ್ಲಿಕೇಶನ್ ಒಳಗೆ VPN ಪರದೆಯನ್ನು ನಿರ್ಮಿಸಿದಾಗ, ಮೊದಲ ಆಶ್ಚರ್ಯ ಎಂದರೆ ಸೆಟ್ಟಿಂಗ್ಸ್ ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿನ ಪ್ರೋಟೋಕಾಲ್ ಪಟ್ಟಿ API ಪಟ್ಟಿಯಲ್ಲ. Network Extension ಚೌಕಟ್ಟು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಆ ಅಪ್ಲಿಕೇಶನ್ ಒಡೆತನದ ಒಂದು ವೈಯಕ್ತಿಕ VPN ಸಂರಚನೆಯನ್ನು ರಚಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಕೆಲವೇ ಪ್ರೋಟೋಕಾಲ್ ವಸ್ತುಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಜನರು ನಿರೀಕ್ಷಿಸುವ ಉಳಿದೆಲ್ಲವೂ, L2TP ನಿಂದ ಡೌನ್ಲೋಡ್ ಮಾಡಿದ ಪ್ರೊಫೈಲ್ವರೆಗೆ, ಆ ಮೇಲ್ಮೈಯ ಹೊರಗಿದೆ ಅಥವಾ Apple ಗೆ ಖಾಸಗಿ. ನಂತರ ಬರುವ ವೈಫಲ್ಯಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಬಗ್ಗಳಲ್ಲ, ಅದು ಎಂದಿಗೂ ನೀಡದ ಕೆಲಸವನ್ನು API ನಿರಾಕರಿಸುತ್ತಿದೆ.

ಪುರಾಣ: API ಒಂದು ಸೆಟ್ಟಿಂಗ್ಸ್ ಸಂಪಾದಕ

iOS IKEv1, IKEv2, L2TP ಮತ್ತು IPsec ಪ್ರೊಫೈಲ್ಗಳನ್ನು ಸಂರಚಿಸಬಲ್ಲದ್ದರಿಂದ, ಅಪ್ಲಿಕೇಶನ್ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಪ್ರೋಗ್ರಾಮ್ಮ್ಯಾಟಿಕ್ ಆಗಿ ರಚಿಸಬಹುದು ಎಂಬ ನಂಬಿಕೆ ಇದೆ. ಸಾಧ್ಯವಿಲ್ಲ. ಚೌಕಟ್ಟು ಕರೆಯುವ ಅಪ್ಲಿಕೇಶನ್ಗೆ ನಿಖರವಾಗಿ ಒಂದು ಸಂರಚನಾ ಸ್ಲಾಟ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಸ್ಲಾಟ್ ಸಾರ್ವಜನಿಕ ಪ್ರೋಟೋಕಾಲ್ ವರ್ಗಗಳ ಒಂದು ಸಣ್ಣ ಗುಂಪನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತದೆ. ಜನರು ನಿರೀಕ್ಷಿಸುವ ಉಳಿದೆಲ್ಲವೂ, L2TP ನಿಂದ ಡೌನ್ಲೋಡ್ ಮಾಡಿದ ಪ್ರೊಫೈಲ್ವರೆಗೆ, ಆ ಮೇಲ್ಮೈಯ ಹೊರಗಿದೆ ಅಥವಾ Apple ಗೆ ಖಾಸಗಿ.

ನಂತರ ಬರುವ ವೈಫಲ್ಯಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಬಗ್ಗಳಲ್ಲ. ಅದು ಎಂದಿಗೂ ನೀಡದ ಕೆಲಸವನ್ನು API ನಿರಾಕರಿಸುತ್ತಿದೆ, ಮತ್ತು ಪರಿಹಾರವೆಂದರೆ API ಒಡೆತನದಲ್ಲಿರುವುದರ ಸುತ್ತ ಪರದೆಯನ್ನು ವಿನ್ಯಾಸ ಮಾಡುವುದು.

ಮೂರು ಪ್ರೋಟೋಕಾಲ್ ವಸ್ತುಗಳು ಮತ್ತು ಇಲ್ಲದಿರುವವು

ನಿಮ್ಮ ಆಯ್ಕೆಗಳು: NEVPNProtocolIPSec ಮೂಲಕ IKEv1, NEVPNProtocolIKEv2 ಮೂಲಕ IKEv2, ಮತ್ತು ನಿಮ್ಮದೇ ಪ್ಯಾಕೆಟ್ ಟನೆಲ್ ವಿಸ್ತರಣೆಯನ್ನು ನೀಡಿದರೆ NETunnelProviderProtocol. NEVPNManager ಉಲ್ಲೇಖ ಸ್ವೀಕರಿಸಲಾದ ಪ್ರೋಟೋಕಾಲ್ ವಸ್ತುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. L2TP ಮತ್ತು PPTP ಆ ಪಟ್ಟಿಯಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ Apple ಅವುಗಳಿಗೆ ಯಾವುದೇ ವರ್ಗವನ್ನು ಪ್ರಕಟಿಸಿಲ್ಲ. ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಪ್ರಯತ್ನಿಸುವುದು ಉಳಿಸುವ ಸಮಯದಲ್ಲಿ ದೋಷದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಅಥವಾ ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ, ಸಿಸ್ಟಂ ಮೌನವಾಗಿ ಬಳಸಲು ನಿರಾಕರಿಸುವ ಸಂರಚನೆಯೊಂದಿಗೆ.

ಡೆಸ್ಕ್ಟಾಪ್ ಕೋಡ್ ಬೇರೆ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ. macOS ನಲ್ಲಿ SCNetworkInterfaceCreateWithInterface IPv4 ಮೇಲಿನ L2TP ನಂತಹ ಇಂಟರ್ಫೇಸ್ ಪ್ರಕಾರವನ್ನು ಜೋಡಿಸಿ ಅದನ್ನು ನೆಟ್ವರ್ಕ್ ಸೇವೆಗೆ ಜೋಡಿಸುತ್ತದೆ, ಮತ್ತು networksetup -connectpppoeservice ಫಲಿತಾಂಶವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ನಿರ್ವಾಹಕ ಹಕ್ಕುಗಳು ಮತ್ತು ಸಹಾಯಕ ಸಾಧನ ಬೇಕು, ಏಕೆಂದರೆ ಹಂಚಿದ ರಹಸ್ಯ ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಸಿಸ್ಟಂ ಕೀಚೈನ್ಗೆ ಹೋಗುತ್ತವೆ. ಆ ವಿನ್ಯಾಸವನ್ನು iOS ಗೆ ನಕಲಿಸಿ, ಏನೂ ಕಂಪೈಲ್ ಆಗುವುದಿಲ್ಲ.

ಪಾಸ್ವರ್ಡ್ ಅಲ್ಲ, ಕೀಚೈನ್ ಉಲ್ಲೇಖವನ್ನು ನೀಡಿ

ಯಾವುದೇ IKE ವರ್ಗವು ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಪಠ್ಯವಾಗಿ ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. passwordReference ಮತ್ತು sharedSecretReference ಎಂಬ ಎರಡು ಗುಣಲಕ್ಷಣಗಳು ಶಾಶ್ವತ ಕೀಚೈನ್ ಉಲ್ಲೇಖವನ್ನು ಬಯಸುತ್ತವೆ, ಅದನ್ನು kSecReturnPersistentRef ಕೇಳಿ SecItemCopyMatching ನಿಂದ ಪಡೆಯುತ್ತೀರಿ. ಐಟಂ ಡೇಟಾವನ್ನು ರವಾನಿಸುವುದು, ಅಥವಾ ಕ್ಷೇತ್ರಕ್ಕೆ ಸ್ಟ್ರಿಂಗ್ ಸೇರಿಸುವುದು, ಉಳಿಸುವ ವೈಫಲ್ಯ ಅಥವಾ ಖಾಲಿ ರುಜುವಾತುಗಳಿರುವ ಸಂಪರ್ಕವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಉಲ್ಲೇಖವು ಅದರ ಹಿಂದಿನ ಕೀಚೈನ್ ಐಟಂನಷ್ಟೇ ಬಾಳಿಕೆ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂರಚನೆಯನ್ನು ಜೋಡಿಸುವ ಮೊದಲು ಐಟಂ ಇರಬೇಕು. ಉಳಿಸುವಿಕೆಯ ಅದೇ ವಹಿವಾಟಿನಲ್ಲಿ ಅದನ್ನು ರಚಿಸಿ ಮತ್ತು ಕ್ರಮದ ಬಗ್ಗಳ ಸಂಪೂರ್ಣ ವರ್ಗವನ್ನು ತೆಗೆದುಹಾಕುತ್ತೀರಿ.

ಪ್ರಮಾಣಪತ್ರ ದೃಢೀಕರಣವು ಬೇರೆ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: PKCS#12 ಬ್ಲಾಬ್ಗಾಗಿ identityData ಜೊತೆಗೆ identityDataPassword. ಆ ಬ್ಲಾಬ್ ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಬಂಡಲ್ನೊಳಗೆ ಕಳುಹಿಸುವುದು ಮಾದರಿ ಕೋಡ್ನಿಂದ ಬಂದ ಅಭ್ಯಾಸ, ಬಿಡುಗಡೆಯ ನಿರ್ಧಾರವಲ್ಲ, ಏಕೆಂದರೆ ಪಾಸ್ವರ್ಡ್ ಅದರೊಂದಿಗೆ ಪ್ರಯಾಣಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ಪ್ರತಿ ಪ್ರತಿಯೂ ಅದೇ ಗುರುತನ್ನು ಹೊಂದಿರುತ್ತದೆ.

ಅಧಿಕಾರ ಮತ್ತು ಲಭ್ಯತೆ ಎಲ್ಲವನ್ನೂ ನಿಯಂತ್ರಿಸುತ್ತವೆ

ನಿರ್ವಾಹಕನು ಇಲ್ಲದೇ ಇರಬಹುದು, ಮತ್ತು ಕಾರಣ ಪ್ರೊವಿಷನಿಂಗ್. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಐಡೆಂಟಿಫೈಯರ್ಗೆ Network Extension ಸಾಮರ್ಥ್ಯ ಮತ್ತು ವೈಯಕ್ತಿಕ VPN ಅಧಿಕಾರ ಎರಡೂ ಬೇಕು, ಮತ್ತು ಬಿಲ್ಡ್ಗೆ ಸಹಿ ಮಾಡುವ ಪ್ರೊಫೈಲ್ ಎರಡನ್ನೂ ಹೊಂದಿರಬೇಕು.

ಇದನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟರೆ ಹಂಚಿದ ಇನ್ಸ್ಟನ್ಸ್ nil ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಅಥವಾ ಅಧಿಕಾರವನ್ನು ಎಂದಿಗೂ ಉಲ್ಲೇಖಿಸದ ದೋಷದೊಂದಿಗೆ ಉಳಿಸುವಿಕೆ ವಿಫಲವಾಗುತ್ತದೆ. ಲಭ್ಯತೆ ಇನ್ನೊಂದು ದ್ವಾರ. iOS 8 ಗಿಂತ ಹಳೆಯದನ್ನು ಗುರಿಯಾಗಿಸಿದರೆ ರನ್ಟೈಮ್ನಲ್ಲಿ ಚಿಹ್ನೆ ಇರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ವೈಫಲ್ಯವು ಕ್ರ್ಯಾಶ್ ಅಥವಾ nil ನಿರ್ವಾಹಕ, ಸಂರಚನೆಯಿಲ್ಲದ ನಿರ್ವಾಹಕವಲ್ಲ. ನಿಮ್ಮ ವಸ್ತು ಗ್ರಾಫ್ ಅನ್ನು ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ರನ್ಟೈಮ್ ಮತ್ತು ಅಧಿಕಾರವನ್ನು ಪರಿಶೀಲಿಸಿ.

ಲೋಡ್ ಮಾಡಿ, ಬದಲಾಯಿಸಿ, ಉಳಿಸಿ, ನಂತರ ಆನ್-ಡಿಮಾಂಡ್ ಕ್ರಮವನ್ನು ಗಮನಿಸಿ

ಜೀವನಚಕ್ರವನ್ನು ಲೋಡ್, ಬದಲಾವಣೆ, ಉಳಿಸುವಿಕೆ ಎಂದು ಪರಿಗಣಿಸಿ ಮತ್ತು ಲೋಡ್ ಅನ್ನು ಎಂದಿಗೂ ಬಿಟ್ಟುಬಿಡಬೇಡಿ. loadFromPreferences ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ನಿರ್ವಾಹಕನು ಏನನ್ನೂ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ವಸ್ತುವನ್ನು ಓದಲು ಅಥವಾ ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಎರಡನೇ ಉಳಿಸುವಿಕೆ ಇನ್ನೊಂದನ್ನು ಸೇರಿಸುವ ಬದಲು ಸಂರಚನೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅರ್ಧ ಮುಗಿದ ಉಳಿಸುವಿಕೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಹಾನಿಗೊಳಿಸಬಹುದು. ಆನ್-ಡಿಮಾಂಡ್ ನಿಯಮಗಳು ಕ್ರಮಬದ್ಧ ರಚನೆಯನ್ನು ರೂಪಿಸುತ್ತವೆ, ಮತ್ತು ಆ ಕ್ರಮವೇ ನೀತಿ. ಎಲ್ಲಿಂದಲಾದರೂ ಸಂಪರ್ಕಿಸುವ ನಿಯಮವನ್ನು ಸಂಪರ್ಕ ಕಡಿತ ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು ಇರಿಸಿ, ಮತ್ತು ಕೈಯಿಂದ ಸಂಪರ್ಕ ಕಡಿತದ ನಂತರ ತಕ್ಷಣ ಮರುಸಂಪರ್ಕ ಸಂಭವಿಸುತ್ತದೆ, ಅದು ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ ಆದರೆ ದಾಖಲಿತ ಮೌಲ್ಯಮಾಪನವನ್ನು ಅನುಸರಿಸುತ್ತದೆ.

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