ZeroTier ಮೇಲೆ HTTP ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆಯೇ? ಓವರ್ಲೇ ಎಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ ಎಂದು ನೋಡಿ
ZeroTier ಪೀರ್-ಟು-ಪೀರ್ ಹಾಪ್ಗಳನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ, ರೌಟರ್ ಅಥವಾ ಬ್ರಿಡ್ಜ್ನ ಹಿಂದಿನ LAN ಭಾಗವನ್ನಲ್ಲ. ಸಾಮಾನ್ಯ HTTP ಅನ್ನು ಸುರಕ್ಷಿತ ಎಂದು ಹೇಳುವ ಮೊದಲು ಓವರ್ಲೇ ಎಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ ಎಂದು ನೋಡಿ.
ಈ ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಮೊದಲನೆಯದು ವಿಫಲವಾದಲ್ಲೇ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಉತ್ತರವೂ ಮುಂದಿನ ಹಂತದ ಅರ್ಥವನ್ನು ಬದಲಿಸುತ್ತದೆ. ನಿಜವಾದ ಪ್ರಶ್ನೆ ಸಂಕುಚಿತವಾಗಿದೆ: ZeroTier ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಸಾಮಾನ್ಯ HTTP ಇಂಟರ್ನೆಟ್ ಮೇಲೆ ತೆರೆದುಕೊಂಡು ಹೋಗುತ್ತದೆಯೇ? ಎರಡು ZeroTier ಪೀರ್ಗಳ ನಡುವೆ ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲ, ಏಕೆಂದರೆ ಓವರ್ಲೇ ಆ ಹಾಪ್ ಅನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ. ಆದರೆ ಅದು ಎರಡು ತುದಿಗಳ ಬಗ್ಗೆ ಹೇಳಿಕೆ, ವಿನಂತಿ ದಾಟುವ ಪ್ರತಿ ವಿಭಾಗದ ಬಗ್ಗೆ ಅಲ್ಲ. ರೌಟರ್, ಬ್ರಿಡ್ಜ್ ಅಥವಾ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ತುದಿಯನ್ನು ಸರಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಆಚೆ ಬದಿಯಲ್ಲಿ ಸ್ಪಷ್ಟ ಪಠ್ಯ ಮತ್ತೆ ಆರಂಭವಾಗುತ್ತದೆ.
ಪರಿಶೀಲನೆ 1: ಬ್ರೌಸರ್ ಸಂಪರ್ಕಿಸುವ ವಿಳಾಸವನ್ನು ಹುಡುಕಿ
URL ಅನ್ನು ಯಂತ್ರದಲ್ಲಿ ನಿಜವಾಗಿ ಇರುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ. ip -brief addr show zt ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಕಂಟ್ರೋಲರ್ ನೀಡಿದ ಓವರ್ಲೇ ವಿಳಾಸವನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ; URL ಆ ವಿಳಾಸವನ್ನು ಬಳಸಿದರೆ, ಬ್ರೌಸರ್ನ ಸಾಕೆಟ್ ಓವರ್ಲೇ ಒಳಗೆ ಹೋಗುತ್ತದೆ.
ಹೆಸರು ಬದಲಿಗೆ LAN ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಿದರೆ, ಕ್ಲೈಂಟ್ನ ಸ್ಥಿತಿ ಸೂಚಕ ಏನೇ ಸೂಚಿಸಿದರೂ, ಓವರ್ಲೇ ಒಳಗೊಂಡಿರದೇ ಇರಬಹುದು. ip route get 10.147.20.5 ಕರ್ನೆಲ್ ಆಯ್ಕೆ ಮಾಡುವ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮೂಲ ವಿಳಾಸವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಲ್ಲಿ zt ಇಂಟರ್ಫೇಸ್ ಎಂದರೆ ಪ್ಯಾಕೆಟ್ ಓವರ್ಲೇ ಒಳಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಭೌತಿಕ NIC ಹೆಸರು ಎಂದರೆ ಹೋಗುವುದಿಲ್ಲ. ಹೆಸರುಗಳು ಇನ್ನೊಂದು ಪದರ ಸೇರಿಸುತ್ತವೆ: ಓವರ್ಲೇ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುವ ದಾಖಲೆ LAN ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುವದಕ್ಕಿಂತ ಬೇರೆಯಾಗಿ ವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಹುಡುಕಾಟ ಸಫಿಕ್ಸ್ ಅಥವಾ hosts ಫೈಲ್ನ ನಮೂದು ಯಾವುದು ಸಿಗುತ್ತದೆ ಎಂಬುದನ್ನು ಸದ್ದಿಲ್ಲದೆ ನಿರ್ಧರಿಸಬಹುದು.
ಪರಿಶೀಲನೆ 2: ಎರಡೂ ತುದಿಗಳು ಪೀರ್ಗಳೇ, ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುವ ರಿಲೇ ಅಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ
ZeroTier ಪೀರ್ಗಳ ನಡುವೆ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ನೇರ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದಲ್ಲಿ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಇನ್ನೂ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿಯೇ ಕಳುಹಿಸುವ ಮೂಲದ ಮೂಲಕ ರವಾನಿಸಲಾಗುತ್ತದೆ. zerotier-cli peers ಪ್ರತಿ ಪೀರ್ನ ಮಾರ್ಗವನ್ನು ವಿಳಂಬ ಸಂಖ್ಯೆಯೊಂದಿಗೆ DIRECT ಅಥವಾ RELAY ಎಂದು ಗುರುತಿಸುತ್ತದೆ. ರವಾನೆಯಾದ ಮಾರ್ಗವು ಹೋಗಿ ಬರುವ ಪ್ರಯಾಣಗಳನ್ನು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ, ಗೋಪ್ಯತೆಯನ್ನಲ್ಲ.
ಉತ್ತರವನ್ನು ನಿಜವಾಗಿ ಬದಲಿಸುವುದು ನಿಜವಾದ ತುದಿಯಲ್ಲದ ಸದಸ್ಯ. ಎದುರು ಭಾಗವು ಭೌತಿಕ LAN ಗೆ ರೌಟ್ ಅಥವಾ ಬ್ರಿಡ್ಜ್ ಮಾಡುವ ZeroTier ಸದಸ್ಯನಾಗಿದ್ದರೆ, ಓವರ್ಲೇ ಆ ಸದಸ್ಯನಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ ಸಾಮಾನ್ಯ ಎಥರ್ನೆಟ್.
ಪರಿಶೀಲನೆ 3: ವಿನಂತಿ ಎಲ್ಲಿ ಓದಬಹುದಾದದ್ದಾಗುತ್ತದೆ ಎಂದು ನೋಡಿ
ಪುಟವನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ನೀವು ನಂಬುವ ಹೋಸ್ಟ್ನಲ್ಲಿ, ಮರುಲೋಡ್ ಮಾಡುವಾಗ ಓವರ್ಲೇ ಇಂಟರ್ಫೇಸ್ ಸೆರೆಹಿಡಿಯಿರಿ: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. ಆ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಓದಬಹುದಾದ ವಿನಂತಿ ಸಾಲು ಟ್ರಾಫಿಕ್ ಆ ಹೋಸ್ಟ್ಗೆ ಡೀಕ್ರಿಪ್ಟ್ ಆಗಿ ತಲುಪಿದೆ ಎಂದು ಸಾಬೀತು ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದೇ ನೀವು ಹುಡುಕುತ್ತಿರುವ ಗಡಿ.
ನಂತರ ಉಳಿದ LAN ಕಡೆಗೆ ನೋಡುವ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ. ಅದೇ ವಿನಂತಿ ಅಲ್ಲಿ ತೆರೆದುಕೊಂಡು ಕಂಡುಬಂದರೆ, ಅದು ಅಪ್ಲಿಕೇಶನ್ ತಲುಪುವ ಮೊದಲೇ ಓವರ್ಲೇ ಬಿಟ್ಟಿದೆ ಮತ್ತು ಆ ವಿಭಾಗದ ಪ್ರತಿ ಸಾಧನವೂ ಅದನ್ನು ಓದಬಹುದು. LAN ಬದಿಯಲ್ಲಿ ಏನೂ ಕಾಣದಿದ್ದರೂ ಪುಟ ಲೋಡ್ ಆದರೆ, ಅಪ್ಲಿಕೇಶನ್ ZeroTier ಹೋಸ್ಟ್ನಲ್ಲೇ ಮುಕ್ತಾಯಗೊಳ್ಳುತ್ತದೆ.
ಮುಂದೆ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಇದ್ದಾಗ ಲೂಪ್ಬ್ಯಾಕ್ ಸೆರೆಹಿಡಿಯುವುದೂ ಮುಖ್ಯ, ಏಕೆಂದರೆ HTTPS ಸ್ವೀಕರಿಸಿ HTTP ಮುಂದೆ ಕಳುಹಿಸುವ ಪ್ರಾಕ್ಸಿ ಗಡಿಯನ್ನು ತನ್ನದೇ ಬ್ಯಾಕೆಂಡ್ಗೆ ಸರಿಸುತ್ತದೆ.
ಪರಿಶೀಲನೆ 4: ರೌಟರ್ ಅಥವಾ ಬ್ರಿಡ್ಜ್ ಹಿಂದಿನ ಪ್ರತಿ ಹಾಪನ್ನು ಲೆಕ್ಕಿಸಿ
ಓವರ್ಲೇ ಮತ್ತು LAN ನಡುವೆ ರೌಟ್ ಮಾಡಲು ಸಂರಚಿಸಲಾದ ಸದಸ್ಯ ಸಾಮಾನ್ಯ ವಿನ್ಯಾಸ ಮತ್ತು ಈ ಊಹೆಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಮುರಿಯುವ ಸ್ಥಳ. ಓವರ್ಲೇ ಬ್ರೌಸರ್ನಿಂದ ರೌಟರ್ನವರೆಗಿನ ಭಾಗವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ, ಅದರ ನಂತರ ಏನನ್ನೂ ರಕ್ಷಿಸುವುದಿಲ್ಲ. ಬ್ರಿಡ್ಜ್ ಅದೇ ಕಥೆಯನ್ನು ಬೇರೆ ವಿಧಾನದಿಂದ ಹೇಳುತ್ತದೆ: ಓವರ್ಲೇ ಮತ್ತು ಭೌತಿಕ ವಿಭಾಗ ಒಂದೇ ಪ್ರಸಾರ ಡೊಮೇನ್ ಆಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಬ್ರಿಡ್ಜ್ ಮಾಡಿದ ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ ಬರುವ ವಿನಂತಿ ಸಾಮಾನ್ಯ ಎಥರ್ನೆಟ್ ದಾಟುತ್ತದೆ, ಆ ಲ್ಯಾಪ್ಟಾಪ್ ZeroTier ನೆಟ್ವರ್ಕ್ನಲ್ಲಿದ್ದರೂ.
ಊಹಿಸುವ ಬದಲು ಅದನ್ನು ಜಾಡಿಸಿ. ಕ್ಲೈಂಟ್ನಿಂದ ಸೇವಾ ವಿಳಾಸಕ್ಕೆ traceroute ಮತ್ತು ಗೇಟ್ವೇ ಸದಸ್ಯನ ಮಾರ್ಗಣೆ ಕೋಷ್ಟಕ ಕೊನೆಯ ಹಾಪ್ zt ಅಥವಾ eth ಎಂದು ತೋರಿಸುತ್ತವೆ.
ZeroTier ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ನಿಗದಿತ ಸ್ಥಳೀಯ ಮಾರ್ಗಗಳಲ್ಲಿ ಸಾಗಣೆ ಭದ್ರತೆಯನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದಾದ ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗ ಮೋಡ್ ಅನ್ನೂ ನೀಡುತ್ತದೆ. ಅದನ್ನು ಬಳಸುವ ನೆಟ್ವರ್ಕ್ ಸಾಮಾನ್ಯ ಎನ್ಕ್ರಿಪ್ಟೆಡ್ ಮಾರ್ಗದ ಊಹೆಯನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಒಂದನ್ನು ಉಲ್ಲೇಖಿಸುವ ಮೊದಲು ನೆಟ್ವರ್ಕ್ ಸಂರಚನೆಯನ್ನು ಓದಿ. ಪ್ರೋಟೋಕಾಲ್ ದಾಖಲೆ ಪೀರ್ ಎನ್ಕ್ರಿಪ್ಶನ್ ಮತ್ತು ಆ ವಿನಾಯಿತಿ ಎರಡನ್ನೂ ವಿವರಿಸುತ್ತದೆ.
ಪರಿಶೀಲನೆ 5: ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ಏನು ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ
ಓವರ್ಲೇ ಸದಸ್ಯತ್ವ ಸಾಧನವನ್ನು ನೆಟ್ವರ್ಕ್ಗೆ ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಆಚೆ ಬದಿಯ ಸೇವೆ ನೀವು ತಲುಪಲು ಉದ್ದೇಶಿಸಿದ್ದೇ ಎಂಬ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. HTTPS ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಹೋಸ್ಟ್ನಾಮ್ ಅನ್ನು ಕೀಲಿಗೆ ಬಂಧಿಸಿ ಉತ್ತರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡು ರಕ್ಷಣೆಗಳು ಪರಸ್ಪರ ಬದಲಾಯಿಸದೆ ಅತಿಕ್ರಮಿಸುತ್ತವೆ. ಅಧಿಕೃತ ಪೀರ್ ಕೂಡ ತಪ್ಪು ಸೇವೆಯಾಗಿರಬಹುದು, ಮತ್ತು ರಾಜಿ ಮಾಡಿದ ತುದಿ ವಿನಂತಿಯನ್ನು ಎನ್ಕ್ರಿಪ್ಶನ್ ಮೊದಲು ಮತ್ತು ಡೀಕ್ರಿಪ್ಶನ್ ನಂತರ ಎರಡೂ ಸಮಯದಲ್ಲಿ ಓದುತ್ತದೆ. ಯಾವುದೇ ವಿಧಾನ ಅಪ್ಲಿಕೇಶನ್ ಏನು ದಾಖಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಆಡಿಟ್ ಮಾಡುವುದಿಲ್ಲ.
ಮರುಬಳಕೆಯ ಸೆಶನ್ ಅಥವಾ ಪಾಸ್ವರ್ಡ್ ಇರುವ ಯಾವುದಕ್ಕೂ ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ಅಥವಾ ನೀವು ನಿಯಂತ್ರಿಸುವ ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ TLS ಮುಗಿಸಿ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಯನ್ನು ಆನ್ ಆಗಿಡಿ. ಹಳೆಯ ಸೇವೆ ಸಾಮಾನ್ಯ HTTP ನಲ್ಲೇ ಇರಬೇಕಾದರೆ, ಅದು ಬಳಸಬಹುದಾದ ನಿಖರ ಹೋಸ್ಟ್-ಟು-ಹೋಸ್ಟ್ ಮಾರ್ಗ, ಯಾರು ಅದನ್ನು ತಲುಪಬಹುದು ಮತ್ತು ಯಾವ ವಿಭಾಗ ರಕ್ಷಣೆ ಇಲ್ಲದೆ ಉಳಿಯುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ; ಭವಿಷ್ಯದ ವಿಮರ್ಶಕನಿಗೆ ಬೇಕಾಗುವುದು ಆ ಟಿಪ್ಪಣಿಯೇ.
"VPN ಸಂಪರ್ಕಗೊಂಡಿದೆ" ಇವುಗಳ ಯಾವುದಕ್ಕೂ ಮೌಲ್ಯಮಾಪನ ಅಲ್ಲ. ಪ್ರಾಮಾಣಿಕ ಆವೃತ್ತಿ ಎರಡೂ ತುದಿಗಳನ್ನು, ಅವುಗಳ ನಡುವಿನ ಮಾರ್ಗವನ್ನು ಮತ್ತು ಮುಚ್ಚದ ಮೊದಲ ಹಾಪ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ.
ಸೆರೆಹಿಡಿಯುವ ಔಟ್ಪುಟ್ ಮತ್ತು ಪೀರ್ ಪಟ್ಟಿಯನ್ನು ಸೇವಾ ದಾಖಲೆಯ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ, ಇದರಿಂದ ಮಾರ್ಗ ಬದಲಿಸುವ ಅಥವಾ ಬ್ರಿಡ್ಜ್ ಸೇರಿಸುವ ಯಾರಾದರೂ ಯಾವ ಊಹೆಯನ್ನು ಮುರಿಯಲಿದ್ದಾರೆ ಎಂದು ನೋಡಬಹುದು.