Android VPN ರೂಟಿಂಗ್: main ಕೋಷ್ಟಕಕ್ಕಿಂತ ಮೊದಲು ನೀತಿ ನಿಯಮಗಳು
Android ಯಾವುದೇ ಗಮ್ಯಸ್ಥಾನ ಹುಡುಕಾಟಕ್ಕಿಂತ ಮೊದಲು uid ಮತ್ತು ಗುರುತು ನಿಯಮಗಳಿಂದ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ main ಗೆ ಸೇರಿಸಿದ ಮಾರ್ಗವನ್ನು ಎಂದಿಗೂ ಪರಿಶೀಲಿಸದಿರಬಹುದು.
Android ನಲ್ಲಿ main ಕೋಷ್ಟಕಕ್ಕೆ ಸೇರಿಸಿದ ಮಾರ್ಗವು ಪ್ರತಿ ಪಟ್ಟಿಯಲ್ಲೂ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಆದರೂ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುವುದಿಲ್ಲ. ಕಾರಣವೆಂದರೆ main ಕೋಷ್ಟಕವು ಹಲವು ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದು, ಮತ್ತು ಅದನ್ನು ಮೊದಲು ಕೇಳಲಾಗುವುದಿಲ್ಲ. Android ನ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಸೇವೆಯು ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸದಲ್ಲಿ ಇಲ್ಲದ ಮಾಹಿತಿಯಿಂದ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ನೀತಿ ನಿಯಮಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ — ಅಪ್ಲಿಕೇಶನ್‌ನ uid, ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿನ ಗುರುತು, ಅದು ಬಂದ ಇಂಟರ್ಫೇಸ್ — ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಹುಡುಕಾಟವು ನಂತರ, ಆ ನಿಯಮಗಳು ಆಯ್ಕೆ ಮಾಡಿದ ಕೋಷ್ಟಕದ ಒಳಗೆ ನಡೆಯುತ್ತದೆ.
ನಿಗದಿತ ಕ್ರಮದಲ್ಲಿ ಮೂರು ನಿರ್ಣಯಗಳು
ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ ಮೂರು ಪ್ರತ್ಯೇಕ ನಿರ್ಣಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ಒಂದು ನೀತಿ ನಿಯಮ ಯಾವ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ಆ ಕೋಷ್ಟಕದೊಳಗಿನ ಮಾರ್ಗವು ಮುಂದಿನ ಹಾಪ್ ಮತ್ತು ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಮೂರನೆಯದಾಗಿ, netfilter ಕೊಕ್ಕೆಗಳು ಪ್ಯಾಕೆಟ್ ಉಳಿಯುತ್ತದೆಯೇ, ಬದಲಾಗುತ್ತದೆಯೇ ಅಥವಾ ಮರುನಿರ್ದೇಶನಗೊಳ್ಳುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ.
ಕ್ರಮವು ಮುಖ್ಯ ಏಕೆಂದರೆ ಪ್ರತಿ ಹಂತವು ತನ್ನದೇ ಪ್ರಶ್ನೆಗೆ ಮಾತ್ರ ಉತ್ತರಿಸಬಲ್ಲದು. ಪ್ಯಾಕೆಟ್ ಸ್ವೀಕರಿಸುವ ಫೈರ್‌ವಾಲ್ ನಿಯಮವು ಕೋಷ್ಟಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವ ನಿಯಮವೂ ಆಯ್ಕೆ ಮಾಡದ ಕೋಷ್ಟಕಕ್ಕೆ ಸೇರಿಸಿದ ಮಾರ್ಗವು ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತದೆ. Android VPN ಗಳ ಸುತ್ತಲಿನ ಬಹಳಷ್ಟು ಗೊಂದಲವು ಮೂರರಲ್ಲಿ ಒಂದನ್ನು ಸರಿಪಡಿಸಿ ಯಾವುದೇ ಬದಲಾವಣೆ ಕಾಣದಿರುವುದರಿಂದ ಬರುತ್ತದೆ, ಏಕೆಂದರೆ ದೋಷವು ಇನ್ನೊಂದರಲ್ಲಿತ್ತು.
| Stage | Selector | What it cannot decide |
|---|---|---|
| Policy rule | uid range, mark, incoming interface | Which route exists inside the table |
| Route lookup | Destination prefix, longest match | Whether the packet is allowed out |
| Netfilter hook | Chain position, match conditions | Which table was selected |
ಗುರುತುಗಳು ಪ್ಯಾಕ್ ಮಾಡಿದ ಕ್ಷೇತ್ರ, ನಿಮ್ಮ ಸ್ವಂತ ಲೇಬಲ್ ಅಲ್ಲ
Android ಹಲವು ಸಂಗತಿಗಳನ್ನು ಒಂದೇ ಗುರುತು ಮೌಲ್ಯದಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡುತ್ತದೆ: ಯಾವ ನೆಟ್‌ವರ್ಕ್ ಆಯ್ಕೆಯಾಯಿತು, ಅಪ್ಲಿಕೇಶನ್ ಸ್ಪಷ್ಟವಾಗಿ ನೆಟ್‌ವರ್ಕ್ ಆಯ್ಕೆ ಮಾಡಿದೆಯೇ, ಸಾಕೆಟ್ VPN ನಿಂದ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಮತ್ತು ಅನುಮತಿಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಬಿಟ್‌ಗಳು. AOSP ನ fwmark ಹೆಡರ್ ಪ್ರಸ್ತುತ ಮರಕ್ಕೆ ಆ ವಿನ್ಯಾಸವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಮತ್ತು ವಿನ್ಯಾಸವು ಬಿಡುಗಡೆಗಳ ನಡುವೆ ಬದಲಾಗುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆಂತರಿಕ ವಿವರವಾಗಿದೆ.
ಆದ್ದರಿಂದ Android ನಲ್ಲಿ iptables -j MARK --set-mark ಬಳಸಿ ಇಡೀ ಗುರುತು ಮೌಲ್ಯವನ್ನು ಬರೆಯುವುದು ಅಪಾಯಕಾರಿ. ಅದು ಟ್ಯಾಗ್ ಸೇರಿಸುವುದಿಲ್ಲ; ಸಿಸ್ಟಂ ಈಗಾಗಲೇ ಮಾಡಿದ ನೆಟ್‌ವರ್ಕ್ ಆಯ್ಕೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ. ನಂತರ ಪ್ಯಾಕೆಟ್ ಬೇರೆ ನಿಯಮಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ, ಇದು ಯಾವ ಬಿಟ್‌ಗಳನ್ನು ಮತ್ತೆ ಬರೆಯಲಾಯಿತು ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ VPN ಕೆಲಸ ಆರಂಭಿಸಿದಂತೆ ಅಥವಾ ಸಂಬಂಧವಿಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕ ಕಳೆದುಕೊಂಡಂತೆ ಕಾಣಬಹುದು.
ಗುರುತುಗಳನ್ನು ಮುಟ್ಟಬೇಕಾದರೆ, ಮೊದಲು ಪ್ರಸ್ತುತ ಮೌಲ್ಯವನ್ನು ಓದಿ ಮತ್ತು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡ ಬಿಟ್‌ಗಳು ಮಾತ್ರ ಬದಲಾಗುವಂತೆ ಮಾಸ್ಕ್ ಬಳಸಿ:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11ಸಂಪರ್ಕ ಗುರುತು ಪ್ಯಾಕೆಟ್ ಗುರುತಿನಿಂದ ಪ್ರತ್ಯೇಕ ವಸ್ತು, ಮತ್ತು ಎರಡೂ ಮಾರ್ಗವಲ್ಲ. ಉತ್ತರ ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ ಗುರುತನ್ನು ಮರುಸ್ಥಾಪಿಸುವುದು ಹೊರಹೋಗುವಾಗ ಕೋಷ್ಟಕ ಆಯ್ಕೆ ಮಾಡುವುದಕ್ಕಿಂತ ಬೇರೆ ಹಂತ, ಆದ್ದರಿಂದ ಏಕಮುಖ ಸರಿಪಡಿಸುವಿಕೆಗಳು ತೆರೆದು ನಂತರ ನೇತಾಡುವ ಸಂಪರ್ಕಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.
ನಿಯಮಗಳು ಮತ್ತು ಕೋಷ್ಟಕಗಳ ಮಾಲೀಕರು ಯಾರು
Android ನ ನೆಟ್‌ವರ್ಕ್ ಸೇವೆ, netd, ನಿಯಮಗಳನ್ನು ಮತ್ತು ಪ್ರತಿ ನೆಟ್‌ವರ್ಕ್ ಕೋಷ್ಟಕಗಳನ್ನು ರಚಿಸುತ್ತದೆ. AOSP RouteController ಎಂಬುದು VPN, ಭೌತಿಕ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು uid ಶ್ರೇಣಿಗಳಿಗಾಗಿ ಆ ನಿಯಮಗಳನ್ನು ಜೋಡಿಸುವ ಸ್ಥಳ, ಮತ್ತು ಅದರ ಜೀವನಚಕ್ರವು ಕಾನ್ಫಿಗ್ ಫೈಲ್‌ಗಿಂತ ನೆಟ್‌ವರ್ಕ್ ಘಟನೆಗಳಿಗೆ ಬದ್ಧವಾಗಿದೆ.
ಎರಡು ಪರಿಣಾಮಗಳು ಉಂಟಾಗುತ್ತವೆ. ಮೊದಲನೆಯದಾಗಿ, ಒಂದು ಹ್ಯಾಂಡ್‌ಸೆಟ್‌ನಲ್ಲಿ ಕಂಡುಬರುವ ಆದ್ಯತೆಗಳು ಮತ್ತು ಕೋಷ್ಟಕ ಸಂಖ್ಯೆಗಳು ಬಿಲ್ಡ್‌ನ ಆಂತರಿಕ ವಿವರಗಳು, ಇಂಟರ್ಫೇಸ್ ಅಲ್ಲ: ಬೇರೆ Android ಆವೃತ್ತಿಯಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಸಂಖ್ಯೆಗಳು ಸಂಪೂರ್ಣ ಬೇರೆ ಅರ್ಥವನ್ನು ನೀಡಬಹುದು. ಎರಡನೆಯದಾಗಿ, ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಬದಲಾದಾಗ ಸ್ಥಿತಿಯನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಇಂದು root ಶೆಲ್‌ನಿಂದ ಸೇರಿಸಿದ ನಿಯಮವು ಮುಂದಿನ Wi-Fi ಬದಲಾವಣೆಯ ನಂತರ ಮಾಯವಾಗಿರಬಹುದು.
ಈ ಮಾಯವಾಗುವಿಕೆಯನ್ನು ಸಿಸ್ಟಂ ಮಾರ್ಗವನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತಿದೆ ಎಂದು ಹೆಚ್ಚಾಗಿ ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ ಸಂಭವಿಸಿದ್ದು, ಕೋಷ್ಟಕವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ ನಿಯಮವು ಇನ್ನಿಲ್ಲ, ಮತ್ತು ಕೋಷ್ಟಕದೊಳಗಿನ ಮಾರ್ಗವು ಈಗ ಪ್ಯಾಕೆಟ್‌ನ ದೃಷ್ಟಿಯಿಂದ ತಲುಪಲಾಗದ್ದಾಗಿದೆ. ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಸಂರಚನೆಯು ಮರುಸಂಪರ್ಕದ ನಂತರ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ, ಮಾರ್ಗ ಪಟ್ಟಿಯಲ್ಲ, ನಿಯಮ ಪಟ್ಟಿಯನ್ನು ಪರಿಶೀಲಿಸಿ.
ಕೊಕ್ಕೆಗಳ ಕ್ರಮದ ಪ್ರಶ್ನೆಗಳಿಗೆ ಸಾರ್ವತ್ರಿಕ ಉತ್ತರವಿಲ್ಲ
iptables VPN ರೂಟಿಂಗ್‌ಗಿಂತ ಮೊದಲು ಚಲಿಸುತ್ತದೆಯೇ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಪ್ಯಾಕೆಟ್‌ನ ಮಾರ್ಗವನ್ನು ಹೆಸರಿಸದೆ ಉತ್ತರಿಸಲಾಗದು. ಸ್ಥಳೀಯವಾಗಿ ರಚಿಸಿದ ಪ್ಯಾಕೆಟ್ output ಕೊಕ್ಕೆಯ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ, ಅಲ್ಲಿ ಗುರುತಿನ ಬದಲಾವಣೆಯು ಮರುರೂಟಿಂಗ್ ಪರಿಶೀಲನೆಯನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ — ಎರಡನೇ ಹುಡುಕಾಟ, ಮೊದಲನೆಯದರ ಹಿಂದಿನ ತಿದ್ದುಪಡಿ ಅಲ್ಲ. tether ಮಾಡಿದ ಕ್ಲೈಂಟ್‌ನಿಂದ ಬರುವ ಪ್ಯಾಕೆಟ್ prerouting ಮಾರ್ಗದ ಮೂಲಕ ಹೋಗಿ ಬದಲಿಗೆ ಮುಂದಕ್ಕೆ ರವಾನೆಯಾಗುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ನೋಡುವ ಸರಪಣಿಗಳು ಬೇರೆಯಾಗಿವೆ.
ಹಾಗಾಗಿ ಒಂದೇ ನಿಯಮವು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂಚಾರಕ್ಕೆ ಪರಿಣಾಮಕಾರಿ ಮತ್ತು tether ಸಂಚಾರಕ್ಕೆ ಅಗೋಚರವಾಗಿರಬಹುದು, ಮತ್ತು ಶೂನ್ಯದಲ್ಲೇ ಉಳಿಯುವ ಕೌಂಟರ್ ಪ್ಯಾಕೆಟ್ ಯಾವ ಮಾರ್ಗ ತೆಗೆದುಕೊಂಡಿತು ಎಂದು ಹೇಳುತ್ತದೆ, ನಿಯಮ ತಪ್ಪಿದೆಯೇ ಎಂದಲ್ಲ. ಯಾವುದೇ ಹೊಂದಾಣಿಕೆ ಷರತ್ತನ್ನು ಬದಲಿಸುವ ಮೊದಲು ಕೌಂಟರ್‌ಗಳಿಂದ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸಿ.
ನೀತಿ ರೂಟಿಂಗ್ ದೋಷವು ಕಾಣಲು ಕಷ್ಟವಾಗುವ ಹಂತ ಇದೂ ಕೂಡ. ಇರುವ ಆದರೆ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹೊಂದಿರದ ಕೋಷ್ಟಕಕ್ಕೆ ರೂಟಿಂಗ್ ಮಾಡುವುದು ಫೈರ್‌ವಾಲ್ ಡ್ರಾಪ್‌ನಂತೆ ಕಾಣುವ ನೆಟ್‌ವರ್ಕ್ ತಲುಪಲಾಗದ್ದನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಆದರೆ ಫೈರ್‌ವಾಲ್ ಡ್ರಾಪ್ ರೂಟಿಂಗ್ ಕಪ್ಪು ಕುಳಿಯಂತೆ ಕಾಣುವ ಕಾಲಾವಧಿ ಮುಗಿತವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಸಿಸ್ಟಂನ ಒಳಗೆ ರೋಗನಿರ್ಣಯ ಮಾಡಿ, ಅಥವಾ ಅದನ್ನು ಬಿಡಿ
ಅಧಿಕೃತ ಪರಿಶೀಲನೆಗಾಗಿ, ಏನನ್ನೂ ಮುಟ್ಟುವ ಮೊದಲು ನಾಲ್ಕು ಸಂಗತಿಗಳನ್ನು ಸ್ಥಾಪಿಸಿ: ಅಪ್ಲಿಕೇಶನ್‌ನ uid ಮತ್ತು ಪ್ರೊಫೈಲ್, Android ಅದಕ್ಕಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ ನೆಟ್‌ವರ್ಕ್, VPN ಆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆಯೇ, ಮತ್ತು ಸಮಸ್ಯೆಯು ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳಲ್ಲಿ ಇದೆಯೇ. ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಹೊರಗಿಡುವಿಕೆಯು ಯಾವುದೇ ರೂಟಿಂಗ್ ದೋಷವಿಲ್ಲದೆ VPN ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ ಎಂಬ ಅನೇಕ ವರದಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.
ನಂತರ ನಿಜವಾಗಿ ಜಾರಿಯಲ್ಲಿರುವ ನಿಯಮಗಳು, ಮಾಸ್ಕ್‌ಗಳು ಮತ್ತು ಕೋಷ್ಟಕಗಳನ್ನು ಓದಿ, ಮತ್ತು ವೀಕ್ಷಣಾ ವಿಂಡೋದೊಳಗೆ ಒಂದು ನೆಟ್‌ವರ್ಕ್ ಬದಲಾವಣೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ಮರುಸಂಪರ್ಕದ ಉದ್ದಕ್ಕೂ ವರ್ತನೆ ಬದಲಾದರೆ, ನೀವು ನಿರ್ವಹಿತ ಜೀವನಚಕ್ರವನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ, ಕಾಣೆಯಾದ ಮಾರ್ಗವನ್ನಲ್ಲ.
ಸಾಮಾನ್ಯ ಅವಶ್ಯಕತೆಗಳಿಗೆ ಬೆಂಬಲಿತ ನಿಯಂತ್ರಣಗಳನ್ನು ಬಳಸಿ: ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಸೇರ್ಪಡೆ ಮತ್ತು ಹೊರಗಿಡುವಿಕೆ VPN ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗ ಬೇಕಾದ ಯಾವುದಕ್ಕೂ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಸ್ವಂತ ನೆಟ್‌ವರ್ಕ್ ಆಯ್ಕೆ. ವಿಶೇಷಾಧಿಕಾರದ ಏಕೀಕರಣವು ನಿಜವಾಗಿ ರೂಟಿಂಗ್ ಯಂತ್ರದೊಂದಿಗೆ ಸಹಕರಿಸಬೇಕಿದ್ದರೆ, ನೀವು ಬೆಂಬಲಿಸುವ ನಿಖರವಾದ Android ಆವೃತ್ತಿಯ ಅನುಷ್ಠಾನವನ್ನು ಗುರಿಯಾಗಿಸಿ ಮತ್ತು ಅದನ್ನು ಹೊಂದಿರುವ ಘಟಕದ ಮೂಲಕ ಅದರ ಜೀವನಚಕ್ರವನ್ನು ನಿರ್ವಹಿಸಿ. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸರಪಣಿಗಳನ್ನು ಫ್ಲಶ್ ಮಾಡುವುದು ಅಥವಾ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ನಿಯಮವನ್ನು ಸೇರಿಸುವುದು ರೋಗನಿರ್ಣಯವನ್ನು ಎರಡನೇ ನೆಟ್‌ವರ್ಕ್ ವ್ಯವಸ್ಥಾಪಕವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಫೋನ್ ಅದಕ್ಕನುಗುಣವಾಗಿ ವರ್ತಿಸುತ್ತದೆ.