ಕೇವಲ ವೆಬ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ VPN ಬ್ಲಾಕ್? ಪದರಗಳನ್ನು ಕೆಲಸ ಮಾಡಿ

ಬ್ರೌಸರ್ ಕೆಲಸ ಮಾಡುವ ಮತ್ತು ಪ್ರತಿ ಟನೆಲ್ ಸಾಯುವ ಕ್ಯಾಂಪಸ್ ಅಥವಾ ಹೋಟೆಲ್ ನೆಟ್‌ವರ್ಕ್ ಒಂದು ಸಮಸ್ಯೆ ಅಲ್ಲ, ನಾಲ್ಕು ಪದರಗಳು. ಮಾರ್ಗವು TCP 443 ಗೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡಬಹುದು, ದೃಢೀಕೃತ ಪ್ರಾಕ್ಸಿ ಬೇಡಬಹುದು, ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪರೀಕ್ಷಿಸಬಹುದು, ಅಥವಾ ನೀತಿಯಿಂದ ದೂರಸ್ಥ ಪ್ರವೇಶವನ್ನು ಸರಳವಾಗಿ ನಿಷೇಧಿಸಬಹುದು. ಅವನ್ನು ಕ್ರಮವಾಗಿ ನಿರ್ವಹಿಸುವುದು ನೆಟ್‌ವರ್ಕ್ ನಿಯಮ ಸರಿಪಡಿಸಲು ಹೊಸ ಕ್ಲೈಂಟ್ ಖರೀದಿಸುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ಕೆಳಗಿನ ಮಾರ್ಗದರ್ಶಿ ಸುಮಾರು ಹತ್ತು ನಿಮಿಷ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಯಾವ ಪದರ ನಿಮ್ಮನ್ನು ನಿರಾಕರಿಸಿತು ಎಂಬ ಲಿಖಿತ ಉತ್ತರದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಯಾವ ಪದರ ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ

VPN ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಬೇಡಿ. ಅದೇ ಹೋಸ್ಟ್‌ಗೆ ಸಾಮಾನ್ಯ HTTPS ವಿನಂತಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಸಮಯ ಹಂತಗಳನ್ನು ಓದಿ, ಏಕೆಂದರೆ ವಿಫಲವಾಗುವ ಹಂತ ಯಾವ ಸಾಧನ ಜವಾಬ್ದಾರ ಎಂದು ಹೇಳುತ್ತದೆ:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

ಯಾವ ಪ್ರತಿಕ್ರಿಯೆಯೂ ಇಲ್ಲದೆ connect ಸಮಯವೂ ಇಲ್ಲದಿದ್ದರೆ TCP ಎಂದಿಗೂ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ, ಆದ್ದರಿಂದ ಫೈರ್‌ವಾಲ್, ಪ್ರಾಕ್ಸಿ ಬೇಡಿಕೆ ಅಥವಾ ತಪ್ಪು ಗಮ್ಯಸ್ಥಾನ ಆಟದಲ್ಲಿದೆ. connect ಸಮಯ ಇದ್ದು tls ಸಮಯ ಇಲ್ಲದಿದ್ದರೆ ನಡುವೆ ಏನೋ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸಿ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ನಿಲ್ಲಿಸಿತು, ಪರಿಶೀಲಿಸುವ ಪ್ರಾಕ್ಸಿ ಕ್ಲೈಂಟ್ ಬದಿಯಿಂದ ಹೀಗೇ ಕಾಣುತ್ತದೆ.

ಈಗ ನೀವು ನಿಜವಾಗಿ ಪಡೆಯುವ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪರಿಶೀಲಿಸಿ. ಸರ್ವರ್‌ನೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೀರಾ ಅಥವಾ ಸೆಷನ್‌ಗೆ ಮತ್ತೆ ಸಹಿ ಹಾಕಿದ ಮಧ್ಯವರ್ತಿ ಪೆಟ್ಟಿಗೆಯೊಂದಿಗೆ ಎಂದು ತಿಳಿಯುವ ವೇಗದ ದಾರಿ ಇದು:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

ನೀಡುವವರ ಸಾಲನ್ನು ಓದಿ. ನಿಮ್ಮ ಸ್ವಂತ CA ಎಂದರೆ ಸೇವೆಗೆ ತಲುಪಿದ್ದೀರಿ; ಕಾರ್ಪೊರೇಟ್ ಅಥವಾ ಸಾಧನ ನೀಡುವವ ಎಂದರೆ ಫಿಲ್ಟರ್ ಸಂಪರ್ಕವನ್ನು ಮುಗಿಸಿ ಮುಂದೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತಿದೆ. ಎರಡೂ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಸಮಯಮುದ್ರೆಯೊಂದಿಗೆ ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ಗಂಟೆಯ ನಂತರ ಅತಿಥಿ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಅದೇ ಪರೀಕ್ಷೆ ಬೇರೆ ಉತ್ತರ ನೀಡಬಹುದು.

ಪ್ರಾಕ್ಸಿ ಅರಿವಿರುವ ಕ್ಲೈಂಟ್ ಮೊದಲ ಪ್ಯಾಕೆಟ್ ಬದಲಾಯಿಸುತ್ತದೆ, ನೀತಿಯನ್ನಲ್ಲ

ನೆಟ್‌ವರ್ಕ್ ದೃಢೀಕೃತ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ CONNECT ಬೇಡಿದರೆ, VPN ಕ್ಲೈಂಟ್‌ಗೆ ಹೇಳಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಅದು ಮಾರ್ಗ ಮಾಡಲಾಗದ ವಿಳಾಸಕ್ಕೆ ಸಾಕೆಟ್ ತೆರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಪ್ರಾಕ್ಸಿಯನ್ನು ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ವೈಫಲ್ಯಕ್ಕೆ ಒಂದೇ ವಿವರಣೆ ಇರಲಿ:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

ಮೊದಲ ಆಜ್ಞೆ ಪ್ರಾಕ್ಸಿ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಒಯ್ಯುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಎರಡನೆಯದು ಕ್ಲೈಂಟ್‌ಗೆ 443 ನಲ್ಲಿ TCP ಬಳಸಲು ಹೇಳುತ್ತದೆ, ಬಹುಪಾಲು ಕೇವಲ-ವೆಬ್ ಮಾರ್ಗಗಳು ಎಲ್ಲಾದರೂ ರವಾನಿಸುವ ಏಕೈಕ ಸಾಗಣೆ ಇದು. ಮೊದಲನೆಯದು ಯಶಸ್ವಿಯಾಗಿ ಎರಡನೆಯದು ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಪ್ರಾಕ್ಸಿ ಅಡಚಣೆ ಅಲ್ಲ.

ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳು ಮೇಲ್ಬರಹದ ಬದಲು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನ ಪ್ರಾಕ್ಸಿಯನ್ನು ಓದುತ್ತವೆ, ಕೆಲವು ಎರಡನ್ನೂ ಓದುವುದಿಲ್ಲ. ಸಿಸ್ಟಮ್-ವ್ಯಾಪಿ ಸೆಟ್ಟಿಂಗ್ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ದಾಖಲೆ ಪರಿಶೀಲಿಸಿ. ಪ್ರಾಕ್ಸಿ ಸೇವೆ ನೀಡದ ಪರಿಹಾರಕದ ಮೂಲಕ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಬಗೆಹರಿಸುವ ಕ್ಲೈಂಟ್ ಕೂಡ ಇಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ DNS ಬದಲಾವಣೆ ಪರಿಹಾರದಂತೆ ಕಾಣಬಹುದು ಅದು ಕೇವಲ ಸುತ್ತುದಾರಿ ಆಗಿರುವಾಗ.

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

ಪೋರ್ಟ್ 443 ತಲುಪಬಹುದು, ಅನುಮತಿಸಲಾಗಿಲ್ಲ

443 ನಲ್ಲಿ ಟನೆಲ್ ಅನ್ನು TLS ನಲ್ಲಿ ಸುತ್ತುವುದು ತಲುಪುವಿಕೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಬೇರೇನೂ ಇಲ್ಲ. ಪೋರ್ಟ್ ಪರಿಶೀಲಿಸುವ ಫಿಲ್ಟರ್ ಅದನ್ನು ದಾಟಿಸುತ್ತದೆ; ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ನ ಬೆರಳಚ್ಚು ತೆಗೆದುಕೊಳ್ಳುವ ಫಿಲ್ಟರ್ ದಾಟಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಕ್ಲೈಂಟ್ ವಂದನೆ ಸರ್ವರ್ ಹೆಸರನ್ನು ಎರಡೂ ತುದಿಗಳು ಬೆಂಬಲಿಸಿದಾಗ ಮಾತ್ರ ಮರೆಮಾಡುತ್ತದೆ. ಪರೀಕ್ಷೆ ನಡೆಸಿ ನಿರೀಕ್ಷಿಸುವ ಬದಲು ನೀವು ಯಾವ ರೀತಿಯ ಫಿಲ್ಟರ್‌ನ ಹಿಂದೆ ಇದ್ದೀರಿ ಎಂದು ತಿಳಿಯಿರಿ.

ಜನರು ನಂತರ ಕಂಡುಕೊಳ್ಳುವ ಕಾರ್ಯಕ್ಷಮತೆ ವೆಚ್ಚವೂ ಇದೆ. ವಿಶ್ವಾಸಾರ್ಹ ಸಾಗಣೆಯ ಒಳಗೆ ವಿಶ್ವಾಸಾರ್ಹ ಸಾಗಣೆ ನಷ್ಟವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಒಳಗಿನ ಸ್ಟಾಕ್ ಹೊರಗಿನ ಸ್ಟಾಕ್ ಈಗಾಗಲೇ ಮತ್ತೆ ಕಳುಹಿಸಿದ ವಿಭಾಗಗಳನ್ನು ಮತ್ತೆ ಕಳುಹಿಸುತ್ತದೆ. ಸ್ವಚ್ಛ ಲಿಂಕ್‌ನಲ್ಲಿ ಯಾರೂ ಗಮನಿಸುವುದಿಲ್ಲ. ದಟ್ಟಣೆಯ ಕ್ಯಾಂಪಸ್ ವೈರ್‌ಲೆಸ್‌ನಲ್ಲಿ ಟನೆಲ್ ನಿಮಗೆ ಬೇಕಾದ ಕ್ಷಣದಲ್ಲೇ ನಿರುಪಯುಕ್ತವಾಗುತ್ತದೆ, ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಏನನ್ನೂ ಬೀಳಿಸದಿದ್ದರೂ ಗ್ರಾಫ್ ಪ್ಯಾಕೆಟ್ ನಷ್ಟದಂತೆ ಕಾಣುತ್ತದೆ.

UDP ಸಾಮಾನ್ಯವಾಗಿ ಮೊದಲ ಬಲಿ, ಮತ್ತು ಊಹಿಸುವ ಬದಲು ಅದನ್ನು ದೃಢೀಕರಿಸುವುದು ಯೋಗ್ಯ. TCP 443 ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೂ WireGuard ಅಥವಾ ಡಿಫಾಲ್ಟ್ OpenVPN ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪೂರ್ಣಗೊಳಿಸದಿದ್ದರೆ, ನೆಟ್‌ವರ್ಕ್ UDP ಬೀಳಿಸುತ್ತಿದೆ, ಮತ್ತು ಕೀ ಮರುಉತ್ಪಾದನೆ ಅದನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

ನಿನ್ನೆ ಕೆಲಸ ಮಾಡಿದ ಪೀರ್‌ನ ಪಕ್ಕದಲ್ಲಿ ಖಾಲಿ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಮಯಮುದ್ರೆ UDP ಉತ್ತರ. ಎರಡು DNS ಪ್ರಶ್ನೆಗಳು ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತವೆ: ಸ್ಥಳೀಯ ಪರಿಹಾರಕ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಪರಿಹಾರಕ ಎಂಡ್‌ಪಾಯಿಂಟ್ ವಿಳಾಸದ ಬಗ್ಗೆ ಒಪ್ಪದಿದ್ದರೆ, ನಿಮ್ಮನ್ನು ನಿರ್ದೇಶಿಸಲಾಗುತ್ತಿದೆ ಮತ್ತು ಸಾಗಣೆ ವಾದ ತಪ್ಪು.

ಯಂತ್ರದಿಂದ ನಿಜವಾಗಿ ಏನು ಹೊರಟಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ

ಕ್ಲೈಂಟ್ ಲಾಗ್‌ಗಳು ಕ್ಲೈಂಟ್ ನಂಬುವುದನ್ನು ವಿವರಿಸುತ್ತವೆ. ಸೆರೆಹಿಡಿಯುವಿಕೆ ನೆಟ್‌ವರ್ಕ್ ನೋಡಿದ್ದನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡರ ನಡುವಿನ ವ್ಯತ್ಯಾಸವೇ ಈ ಪ್ರಕರಣಗಳ ಬಹುಪಾಲು ಬಗೆಹರಿಯುವ ಸ್ಥಳ:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

SYN ಪ್ಯಾಕೆಟ್‌ಗಳು ಕಂಡು SYN-ACK ಇಲ್ಲದಿದ್ದರೆ, ಬ್ಲಾಕ್ ಮೇಲ್ಮುಖದಲ್ಲಿದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ನಿರಪರಾಧಿ. ಸರ್ವರ್‌ನದಲ್ಲದ ವಿಳಾಸಕ್ಕೆ ಪೂರ್ಣಗೊಂಡ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಕಂಡರೆ, ನೀವು ಪ್ರಾಕ್ಸಿ ಅಥವಾ ಪ್ರತಿಬಂಧಕದೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೀರಿ. ಏನನ್ನೂ ಕಾಣದಿದ್ದರೆ, ಯಾವುದೇ ತೀರ್ಮಾನಕ್ಕೆ ಬರುವ ಮೊದಲು ಸರಿಯಾದ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಸೆರೆಹಿಡಿದಿದ್ದೀರಾ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಸಾಕೆಟ್ ಪಟ್ಟಿ ಸೂಕ್ಷ್ಮ ಪ್ರಕರಣವನ್ನು ಹಿಡಿಯುತ್ತದೆ: ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಈಗಾಗಲೇ ಹಿಡಿದಿರುವ ಎರಡನೇ ಟನೆಲ್. ಮಾರ್ಗಣೆ ಕೋಷ್ಟಕಕ್ಕಾಗಿ ಹೋರಾಡುವ ಎರಡು ಕ್ಲೈಂಟ್‌ಗಳು ಬ್ಲಾಕ್ ಆದ ನೆಟ್‌ವರ್ಕ್‌ನಂತೆಯೇ ಕಾಣುವ ಮಧ್ಯಂತರ ವೈಫಲ್ಯಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ, ಮತ್ತು ಸೆರೆಹಿಡಿಯುವಿಕೆ ನೀವು ನಿರೀಕ್ಷಿಸದ ಇಂಟರ್‌ಫೇಸ್‌ನಿಂದ ಹೊರಹೋಗುವ ಸಂಚಾರವನ್ನು ತೋರಿಸುತ್ತದೆ.

ಹಿಂಪಡೆಯುವಿಕೆ, ಮತ್ತು ಇಟ್ಟುಕೊಳ್ಳಲು ಯೋಗ್ಯವಾದ ಟಿಪ್ಪಣಿ

ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದ ಹಿಮ್ಮುಖ ಕ್ರಮದಲ್ಲಿ ಹಿಂತಿರುಗಿಸಿ. ಪ್ರಾಕ್ಸಿ ಚರಗಳನ್ನು ತೆಗೆಯಿರಿ, ಕೈಯಿಂದ ಪ್ರಾರಂಭಿಸಿದ ಕ್ಲೈಂಟ್ ನಿಲ್ಲಿಸಿ, ಮತ್ತು ಸೇರಿಸಿದ ಯಾವುದೇ ಮಾರ್ಗ ಅಥವಾ ಪರಿಹಾರಕ ಮೇಲ್ಬರಹ ತೆಗೆಯಿರಿ:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

ಕೈಯಿಂದ ಪ್ರಾರಂಭಿಸಿದ ಕ್ಲೈಂಟ್ ಚಾಲನೆಯಲ್ಲಿರಲು ಬಿಡುವುದು ಮುಂದಿನ ಕಚೇರಿ ಭೇಟಿಯಲ್ಲಿ ಲ್ಯಾಪ್‌ಟಾಪ್ ಮುರಿದ ನೆಟ್‌ವರ್ಕ್‌ನೊಂದಿಗೆ ಉಳಿಯುವ ದಾರಿ. ಶೆಲ್ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಬಿಟ್ಟ ಪ್ರಾಕ್ಸಿ ಚರಗಳು ವಾರಗಳ ನಂತರ ಸಂಬಂಧವಿಲ್ಲದ ಉಪಕರಣಗಳನ್ನು ಮುರಿಯುತ್ತವೆ, ಮತ್ತು ಅವನ್ನು ಡೀಬಗ್ ಮಾಡುವವರು ಎರಡು ಘಟನೆಗಳನ್ನು ಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ.

ನಂತರ ನಾಲ್ಕು ಸಾಲು ಬರೆಯಿರಿ: ನೆಟ್‌ವರ್ಕ್, ಸಮಯಮುದ್ರೆ, ವಿಫಲವಾದ ಹಂತ ಮತ್ತು ನೀವು ಕಂಡ ನೀಡುವವ. ಒಂದು ಕ್ಯಾಂಪಸ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಮುಂದಿನದರಲ್ಲಿ ವಿಫಲವಾಗುವ ಮಾರ್ಗ ಸಾಮಾನ್ಯ, ಮತ್ತು ಮುಂದಿನ ವ್ಯಕ್ತಿ ವ್ಯತ್ಯಾಸ ಪ್ರಾಕ್ಸಿ, ಪರಿಹಾರಕ ಅಥವಾ ಫಿಲ್ಟರ್ ಎಂದು ತಿಳಿಯಬೇಕು. ಉತ್ತರ ನೆಟ್‌ವರ್ಕ್ ದೂರಸ್ಥ ಪ್ರವೇಶ ನಿಷೇಧಿಸುತ್ತದೆ ಎಂದಾದರೆ, ಅಲ್ಲೇ ನಿಲ್ಲಿ ಮತ್ತು ನಿರ್ವಾಹಕರನ್ನು ಬೆಂಬಲಿತ ಮಾರ್ಗ ಕೇಳಿ, ಓದದ ನೀತಿಗೆ ಸುತ್ತುದಾರಿ ಒಯ್ಯುವ ಬದಲು.