TunnelCrack vs TunnelVision: ಪ್ರತಿಯೊಂದೂ ನಿಜವಾಗಿ ಏನನ್ನು ಮುರಿಯುತ್ತದೆ
TunnelCrack ಮತ್ತು TunnelVision ವಿಭಿನ್ನ ರೂಟಿಂಗ್ ವಿನಾಯಿತಿಗಳನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುತ್ತವೆ: ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ವಿನಾಯಿತಿ, ಸರ್ವರ್ ಮಾರ್ಗ ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಬಿಲ್ಡ್‌ಗೂ DHCP ಆಯ್ಕೆ 121 ಅನ್ನು ಪರಿಶೀಲಿಸಿ.
ಟನೆಲ್‌ನಿಂದ ಹೊರಹೋಗುವ ಯಾವುದೇ VPN ಸಂಚಾರಕ್ಕೆ ಎರಡು ಸಂಶೋಧನಾ ಹೆಸರುಗಳನ್ನು ಪರಸ್ಪರ ಬದಲಿಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅವುಗಳ ಹಿಂದಿನ ಕಾರ್ಯವಿಧಾನಗಳು ಒಂದೇ ಅಲ್ಲ. TunnelCrack ರೂಟಿಂಗ್ ವಿನಾಯಿತಿಗಳ ಎರಡು ಕುಟುಂಬಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ; TunnelVision ಅಂತಿಮ ಸಾಧನದಲ್ಲಿ DHCP ಒದಗಿಸುವ ಮಾರ್ಗವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಎರಡೂ ಎನ್‌ಕ್ರಿಪ್ಷನ್ ಮುರಿಯುವುದಿಲ್ಲ, ಮತ್ತು ಎರಡೂ ಇಂದು ನಿರ್ದಿಷ್ಟ ಕ್ಲೈಂಟ್ ಬಿಲ್ಡ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಹೇಳುವುದಿಲ್ಲ. ಐದು ಪರಿಶೀಲನೆಗಳು ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಶೀರ್ಷಿಕೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ.
ಮೊದಲ ಹಂತ: ನೀವು ಪರಿಶೀಲಿಸುತ್ತಿರುವ ಕಾರ್ಯವಿಧಾನಕ್ಕೆ ಹೆಸರಿಸಿ
ಆಗಸ್ಟ್ 2023 ರ TunnelCrack ಬಹಿರಂಗಪಡಿಸುವಿಕೆ ಎರಡು ದಾಳಿ ಕುಟುಂಬಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಸಂದರ್ಭದಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸೇರಿದೆ ಎಂದು ಪರಿಗಣಿಸುವ ಸಂಚಾರವು ಸ್ಥಳೀಯ ಪ್ರವೇಶ ವಿನಾಯಿತಿಯನ್ನು ಪಡೆದು ಟನೆಲ್‌ನಿಂದ ಹೊರಹೋಗುತ್ತದೆ. ಸರ್ವರ್ ವಿಳಾಸದ ಸಂದರ್ಭದಲ್ಲಿ, VPN ಸರ್ವರ್‌ಗೆ ತಲುಪಲು ಕ್ಲೈಂಟ್‌ಗೆ ಬೇಕಾದ ಮಾರ್ಗವು ಟನೆಲ್‌ನ ಹೊರಗಿದೆ, ಮತ್ತು ಆ ವಿಳಾಸವನ್ನು ನಿಯಂತ್ರಿಸುವ ವಿರೋಧಿಯು ಆ ವಿನಾಯಿತಿಯನ್ನು ಬಳಸಿಕೊಳ್ಳಬಹುದು.
TunnelVision DHCP ಒದಗಿಸುವ ವರ್ಗರಹಿತ ಸ್ಥಿರ ಮಾರ್ಗಗಳ ಬಗ್ಗೆ ಪ್ರತ್ಯೇಕ ವರದಿಯಾಗಿದೆ. ದುರುದ್ದೇಶಪೂರ್ಣ DHCP ಸರ್ವರ್ ಅಂತಿಮ ಸಾಧನಕ್ಕೆ ಸಂಚಾರದ ಮಾರ್ಗವನ್ನು ಬದಲಿಸುವ ಮಾರ್ಗಗಳನ್ನು ನೀಡಬಹುದು, VPN ಸರ್ವರ್‌ನತ್ತ ಹೋಗುವ ಮಾರ್ಗ ಸೇರಿದಂತೆ. ವರದಿಯು ಸಂಬಂಧಿತ ರೂಟಿಂಗ್ ಪರಿಣಾಮಗಳ ಬಗ್ಗೆ ಹಿಂದಿನ ಕೆಲಸವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತದೆ, ಇದು ಮೂಲ ಕಾರ್ಯವಿಧಾನವು ಹೆಸರಿಗಿಂತ ಹಳೆಯದು ಎಂದು ನೆನಪಿಸುತ್ತದೆ.
| Case | Exception it abuses |
|---|---|
| TunnelCrack local network | Traffic classified as local bypasses the tunnel |
| TunnelCrack server address | The route to the VPN server sits outside the tunnel |
| TunnelVision | DHCP option 121 installs routes that redirect traffic |
ಹೆಸರುಗಳನ್ನು ಅವುಗಳ ಕಾರ್ಯವಿಧಾನಗಳಿಗೆ ಜೋಡಿಸಿ ಇರಿಸಿ. ಇನ್ನೊಂದು ಸುದ್ದಿಯಲ್ಲಿದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಒಂದಕ್ಕೆ ಸರಿಪಡಿಸುವಿಕೆ ಅನ್ವಯಿಸುವುದು ಪರಿಶೀಲನೆಯು ಕವರೇಜ್ ಇಲ್ಲದೆ ಚಲನೆ ಉತ್ಪಾದಿಸುವ ರೀತಿ.
ಎರಡನೇ ಹಂತ: ಸ್ಥಳೀಯ ಪ್ರವೇಶ ವಿನಾಯಿತಿಯನ್ನು ನೋಡಿ
ಬಹುಪಾಲು ಕ್ಲೈಂಟ್‌ಗಳು ಟನೆಲ್ ಸಕ್ರಿಯವಾಗಿರುವಾಗ ಮುದ್ರಕಗಳು, ಪರದೆ ಪ್ರಸಾರ ಮತ್ತು ಕಡತ ಹಂಚಿಕೆ ಕೆಲಸ ಮಾಡಲು ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಸಂಚಾರಕ್ಕೆ ವಿನಾಯಿತಿ ನೀಡುತ್ತವೆ. ಆ ವಿನಾಯಿತಿಯು ಭದ್ರತಾ ವೆಚ್ಚವಿರುವ ನೀತಿ ನಿರ್ಧಾರವಾಗಿದೆ: ಅದೇ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿರುವ ವಿರೋಧಿಯು ತನ್ನನ್ನು ಸ್ಥಳೀಯ ಹೋಸ್ಟ್ ಎಂದು ಪ್ರಸ್ತುತಪಡಿಸಬಹುದು, ಮತ್ತು ಅವನನ್ನು ತಲುಪುವ ಸಂಚಾರವು ಎಂದೂ ಟನೆಲ್‌ಗೆ ಪ್ರವೇಶಿಸಿಲ್ಲ.
ನಿಯೋಜಿತ ಪ್ರೊಫೈಲ್‌ಗೆ ಆ ವಿನಾಯಿತಿ ಎಲ್ಲಾದರೂ ಬೇಕೇ ಎಂದು ಕೇಳಿ. ಸ್ಥಳೀಯ ಅನ್ವೇಷಣೆಯನ್ನು ಎಂದೂ ಬಳಸದ ದೂರಸ್ಥ ಕಾರ್ಯಪಡೆ ಅದನ್ನು ಆಗಾಗ್ಗೆ ಆಫ್ ಮಾಡಬಹುದು, ಮತ್ತು ಉಳಿದ ಸ್ಥಳೀಯ ಸೇವೆಗಳನ್ನು ದಾಖಲಿತ ಮಾರ್ಗದ ಮೂಲಕ ತಲುಪಬಹುದು. ವಿನಾಯಿತಿ ಅಗತ್ಯವಿರುವಲ್ಲಿ, ಅದನ್ನು ಸ್ಥಳೀಯ ಸಂಚಾರ ಎಂದು ವಿವರಿಸುವ ಬದಲು ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ ಎಂದು ಹೇಳಿ.
ಪರಿಶೀಲನೆಯು ಸಂರಚನೆಯ ಪ್ರಶ್ನೆ, ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಅಲ್ಲ. ಪ್ರೊಫೈಲ್ ಸೆಟ್ಟಿಂಗ್ ಮತ್ತು ನೀವು ನಿಯೋಜಿಸುವ ಬಿಲ್ಡ್‌ನ ಕ್ಲೈಂಟ್ ದಾಖಲೆಗಳನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಡೀಫಾಲ್ಟ್ ಉತ್ಪನ್ನಗಳ ನಡುವೆ ಮತ್ತು ಒಂದೇ ಉತ್ಪನ್ನದ ಆವೃತ್ತಿಗಳ ನಡುವೆ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಉತ್ತರವನ್ನು ಪ್ರೊಫೈಲ್‌ನ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ, ಮುಂದಿನ ಪರಿಶೀಲಕನು ಅದನ್ನು ವರ್ತನೆಯಿಂದ ಊಹಿಸಬೇಕಾಗದಂತೆ. ಯಾರೂ ದಾಖಲಿಸದ ವಿನಾಯಿತಿ ಯಾರೂ ಪರಿಶೀಲಿಸದ ವಿನಾಯಿತಿ.
ಮೂರನೇ ಹಂತ: ಸರ್ವರ್ ವಿಳಾಸವನ್ನು ಹೇಗೆ ಕಲಿಯಲಾಗುತ್ತದೆ ಎಂದು ನೋಡಿ
ಯಾವುದೇ ಟನೆಲ್ ಇರುವ ಮೊದಲೇ ಕ್ಲೈಂಟ್ VPN ಸರ್ವರ್‌ಗೆ ತಲುಪಬೇಕು, ಆದ್ದರಿಂದ ಆ ಗಮ್ಯಸ್ಥಾನವು ವಿನ್ಯಾಸದಂತೆ ಟನೆಲ್‌ನ ಹೊರಗೆ ಮಾರ್ಗೀಕರಿಸಲ್ಪಡುತ್ತದೆ. ವಿಳಾಸವನ್ನು ಹೆಸರಿನಿಂದ ಕಲಿಯುವುದಾದರೆ, ಪರಿಹಾರದ ಹಂತವು ವಿಶ್ವಾಸ ಮಾರ್ಗದ ಭಾಗವಾಗಿದೆ, ಮತ್ತು ಆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಬಲ್ಲ ವಿರೋಧಿಯು ಕ್ಲೈಂಟ್ ಅನ್ನು ತಾನು ನಿಯಂತ್ರಿಸುವ ಹೋಸ್ಟ್‌ಗೆ ಕಳುಹಿಸಬಹುದು.
ವಿಳಾಸವನ್ನು ಪಿನ್ ಮಾಡುವುದು, ಸರಿಯಾದ ಹೆಸರಿನ ಪರಿಶೀಲಿತ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬಳಸುವುದು ಮತ್ತು ಪರಿಶೀಲಿಸದ ಸರ್ವರ್‌ಗೆ ಹಿಂತಿರುಗಲು ನಿರಾಕರಿಸುವುದು ಎಲ್ಲವೂ ಒಡ್ಡಿಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತವೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಟನೆಲ್‌ನ ಹೊರಗೆ ಸರ್ವರ್ ತಲುಪುವ ಅಗತ್ಯವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ; ಅವು ಆ ವಿಳಾಸಕ್ಕೆ ಯಾರು ಉತ್ತರಿಸಬಹುದು ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತವೆ.
resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule showಮಾರ್ಗ ಹುಡುಕಾಟವು ಸರ್ವರ್ ವಿಳಾಸಕ್ಕೆ ಕ್ಲೈಂಟ್ ಬಳಸುವ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ, ಅದು ವಿನಾಯಿತಿಯ ಮೂರ್ತ ರೂಪ. ಆ ಹುಡುಕಾಟವು ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, ಕ್ಲೈಂಟ್ ಟನೆಲ್ ಸ್ಥಾಪಿಸಲೇ ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಹೊರಗಿನ ಮಾರ್ಗ ನಿರೀಕ್ಷಿತವಾಗಿದೆ ಮತ್ತು ಪ್ರಶ್ನೆ ಅದರ ಗಮ್ಯಸ್ಥಾನ ಹೇಗೆ ಆಯ್ಕೆಯಾಗುತ್ತದೆ ಎಂಬುದಷ್ಟೇ.
ನಾಲ್ಕನೇ ಹಂತ: DHCP ಒದಗಿಸುವ ಮಾರ್ಗಗಳನ್ನು ನೋಡಿ
ವರ್ಗರಹಿತ ಸ್ಥಿರ ಮಾರ್ಗಗಳು DHCP ಸರ್ವರ್‌ಗೆ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದ ನಮೂದುಗಳನ್ನು ವಿತರಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತವೆ, ಮತ್ತು ಅಂತಿಮ ಸಾಧನವು ಸಾಮಾನ್ಯವಾಗಿ ಕೇಳದೆ ಅವುಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ವಿರೋಧಿಯು ಕಾನೂನುಬದ್ಧ ಸರ್ವರ್‌ಗಿಂತ ವೇಗವಾಗಿ DHCP ಉತ್ತರಿಸಬಲ್ಲ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ, ಆ ನಮೂದುಗಳು ಬಳಕೆದಾರನು ಟನೆಲ್‌ನೊಳಗೆ ಇದೆ ಎಂದು ಭಾವಿಸುವ ಸಂಚಾರವನ್ನು ಬೇರೆಡೆಗೆ ತಿರುಗಿಸಬಹುದು.
ಅಂತಿಮ ಸಾಧನದ ಮಾರ್ಗಗಳನ್ನು ನೀವು ನಿರೀಕ್ಷಿಸುವ ಮಾರ್ಗಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. ಟನೆಲ್ ಸಕ್ರಿಯವಾಗಿರುವಾಗ ಸ್ಥಳೀಯ ಗೇಟ್‌ವೇ ಕಡೆಗೆ ತೋರಿಸುವ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಅಥವಾ ಅಗಲವಾದ ಪೂರ್ವಪ್ರತ್ಯಯವು ತನಿಖೆಗೆ ಅರ್ಹವಾದ ಸಹಿ, ಮತ್ತು ಅದು ಯಾವುದೇ ದಾಳಿ ಸಂಚಾರವಿಲ್ಲದೆ ಗೋಚರಿಸುತ್ತದೆ.
ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"ಕೊನೆಯ ಸೆಟ್ಟಿಂಗ್ ಅಂತಿಮ ಸಾಧನದ ಕಡೆಯ ನಿಯಂತ್ರಣವಾಗಿದ್ದು, ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ವೇದಿಕೆಗಳು ಯಾವುದೋ ರೂಪದಲ್ಲಿ ಒದಗಿಸುತ್ತವೆ: ನೆಟ್‌ವರ್ಕ್ ಒದಗಿಸುವ ಮಾರ್ಗಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಿ. ಸ್ವಯಂಚಾಲಿತ ಮಾರ್ಗ ಸ್ವೀಕೃತಿಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ವಿನಿಮಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಅದು ಉದ್ಯಮ DHCP ಸರ್ವರ್‌ನಿಂದ ಕಾನೂನುಬದ್ಧ ವಿಭಜಿತ ರೂಟಿಂಗ್ ಅನ್ನೂ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಜಾಗತಿಕವಾಗಿ ಅಲ್ಲ, ನೆಟ್‌ವರ್ಕ್ ವರ್ಗದ ಪ್ರಕಾರ ನಿರ್ಧರಿಸಿ.
ಐದನೇ ಹಂತ: ಪ್ರಕಟಣೆಯನ್ನು ಪ್ರಸ್ತುತ ಬಿಲ್ಡ್‌ನಿಂದ ಬೇರ್ಪಡಿಸಿ
ಪ್ರಕಟಿತ ದಾಳಿಯು ನಿರ್ದಿಷ್ಟ ಸಮಯದಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಗಮನಿಸಿದ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅದು ನಿಮ್ಮ ಮುಂದಿರುವ ಲ್ಯಾಪ್‌ಟಾಪ್ ಬಾಧಿತವಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ ಎಂದೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಎರಡೂ ಹೇಳಿಕೆಗಳಿಗೂ ನಿಜವಾದ ಬಿಲ್ಡ್ ಸಂಖ್ಯೆ ಮತ್ತು ಮಾರಾಟಗಾರರ ಪ್ರಸ್ತುತ ಪ್ರಕಟಣೆ ಬೇಕು.
ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿ, ವೇದಿಕೆ, ಮೇಲಿನ ವಿನಾಯಿತಿಗಳನ್ನು ನಿಯಂತ್ರಿಸುವ ಪ್ರೊಫೈಲ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ನೀವು ಪರಿಶೀಲಿಸಿದ ದಿನಾಂಕವನ್ನು ದಾಖಲಿಸಿ. ಆ ದಾಖಲೆ ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹಳೆಯದಾಗುತ್ತದೆ, ಆದರೆ TunnelCrack ಗಾಗಿ VPN ಪ್ಯಾಚ್ ಆಗಿದೆ ಎಂಬ ಟಿಪ್ಪಣಿ ಹಾಗೆ ಹಳೆಯದಾಗುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ ನವೀಕರಣವಾದಾಗಲೆಲ್ಲ ಅದನ್ನು ಮತ್ತೆ ಓದಿ, ಏಕೆಂದರೆ ನೀವು ಮುಟ್ಟದ ಆವೃತ್ತಿಯ ಅಡಿಯಲ್ಲಿ ಪ್ರೊಫೈಲ್ ಡೀಫಾಲ್ಟ್ ಬದಲಾಗಬಹುದು.
ನೀವು ನಿಜವಾಗಿ ಮಾನ್ಯಗೊಳಿಸುವಾಗ, ಅನುಮೋದಿತ ಯೋಜನೆಯನ್ನು ನಿಮ್ಮದೇ ಅಂತಿಮ ಸಾಧನ ಮತ್ತು ಹಾನಿಕರವಲ್ಲದ ಗಮ್ಯಸ್ಥಾನದ ವಿರುದ್ಧ ಬಳಸಿ. ಹಂಚಿದ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಇತರ ಬಳಕೆದಾರರ ವಿರುದ್ಧ ದಾಳಿಯನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದು ಪರೀಕ್ಷೆ ಅಲ್ಲ, ಮತ್ತು ವೀಕ್ಷಣೆಯನ್ನು ಸುಲಭಗೊಳಿಸಲು ಪೀರ್ ಪರಿಶೀಲನೆ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಎನ್‌ಕ್ರಿಪ್ಷನ್ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ನೀವು ಅಳೆಯಲು ಪ್ರಯತ್ನಿಸಿದ ರಕ್ಷಣೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ಕೊನೆಯದಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ರಕ್ಷಣೆಯನ್ನು ಚಿತ್ರದಲ್ಲಿ ಇರಿಸಿ. ರೂಟಿಂಗ್ ವಿನಾಯಿತಿಯು ಟನೆಲ್ ಒಯ್ಯುತ್ತಿದ್ದ ಸಂಚಾರವನ್ನು ಒಡ್ಡಬಹುದು, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ TLS ಇನ್ನೂ ಆ ಸಂಚಾರವನ್ನು ತುದಿಯಿಂದ ತುದಿಗೆ ರಕ್ಷಿಸುತ್ತದೆ. ಎರಡು ಪದರಗಳು ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಸಂಪರ್ಕಿತ ನಿಯಂತ್ರಣ ಚಾನಲ್ ಪ್ರತಿ ಹರಿವು ಉದ್ದೇಶಿತ ಮಾರ್ಗದಲ್ಲಿ ಹೋಯಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ.