ಯಾವ macOS ಸಾಧನವು ಒಂದು ಆ್ಯಪ್ ಅನ್ನು VPN ಮೂಲಕವೇ ಹೋಗಲು ಒತ್ತಾಯಿಸಬಲ್ಲದು?
VPN-ಮಾತ್ರ ಗಡಿಗೆ ಮಾರ್ಗ ಮತ್ತು ನಿರಾಕರಣೆ ಎರಡೂ ಬೇಕು. ಪ್ರತಿ-ಆ್ಯಪ್ ಪ್ರೊಫೈಲ್, ಪ್ರಾಕ್ಸಿ, ಫಿಲ್ಟರ್ ಮತ್ತು PF ಹೋಲಿಸಿ, ನಂತರ ನಿಮಗೆ ಮುಖ್ಯವಾದ ಒಂದು ಆ್ಯಪ್ ಪರೀಕ್ಷಿಸಿ.
ಅಗತ್ಯತೆ-ದಾಖಲೆಯಲ್ಲಿ ಒಂದು ಸಾಲು — “ಈ ಆ್ಯಪ್ VPN ಬಳಸಬಹುದು, ಬೇರೆ ಏನೂ ಇಲ್ಲ” — ಯಾವುದೇ ಒಂದು ಸ್ವಿಚ್ ನೀಡದ ಎರಡು ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಮೆಲ್ಲನೆ ಕೇಳುತ್ತದೆ. ಸಂಚಾರಕ್ಕೆ ಉದ್ದೇಶಿತ ಸುರಂಗದ ಮೂಲಕ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ನೇರವಾಗಿ ಹೊರಹೋಗುವ ಸಂಚಾರವನ್ನು ನಿರಾಕರಿಸಬೇಕು. ಒಂದನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡಿ ಇನ್ನೊಂದನ್ನು ಸ್ವಲ್ಪವೂ ಮಾಡದ ಸಾಧನಗಳು ಸಾಮಾನ್ಯ, ಆದ್ದರಿಂದ ಏನಾದರೂ ತಡೆಯಬಹುದೇ ಎಂದು ಮಾತ್ರ ಕೇಳುವ ಹೋಲಿಕೆ ಪ್ರಶ್ನೆಯ ಅರ್ಧದಷ್ಟಕ್ಕೆ ವಿಶ್ವಾಸದಿಂದ ಉತ್ತರಿಸುತ್ತದೆ. ಮೊದಲು ಗಡಿಯನ್ನು ಬರೆಯಿರಿ, ನಂತರ ಅದರ ಎರಡೂ ಭಾಗಗಳನ್ನು ಆವರಿಸುವ ಘಟಕಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ.
ಒಂದು ವಾಕ್ಯದಲ್ಲಿ ಅಡಗಿರುವ ಎರಡು ಅಗತ್ಯತೆಗಳು
ಮಾರ್ಗದರ್ಶನ ಎಂದರೆ ಸಂಪರ್ಕವನ್ನು ಸುರಂಗ ಅಥವಾ ಪ್ರಾಕ್ಸಿಗೆ ಹಾಕುವ ಭಾಗ. ನಿರಾಕರಣೆ ಎಂದರೆ ಅದೇ ಸಂಪರ್ಕವು ಬೇರೆ ಯಾವುದೇ ಮಾರ್ಗದಿಂದ ಹೊರಹೋಗದಂತೆ ತಡೆಯುವ ಭಾಗ. ಬೇರೆ ಬೇರೆ ಘಟಕಗಳು ಅವನ್ನು ಅಳವಡಿಸುತ್ತವೆ, ಅವು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಒಂದು ಉತ್ಪನ್ನ ಒಂದರಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿದ್ದು ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳದಿರಬಹುದು:
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
ಕೋಷ್ಟಕವನ್ನು ಶ್ರೇಣೀಕರಣವಲ್ಲ, ಪರಿಶೀಲನಾ ಪಟ್ಟಿಯಾಗಿ ಓದಿ. ಯಾವುದೇ ಸಾಲು ಎರಡೂ ಮಧ್ಯ ಕಾಲಮ್‌ಗಳನ್ನು ತುಂಬುವುದಿಲ್ಲ, ಮತ್ತು ಅವನ್ನು ಆವರಿಸುವ ಸಾಲುಗಳು ಸಹಕರಿಸುವ ಎರಡು ಘಟಕಗಳು: ಒಂದು ಮಾರ್ಗದ ಮಾಲೀಕ, ಇನ್ನೊಂದು ನಿರಾಕರಣೆಯದು. ಗುರುತಿನ ಕಾಲಮ್ ಬೇರೆ ಕಾರಣಕ್ಕೆ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಆ್ಯಪ್ ಅನ್ನು ಹೆಸರಿಸಲಾಗದ ನಿಯಮವು ಆ ಆ್ಯಪ್ ಬಗ್ಗೆ ನಿಯಮವನ್ನು ಜಾರಿಗೊಳಿಸಲಾಗದು. ನೀವು ಏನೇ ನಿಯೋಜಿಸಿದರೂ ಅದು ಮೂರಕ್ಕೂ ಉತ್ತರಿಸಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಅಗತ್ಯತೆ-ದಾಖಲೆಯ ಗಡಿ ಯಂತ್ರದ ಮೇಲಿನ ಗಡಿಯಲ್ಲ.
ಮಾರ್ಗದರ್ಶನ ಒಂಟಿಯಾಗಿ ಹೊರಹೋಗುವ ದಾರಿ ಬಿಡುತ್ತದೆ
ಆ್ಯಪ್ಲಿಕೇಶನ್ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ನಿರಾಕರಣೆ ಇಲ್ಲದ ಮಾರ್ಗದರ್ಶನದ ಸ್ಪಷ್ಟ ಉದಾಹರಣೆ. ಸಿಸ್ಟಂ ಪ್ರಾಕ್ಸಿಯನ್ನು ಗೌರವಿಸುವ ಆ್ಯಪ್‌ನ ವಿನಂತಿಗಳನ್ನು ಮಾರ್ಗದರ್ಶಿಸಬಹುದು, ಮತ್ತು ಬೇರೆ ಏನನ್ನೂ ಆವರಿಸುವುದಿಲ್ಲ: ಸಹಾಯಕ ಪ್ರಕ್ರಿಯೆ, ಅಪ್‌ಡೇಟರ್, ಹಿನ್ನೆಲೆ ಸೇವೆ ಅಥವಾ ಬೇರೆ ಪ್ರೋಟೋಕಾಲ್ ಆ ಸೆಟ್ಟಿಂಗ್ ಓದದೆಯೇ ತಮ್ಮ ದಾರಿ ಹಿಡಿಯಬಹುದು. ಆದ್ದರಿಂದ ಒಂದು ಪ್ಯಾನೆಲ್‌ನಲ್ಲಿ SOCKS ಅಂತ್ಯಬಿಂದುವನ್ನು ಆಯ್ಕೆಮಾಡಿದರೆ ಆ್ಯಪ್‌ಗೆ ನೇರ ನಿರ್ಗಮನ ನಿಷೇಧದ ನೀತಿ ಉಂಟಾಗುವುದಿಲ್ಲ. ಅಗತ್ಯತೆ ಇಡೀ ಆ್ಯಪ್ ಬಗ್ಗೆ ಇದ್ದರೆ, ನಿಯಮವು ವಾಸ್ತವವಾಗಿ ಯಾವ ಘಟಕಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ ಎಂದು ಕೇಳಿ.
ಪ್ರತಿ-ಆ್ಯಪ್ VPN ಪ್ರೊಫೈಲ್ ಪ್ರಾಕ್ಸಿಗಿಂತ ಉತ್ತಮ ಮಾರ್ಗದರ್ಶನ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಯಾವ ಆ್ಯಪ್‌ಗಳು ಸುರಂಗ ಪ್ರವೇಶಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿರ್ಧರಿಸುತ್ತದೆ ಪ್ರತಿ ಆ್ಯಪ್ ತಾನೇ ನಿರ್ಧರಿಸುವ ಬದಲು. ಆದರೂ ಅದು ಯಾವುದನ್ನೂ ನಿರಾಕರಿಸುವುದಿಲ್ಲ: ಪ್ರೊಫೈಲ್ ಮಾರ್ಗ ನೀಡುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೆ ಹೊಂದದ ಸಂಚಾರ ಸಾಮಾನ್ಯ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಆ ಅಂತರವೇ ಎರಡನೇ ಘಟಕ ತನ್ನ ಸ್ಥಾನ ಗಳಿಸುವ ಸ್ಥಳ, ಮತ್ತು ಒಂದು ಸ್ವಿಚ್‌ನಂತೆ ಕಾಣುವ ಉತ್ಪನ್ನಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಆಗಿರುವುದಕ್ಕೆ ಅದೇ ಕಾರಣ.
ನಿರಾಕರಣೆ ಒಂಟಿಯಾಗಿ ಆ್ಯಪ್ ಮುರಿಯುತ್ತದೆ
Apple ನ ದಸ್ತಾವೇಜು ವಿಷಯ-ಫಿಲ್ಟರ್‌ಗಳ ಬಗ್ಗೆ ಜಾಲ ಸ್ಟಾಕ್ ಮೂಲಕ ಹಾದುಹೋಗುವ ಸಂಚಾರದ ಮೇಲಿನ ಅನುಮತಿ-ಅಥವಾ-ನಿರ್ಬಂಧ ತೀರ್ಪನ್ನು ವಿವರಿಸುತ್ತದೆ. ಆ ತೀರ್ಪು ಸುರಂಗವಲ್ಲ, ಪ್ರಾಕ್ಸಿ ಸಂಪರ್ಕವೂ ಅಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಏನಾದರೂ ಮುಂದುವರಿಯಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ, ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದಲ್ಲ. ಒಂಟಿ ಫಿಲ್ಟರ್ ನಿರಾಕರಣೆಯನ್ನು ಪರಿಪೂರ್ಣವಾಗಿ ಜಾರಿಗೊಳಿಸಿ ಆ್ಯಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರುಪಯುಕ್ತವಾಗಿ ಬಿಡುತ್ತದೆ, ಸ್ವಚ್ಛ ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಮತ್ತು ಯಾವುದೇ ವಿವರಣೆ ಇಲ್ಲದೆ. ಫಿಲ್ಟರ್ ತೀರ್ಪು ಸಂಪರ್ಕವನ್ನು ನಿಲ್ಲಿಸಬಹುದು ಆದರೆ ಎಂದಿಗೂ ಸುರಂಗ ನೀಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದನ್ನು ಮಾರ್ಗದರ್ಶನದೊಂದಿಗೆ ಜೋಡಿಸುವುದೇ ವಿನ್ಯಾಸದ ನಿರ್ಣಯ, ಐಚ್ಛಿಕ ಹೆಚ್ಚಳವಲ್ಲ.
ಸ್ಥಳೀಯವಾಗಿ ನಿರ್ವಹಿಸಲಾದ PF ನಿಯಮಸಮೂಹ ಆ ಸ್ಪೆಕ್ಟ್ರಮ್‌ನ ಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿದೆ. ಇದು ನಿರ್ವಾಹಕನ ಮಾಲೀಕತ್ವದ ಯಂತ್ರದಲ್ಲಿ ಕಾನೂನುಬದ್ಧ ಬೆಂಬಲ-ನಿರ್ಣಯ, ಮತ್ತು ವಿತರಣೀಯ ಉತ್ಪನ್ನದ ತಳಹದಿ ತಾನಾಗಿ ಆಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನಿಯಮಸಮೂಹದ ಮಾಲೀಕನೇ ಅದರ ಇತರ ಫೈರ್‌ವಾಲ್ ಬಳಕೆದಾರರೊಂದಿಗಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಳ, ಅದರ ನವೀಕರಣ ಮಾರ್ಗದ ಮತ್ತು ನಿಯಮ ತಪ್ಪಾದಾಗ ಅದರ ಮರುಪ್ರಾಪ್ತಿಯ ಮಾಲೀಕನೂ ಆಗಿರುತ್ತಾನೆ. ಉತ್ಪನ್ನಕ್ಕೆ PF ಸೇರಿಸುವುದು ಆ ಮಾಲೀಕತ್ವದ ಪ್ರಶ್ನೆಯನ್ನು ತೆಗೆಯುವುದಿಲ್ಲ; ಅದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ.
ನಿಯೋಜನೆಯೇ ನಿಯಮ ನಾಳೆಯೂ ಇರುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ
Apple ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ Network Extension ಹೇಗೆ ನಿಯೋಜಿಸಲ್ಪಡುತ್ತದೆ ಎಂಬುದು ನಿಮ್ಮ ಮುಂದಿರುವ ಪೂರೈಕೆದಾರ ಪ್ರಕಾರ, ಪ್ಯಾಕೇಜಿಂಗ್ ಮತ್ತು OS ಆವೃತ್ತಿಯನ್ನು ಅವಲಂಬಿಸಿದೆ. macOS ನಲ್ಲಿ ಆ್ಯಪ್ ವಿಸ್ತರಣೆ ಬಳಕೆದಾರ ಸಂದರ್ಭದಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಆ ಬಳಕೆದಾರ ಲಾಗ್ ಔಟ್ ಆದಾಗ ಮುಗಿಯುತ್ತದೆ, ಆದರೆ ಸಿಸ್ಟಂ ವಿಸ್ತರಣೆಗೆ ಅಧಿವೇಶನವನ್ನು ಅವಲಂಬಿಸದ ಜಾಗತಿಕ ಸಂದರ್ಭ ಇರುತ್ತದೆ. ಸಂರಕ್ಷಣೆ ಲಾಗ್ ಔಟ್ ಅನ್ನು ಮೀರಿ ಉಳಿಯಬೇಕಿದ್ದರೆ ಆ ವ್ಯತ್ಯಾಸವೇ ಇಡೀ ವಿನ್ಯಾಸ, ಅಡಿಟಿಪ್ಪಣಿಯಲ್ಲ. ವರ್ತನೆಯ ಭರವಸೆ ನೀಡುವ ಮೊದಲು ನಿಯೋಜನೆ ಮಾರ್ಗವನ್ನು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಅದೇ ಕೋಡ್ ಯಾವ ವಿಸ್ತರಣೆ ಪ್ರಕಾರ ಕಳುಹಿಸಲ್ಪಡುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಬೇರೆಯಾಗಿ ಇಳಿಯುತ್ತದೆ.
ಮೂಲದ ಲಭ್ಯತೆ ಜಾರಿಗೊಳಿಸುವಿಕೆಗಿಂತ ಬೇರೆ ವಿಷಯ. ಸಂಗ್ರಹವನ್ನು ಓದುವುದು ಏನಾದರೂ ಹೇಗೆ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಈ ಯಂತ್ರದಲ್ಲಿ ಸ್ಥಾಪಿತ ಬೈನರಿ ಏನು ಮಾಡಬಹುದು ಎಂದಲ್ಲ. ಸಹಿ, ಸ್ಥಾಪನೆ ಮತ್ತು ಅಧಿಕಾರ ಇನ್ನೂ ಅನ್ವಯಿಸುತ್ತವೆ, ಮತ್ತು ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಕರ್ನಲ್ ವಿಸ್ತರಣೆ ಅಥವಾ ಲೈಬ್ರರಿ-ಇಂಜೆಕ್ಷನ್ ಉಪಾಯದ ಸುತ್ತ ಕಟ್ಟಿದ ಸೂಚನೆಗಳು ಬೇರೆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮತ್ತು ಬೇರೆ ಅಪಾಯದ ನಿಲುವನ್ನು ವಿವರಿಸುತ್ತವೆ, ಒಂದಾನೊಂದು ಕಾಲದಲ್ಲಿ ಎಷ್ಟೇ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಿದ್ದರೂ.
ಆ್ಯಪ್ ಅನ್ನು ಹೆಸರಿಸುವ ಸ್ವೀಕೃತಿ ಪ್ರಕರಣ
ಆ್ಯಪ್ ತಾನಾಗಿ ಮಾಡುವ ಒಂದು ಕ್ರಿಯೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿ, ಅದು ತಲುಪಬೇಕಾದ ವಿಳಾಸ ಮತ್ತು ಆ ವಿಳಾಸ IPv4 ಅಥವಾ IPv6 ಎಂಬುದನ್ನು ಗಮನಿಸಿ, ನಂತರ ಅನುಮೋದಿತ ಸುರಂಗ-ರಹಿತ ಸ್ಥಿತಿಯಲ್ಲಿ ಅದೇ ಕ್ರಿಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಎರಡನೇ ನಡೆಸುವಿಕೆ ಘೋಷಿತ ನಿರಾಕರಣೆಯನ್ನು ನೀಡಬೇಕು, ಮೌನ ನೇರ ಮರುಪ್ರಯತ್ನವನ್ನಲ್ಲ. ಅದೇ ಜನರು ನಿರ್ದಿಷ್ಟಪಡಿಸದೆ ಬಿಡುವ ಅರ್ಧ, ಮತ್ತು ನಿರಾಕರಣೆ ಇದೆಯೇ ಎಂದು ಸಾಬೀತುಪಡಿಸುವ ಏಕೈಕ ಅರ್ಧ. ಮೊದಲು ಸುರಂಗ ಲಭ್ಯವಿದ್ದಾಗ ನಡೆಸಿ, ಎರಡು ಫಲಿತಾಂಶಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಕಾಣೆಯಾದ ಸುರಂಗದಿಂದ ಮಾತ್ರ ಬರಬಹುದು.
ನಂತರ ಅಗತ್ಯತೆ ಹೆಸರಿಸುವ ಪರಿವರ್ತನೆಗಳನ್ನು ನಡೆಯಿರಿ: ಆ್ಯಪ್ ಮರುಪ್ರಾರಂಭ, ಸಹಾಯಕ ಪ್ರಕ್ರಿಯೆ ಪ್ರಚೋದನೆ, ಸುರಂಗ ಮರುಸಂಪರ್ಕ, ಯಂತ್ರದ ಜಾಲ ಬದಲಾವಣೆ, ಮತ್ತು ಅನ್ವಯಿಸುವಲ್ಲಿ ಲಾಗ್ ಔಟ್ ಅಥವಾ ಮರುಬೂಟ್. ಬ್ರೌಸರ್‌ನ ಸಾರ್ವಜನಿಕ-IP ಪುಟವು ಬೇರೆ ಆ್ಯಪ್ಲಿಕೇಶನ್ ಸಾಕೆಟ್‌ಗಳ ಪರೀಕ್ಷೆಯಲ್ಲ, ಆದ್ದರಿಂದ ಅದು ಇದನ್ನು ಬದಲಿಸಲಾರದು. ಯಾವುದೇ ಬೆಂಬಲಿತ ನಿಯೋಜನೆಯು ಆ್ಯಪ್‌ನ ನಿಜವಾದ ವರ್ತನೆಯನ್ನು ಆವರಿಸದಿದ್ದರೆ, ಸ್ಪಷ್ಟ ಗೇಟ್‌ವೇ ಮತ್ತು ಪರ್ಯಾಯ ನಿರ್ಗಮನವಿಲ್ಲದ ಅಧಿಕೃತ ಪ್ರತ್ಯೇಕ ವಾತಾವರಣವು ತನ್ನದೇ ನಿರ್ವಹಣಾ ವೆಚ್ಚವಿರುವ ತಡೆಹಿಡಿಯುವ ನಿರ್ಣಯ, ಚೆಕ್‌ಬಾಕ್ಸ್‌ನ ಬದಲಿ ಅಲ್ಲ.
ನಾಲ್ಕು ನಮೂದುಗಳನ್ನು ಬರೆದು ಮುಗಿಸಿ: ಆ್ಯಪ್ ಯಾವ ಘಟಕಗಳಿಂದ ರೂಪುಗೊಂಡಿದೆ, ಮಾರ್ಗದರ್ಶನದ ಮಾಲೀಕ ಯಾರು, ನಿರಾಕರಣೆಯ ಮಾಲೀಕ ಯಾರು, ಮತ್ತು ನಿಯಮ ಇನ್ನೂ ಜಾರಿಯಲ್ಲಿರಬೇಕಾದ ಸ್ಥಿತಿಗಳು. ಸಾರ್ವಜನಿಕ ಸಂಗ್ರಹ ಆಯ್ಕೆಯ ಒಂದು ಮಾನದಂಡವಾಗಬಹುದು, ಆದರೆ ಅದು ನಾಲ್ಕರಲ್ಲಿ ಒಂದಲ್ಲ, ಮತ್ತು ಆ ನಮೂದುಗಳೇ ನಿರ್ದಿಷ್ಟ ಸಾಧನವು ಜಾಲ ಅಗತ್ಯತೆಯನ್ನು ಪೂರೈಸುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ.