Android VPN ಟನೆಲ್ನಿಂದ ಸಬ್ನೆಟ್ ಅನ್ನು ಹೇಗೆ ಹೊರಗಿಡುವುದು

Android ನ VpnService ಗೆ ಯಾವುದೇ ಹೊರಗಿಡುವ ಮಾರ್ಗವಿಲ್ಲ, ಮತ್ತು API ಓದುವ ಯಾವುದೇ ಪ್ರಮಾಣವೂ ಒಂದನ್ನು ಉತ್ಪಾದಿಸುವುದಿಲ್ಲ. Builder.addRoute() ಟನೆಲ್ಗೆ ಯಾವಾಗಲೂ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಮಾತ್ರ ಸೇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ LAN ವಿಭಾಗವನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಇರಿಸುವುದು ಎಂದರೆ ಆ ವಿಭಾಗ ಎಂದಿಗೂ ಮಾರ್ಗ ಪಟ್ಟಿಗೆ ಪ್ರವೇಶಿಸುವುದಿಲ್ಲ. ಬದಲಾಗಿ ನೀವು ಸೇರಿಸುವುದು ವಿಭಾಗದ ಪೂರಕ, ಸಾಮಾನ್ಯ ಪ್ರಿಫಿಕ್ಸ್ಗಳಾಗಿ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ. ಕೆಲಸ ಅಂಕಗಣಿತ, ಮತ್ತು ಅದು ಕೆಲವು ಊಹಿಸಬಹುದಾದ ಸ್ಥಳಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.

ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ. ಪ್ರತಿಯೊಂದೂ ಹಿಂದಿನದು ನಿಂತಿದೆ ಎಂದು ಊಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಳಗಿನ ಲಕ್ಷಣಗಳನ್ನು ಪ್ಯಾಚ್ ಮಾಡುವ ಬದಲು ಮೊದಲ ವೈಫಲ್ಯದಲ್ಲಿ ನಿಲ್ಲಿಸಿ.

ಟನೆಲ್ ಏನು ಹೇಳಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ

0.0.0.0/0 ಅನ್ನು addRoute() ಗೆ ರವಾನಿಸುವುದು Android ಗೆ ಪ್ರತಿ IPv4 ಗಮ್ಯಸ್ಥಾನವೂ ಟನೆಲ್ಗೆ ಸೇರಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಅದಕ್ಕೇ ಇಷ್ಟು ಕ್ಲೈಂಟ್ಗಳು ವಿಭಜಿತ ಟನೆಲಿಂಗ್ಗೆ ಅಸಮರ್ಥವಾಗಿ ಕಾಣುತ್ತವೆ: ಅವು ಇಡೀ ವಿಳಾಸ ಸ್ಥಳಾವಕಾಶವನ್ನು ಕ್ಲೈಮ್ ಮಾಡಿ ನಂತರ ಅದರಿಂದ ಕಳೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ನಿರ್ಮಾಪಕದಲ್ಲಿ ಯಾವುದೂ ಕಳೆಯುವುದಿಲ್ಲ. ನೀವು ಸ್ಥಳೀಯವಾಗಿ ಇರಿಸಿಕೊಳ್ಳಲು ಬಯಸಿದ ಜಾಲಕ್ಕೆ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾದ ಮಾರ್ಗವು ಜನರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ವರ್ತಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಉದ್ದವಾದ ಹೊಂದುವ ಪ್ರಿಫಿಕ್ಸ್ ಗೆಲ್ಲುತ್ತದೆ ಮತ್ತು ಆ ಜಾಲ ಟನೆಲ್ನ ಒಳಗೆ ಬಂದು ಬೀಳುತ್ತದೆ.

ಮಾರ್ಗ ಪಟ್ಟಿಯೇ ಇಡೀ ನೀತಿ. ಅದರ ಹಿಂದೆ ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನಕ್ಕೂ ವೀಟೋ ಇಲ್ಲ, ಮತ್ತು Builder ಉಲ್ಲೇಖ ಅಂತಹ ಒಂದನ್ನು ಒದಗಿಸುವ ಯಾವುದೇ ವಿಧಾನವನ್ನು ಪಟ್ಟಿ ಮಾಡುವುದಿಲ್ಲ.

ಪ್ರಿಫಿಕ್ಸ್ ಅಂಕಗಣಿತದಿಂದ ಪೂರಕವನ್ನು ರಚಿಸಿ

ಹೊರಗಿಟ್ಟ ಪ್ರಿಫಿಕ್ಸ್ನ ಪೂರಕವು ವಿಳಾಸ ವೃಕ್ಷದ ಮೂಲಕ್ಕೆ ಹೋಗುವ ದಾರಿಯಲ್ಲಿ ಅದರ ಒಡಹುಟ್ಟಿದವರ ಗುಂಪು. 1 ರಿಂದ ಹೊರಗಿಟ್ಟ ಉದ್ದದವರೆಗೆ ಪ್ರತಿ ಉದ್ದಕ್ಕೂ, ನಿಮ್ಮ ಪ್ರಿಫಿಕ್ಸ್ ಹೊಂದಿರುವ ಆ ಉದ್ದದ ಬ್ಲಾಕ್ ತೆಗೆದುಕೊಂಡು, ಪ್ರಿಫಿಕ್ಸ್ನ ನೇರ ಕೆಳಗಿನ ಬಿಟ್ ಅನ್ನು ತಿರುಗಿಸಿ ಫಲಿತಾಂಶವನ್ನು ನೀಡಿ. ನೀವು ಅದನ್ನು ಚಲಾಯಿಸುವವರೆಗೆ ಅದು ಅಮೂರ್ತವಾಗಿ ಕೇಳುತ್ತದೆ.

10.0.0.0/8 ಹೊರಗಿಟ್ಟರೆ ಎಂಟು ಮಾರ್ಗಗಳು ಸಿಗುತ್ತವೆ: 128.0.0.0/1, 64.0.0.0/2, 32.0.0.0/3, 16.0.0.0/4, 0.0.0.0/5, 12.0.0.0/6, 8.0.0.0/7, 11.0.0.0/8. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ 10.0.0.0/8 ಹೊಂದಿಲ್ಲ, ಮತ್ತು ಒಟ್ಟಾಗಿ ಅವು ಉಳಿದ ಎಲ್ಲವನ್ನೂ ಆವರಿಸುತ್ತವೆ.

ಎಂಟು ಸಾಲುಗಳು ಯಾವುದೇ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಆ ಪಟ್ಟಿಯನ್ನು ರಚಿಸುತ್ತವೆ:

import ipaddress
def complement(addr, length):
    base = int(ipaddress.IPv4Address(addr))
    out = []
    for k in range(1, length + 1):
        block = base & (0xFFFFFFFF << (32 - k))
        sibling = block ^ (1 << (32 - k))
        out.append(f"{ipaddress.IPv4Address(sibling)}/{k}")
    return out
print(complement("10.0.0.0", 8))

ಮಾರ್ಗಗಳ ಸಂಖ್ಯೆ ಪ್ರಿಫಿಕ್ಸ್ನ ಉದ್ದಕ್ಕೆ ಸಮ, ಮತ್ತು ಅದೇ ಗಮನಿಸಬೇಕಾದ ಸಂಖ್ಯೆ. ಒಂದೇ /21 ಹೊರಗಿಡುವಿಕೆ 21 ಮಾರ್ಗಗಳನ್ನು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ ಮತ್ತು ಓದಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಹತ್ತು ಹೊರಗಿಡುವಿಕೆಗಳು ಕೆಲವು ನೂರು ವೆಚ್ಚವಾಗಬಹುದು, ಇದರ ಅರ್ಥ ಸಾಮಾನ್ಯವಾಗಿ ಜನರೇಟರ್ ಅಲ್ಲ, ಜಾಲ ವಿನ್ಯಾಸ ಬದಲಾಗಬೇಕು ಎಂದು.

ವಿಳಾಸ ಕುಟುಂಬ ಮತ್ತು ಟನೆಲ್ನ ವ್ಯಾಪ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ

IPv4 ಮಾರ್ಗಗಳು IPv6 ಗೆ ಏನೂ ಮಾಡುವುದಿಲ್ಲ. ಟನೆಲ್ IPv6 ವಿಳಾಸವನ್ನು ಕ್ಲೈಮ್ ಮಾಡಿದರೆ, IPv6 LAN ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಅದರದೇ ಪೂರಕ ಬೇಕು, ಅದು 128 ಬಿಟ್ಗಳ ಮೇಲೆ ಅದೇ ಅಂಕಗಣಿತದಿಂದ ರಚನೆಯಾಗುತ್ತದೆ. ಕಾಗದದ ಮೇಲೆ ಹೊರಗಿಡುವಿಕೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೂ ಸ್ಥಳೀಯ ಸಾಧನ ತಲುಪಲಾಗದೆ ಉಳಿಯುವ ಸಾಮಾನ್ಯ ಕಾರಣ ಇದು: ಹೋಸ್ಟ್ ಅನ್ನು IPv6 ಮೂಲಕ ತಲುಪಲಾಗಿತ್ತು, ಮತ್ತು IPv4 ಮಾತ್ರ ಕತ್ತರಿಸಲಾಗಿತ್ತು. ಅಂಕಗಣಿತ ತಪ್ಪು ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಎರಡೂ ಕುಟುಂಬಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

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

DNS ಮತ್ತು ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ನಿಯಮಗಳನ್ನು ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ

ಮಾರ್ಗ ಹೊರಗಿಡುವಿಕೆಗಳು ರಿಜೋಲ್ವರ್ ಅನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಸ್ಥಳೀಯ ಹೋಸ್ಟ್ನಾಮ್ ಇನ್ನೂ ಟನೆಲ್ನ DNS ಸರ್ವರ್ನಿಂದ ಉತ್ತರ ಪಡೆಯಬಹುದು, ಅದರ ವಿಳಾಸ ಸ್ಥಳೀಯವಾಗಿ ಮಾರ್ಗವಾಗುತ್ತಿರುವಾಗ, ಮತ್ತು ಅಸಂಗತಿ LAN ತಲುಪಲಾಗದ ವಸ್ತುವಿಗೆ ಪರಿಹರಿಸುವ ಹೆಸರಾಗಿ ಕಾಣುತ್ತದೆ. ರಿಜೋಲ್ವರ್ ನೀತಿಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹೊಂದಿಸಿ, ಹುಡುಕಾಟ ಡೊಮೇನ್ ಅಥವಾ ವಿಭಜಿತ DNS ನಿಯಮದೊಂದಿಗೆ. ಮಾರ್ಗಗಳು ನಿಮಗಾಗಿ ಅದನ್ನು ನಿರ್ಧರಿಸಿವೆ ಎಂದು ಊಹಿಸಬೇಡಿ.

addDisallowedApplication() ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಟನೆಲ್ನಿಂದ ಹೊರಗಿಡುತ್ತದೆ; ಒಳಗೆ ಉಳಿಯುವ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹೊರಗಿಡುವುದಿಲ್ಲ. protect() ನೀವು ತೆರೆಯುವ ಸಾಕೆಟ್ ಟನೆಲ್ ಅನ್ನು ಬಳಸಿಕೊಳ್ಳದಂತೆ ಬಿಡುತ್ತದೆ, ಹೀಗೆ ಟನೆಲ್ ತನ್ನದೇ ಸಾರಿಗೆಯನ್ನು ಹಿಡಿಯುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ಎರಡೂ ಪೂರಕವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ನಿಮ್ಮ ಸ್ವಂತ ಪಟ್ಟಿಯಿಂದ ಅಲ್ಲ, ಲುಕಪ್ನಿಂದ ಪರಿಶೀಲಿಸಿ

ಟನೆಲ್ ಮೇಲೆ ಬಂದ ನಂತರ, ನೀವು ನಿರ್ಮಿಸಿದ ಪಟ್ಟಿಯನ್ನು ಮತ್ತೆ ಓದುವ ಬದಲು ವಿಳಾಸ ನಿಜವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ಸಾಧನವನ್ನು ಕೇಳಿ. iproute2 ಹೊಂದಿರುವ ಬಿಲ್ಡ್ನಲ್ಲಿ, adb shell ip route get 10.1.2.3 ಕರ್ನೆಲ್ ಆಯ್ಕೆ ಮಾಡಿದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೂ ಅದೇ ಆದೇಶವನ್ನು ಚಲಾಯಿಸಿ ಮತ್ತು ಅದು ಟನೆಲ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.

ಇನ್ನೆರಡು ಪರಿಶೀಲನೆಗಳು ಚಕ್ರವನ್ನು ಮುಚ್ಚುತ್ತವೆ. ಮೊದಲು ಸ್ಥಳೀಯ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿ, ನಂತರ ಪರಿಹರಿಸಿದ ವಿಳಾಸದಲ್ಲಿ adb shell ip route get ಚಲಾಯಿಸಿ ಮತ್ತು ಟನೆಲ್ ಅಲ್ಲದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬೇಡಿ, ಏಕೆಂದರೆ ಯಶಸ್ವಿ adb shell ping -c 1 host.lan ತಲುಪುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮಾರ್ಗವನ್ನಲ್ಲ. ಟನೆಲ್ ಒಂದನ್ನು ಕ್ಲೈಮ್ ಮಾಡಿದರೆ IPv6 ಮೇಲೆ ವಿಳಾಸ-ಕುಟುಂಬ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ನೀವು ರವಾನಿಸುವ API ಮಟ್ಟದಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ VPN ಜಾಲಗಳು ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕಕ್ಕೆ ಹೇಗೆ ಒಡ್ಡಿಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದು ಬಿಡುಗಡೆಗಳ ನಡುವೆ ಬದಲಾಗಿದೆ. ಕಾಗದದ ಮೇಲೆ ಸರಿಯಾಗಿ ಕಾಣುವ ಮಾರ್ಗ ಪಟ್ಟಿ ಮತ್ತು ತಪ್ಪು ಇಂಟರ್ಫೇಸ್ ಆಯ್ಕೆ ಮಾಡುವ ಲುಕಪ್ ಬೇರೆ ಬೇರೆ ದೋಷಗಳು, ಮತ್ತು ಬಳಕೆದಾರರನ್ನು ತಲುಪುವುದು ಎರಡನೆಯದು ಮಾತ್ರ.

ಹೊರಗಿಡುವ ಪಟ್ಟಿ ಬೆಳೆಯುತ್ತಲೇ ಇದ್ದರೆ, ಮಾರ್ಗಗಳನ್ನು ರಚಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ದೂರದ ಜಾಲವನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡಿ ಅಥವಾ ಬದಲಾಗಿ ಟನೆಲ್ ಅನ್ನು ಸಂಕುಚಿಸಿ. ಜನರೇಟರ್ ಕಾಣೆಯಾದ API ಗೆ ಒಂದು ಪರ್ಯಾಯ ಮಾರ್ಗ, ವಿನ್ಯಾಸ ಸಾಧನವಲ್ಲ.