ಕಚೇರಿ ಮತ್ತು VPN ಗಾಗಿ ಒಂದೇ URL? ಅನುಮತಿ ಪಟ್ಟಿಯ ಪುರಾಣ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ
VPN ಸಂಪರ್ಕವು ಅನುಮತಿ ಪಟ್ಟಿಯ ಸೈಟ್ ನೋಡುವ ವಿಳಾಸವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. URL ಸೇರಿಸುವ ಮೊದಲು ನಿಜವಾದ ನಿರ್ಗಮನ, ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಾಕ್ಸಿ ಹಾಪ್ ಮತ್ತು IPv6 ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ.
ಸುರಂಗವನ್ನು ಸಂಪರ್ಕಿಸಿ, ಅದೇ ಬುಕ್ಮಾರ್ಕ್ ತೆರೆಯಿರಿ, ಮತ್ತು ಅನುಮತಿ ಪಟ್ಟಿಯ ಸೈಟ್ ಕಚೇರಿಯಿಂದ ಹೇಗೆ ಉತ್ತರಿಸಿತೋ ನಿಖರವಾಗಿ ಹಾಗೆಯೇ ಉತ್ತರಿಸುತ್ತದೆ. ಇದೇ ದೂರಸ್ಥ ಪ್ರವೇಶ ಯೋಜನೆಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಮೌನವಾಗಿ ಅವಲಂಬಿಸಿರುವ ಊಹೆ, ಮತ್ತು ಮೂರು ಪ್ರತ್ಯೇಕ ವಿಷಯಗಳು ಒಟ್ಟಿಗೆ ನಿಜವಾಗಿರುವವರೆಗೆ ಮಾತ್ರ ಅದು ನಿಲ್ಲುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ VPN ಕ್ಲೈಂಟ್ನ ವೈಶಿಷ್ಟ್ಯವಲ್ಲ, ಮತ್ತು ಯಾವುದೇ DNS ದಾಖಲೆ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನೂ ಒದಗಿಸಲಾರದು. ಮನೆಯಲ್ಲಿ ಬುಕ್ಮಾರ್ಕ್ ವಿಫಲವಾದಾಗ, ಬ್ರೌಸರ್ ನಿಮಗೆ ಒಂದು ಸಾಮಾನ್ಯ ದೋಷವನ್ನು ನೀಡುತ್ತದೆ, ಕಾರಣ ಕಾಣೆಯಾದ ಮಾರ್ಗವೋ, ಅನುಮೋದಿತವಲ್ಲದ ನಿರ್ಗಮನ ವಿಳಾಸವೋ ಅಥವಾ ಅದು ವರದಿ ಮಾಡುವ ಮೂಲವನ್ನು ಬದಲಿಸಿದ ಪ್ರಾಕ್ಸಿಯೋ ಏನೇ ಆಗಿರಲಿ. ಆ ಮೂರನ್ನು ಒಂದೇ ಸಮಸ್ಯೆಯೆಂದು ಪರಿಗಣಿಸುವುದೇ ಸಣ್ಣ ನೀತಿ ತಿದ್ದುಪಡಿ ಅನುಮತಿ ಪಟ್ಟಿಗಳನ್ನು ವಿಸ್ತರಿಸುವ ಒಂದು ವಾರವಾಗಿ ಬದಲಾಗುವ ದಾರಿ.
ನಿಜವಾದ ಕಚೇರಿ ಜಾಲರಿಯೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ತಾಳಿಕೊಳ್ಳುವ ವಿನ್ಯಾಸ ಊಹೆಗಿಂತ ಸಂಕುಚಿತವಾಗಿದೆ: ಮೂರು ಸಾಲಿನ ಸ್ಪಷ್ಟ ನಿರ್ಧಾರ ಕೋಷ್ಟಕ, ತಪ್ಪಿಸಿಕೊಳ್ಳಲಾಗದ ಒಂದು ಜಾರಿ ಬಿಂದು, ಮತ್ತು ಏನನ್ನಾದರೂ ಸಾಬೀತುಪಡಿಸುವ ನಿರಾಕರಣೆ ಪರೀಕ್ಷೆ. ಊಹೆಯನ್ನು ಒಡೆಯುವುದು ಮೊದಲು ಬರುತ್ತದೆ, ಏಕೆಂದರೆ ಅದರ ನಂತರದ ಎಲ್ಲವೂ ಯಾವ ಪದರ ಮೂಲವನ್ನು ತಪ್ಪಾಗಿ ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿಯುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ.
ಪುರಾಣ: ಸಂಪರ್ಕಿಸುವುದು ಮಾರ್ಗನಿರ್ದೇಶನವಲ್ಲ
ಸುರಂಗವೊಂದು ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಕೆಲವು ಪೂರ್ವಪ್ರತ್ಯಯಗಳಿಗೆ ಮಾರ್ಗಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಸಂಪರ್ಕಿಸುವುದು ಅಷ್ಟೇ ಮಾಡುತ್ತದೆ. ಸಂಬಂಧವಿಲ್ಲದ HTTPS ವಿನಂತಿ ಸುರಂಗದ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆಯೇ, ಮತ್ತು ಬಂದಾಗ ಯಾವ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದಿಂದ ಬಂದಂತೆ ಕಾಣುತ್ತದೆ, ಇವು ನಂತರ ಬೇರೆ ಘಟಕಗಳು ತೆಗೆದುಕೊಳ್ಳುವ ನಿರ್ಧಾರಗಳು: ಮಾರ್ಗ ಕೋಷ್ಟಕ ಮಾರ್ಗವನ್ನು ಆರಿಸುತ್ತದೆ, ಮತ್ತು ನಿರ್ಗಮನ ಮೂಲವನ್ನು ಆರಿಸುತ್ತದೆ.
ಅದಕ್ಕೇ ಕಚೇರಿ ಮತ್ತು ಅಡುಗೆಮನೆಯ ಮೇಜು ಒಂದೇ ಲ್ಯಾಪ್ಟಾಪ್, ಒಂದೇ ಬ್ರೌಸರ್ ಪ್ರೊಫೈಲ್ ಮತ್ತು ಒಂದೇ ಬುಕ್ಮಾರ್ಕ್ನೊಂದಿಗೆ ಭಿನ್ನವಾಗುತ್ತವೆ. ಕಚೇರಿಯಲ್ಲಿ ವಿನಂತಿ ಸೈಟ್ ನಿರ್ವಾಹಕ ಒಪ್ಪಿದ ನಿರ್ವಹಿತ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಮೂಲಕ ಹೊರಡುತ್ತದೆ. ಪೂರ್ಣ ಸುರಂಗದ ಮೂಲಕ ಅದು VPN ನಿರ್ಗಮನದ ಮೂಲಕ ಹೊರಡಬಹುದು, ಅದು ಬೇರೆ ವಿಳಾಸ ಮತ್ತು ಯಾರಾದರೂ ಅದನ್ನು ಸೇರಿಸುವವರೆಗೆ ಅನುಮೋದಿತವಲ್ಲ. ವಿಭಜಿತ ಸುರಂಗದ ಮೂಲಕ ಅದು ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸದೇ ಇರಬಹುದು. ಆ ಮೂರು ಮಾರ್ಗಗಳಲ್ಲಿ ಎರಡು ಮಾತ್ರ ಸೈಟ್ ಮಾಲೀಕರೊಂದಿಗಿನ ಒಪ್ಪಂದದ ಭಾಗವಾಗಿತ್ತು, ಮತ್ತು ಮೂರನೆಯದು ಹೆಚ್ಚುವರಿ allow ಸಾಲಿನಿಂದ ಸರಿಪಡಿಸಬೇಕಾದ ದೋಷವಲ್ಲ.
ಮೂರು ವಿನಂತಿ ಸ್ಥಿತಿಗಳು, ಎರಡು ಅನುಮೋದಿತ ನಿರ್ಗಮನಗಳು
ಫೈರ್ವಾಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಕೋಷ್ಟಕವೇ ವಿನ್ಯಾಸ ಮತ್ತು ನಿಯಮ ಅದರ ಒಂದೇ ಒಂದು ಅನುಷ್ಠಾನ. ಕೆಳಗಿನ ವಿಳಾಸಗಳು ದಾಖಲೆ ಶ್ರೇಣಿಗಳು; ಅವನ್ನು ನಿಮ್ಮದೇ ನಿರ್ವಹಿತ ಮೌಲ್ಯಗಳಿಂದ ಬದಲಿಸಿ ಮತ್ತು ಸೈಟ್ ಮಾಲೀಕರು ಪರಿಶೀಲಿಸಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ.
| Request path | Source the site sees | Intended decision |
|---|---|---|
| Office, no tunnel | Office public exit | Admit to the application login |
| Remote, approved full tunnel | Approved VPN egress | Admit to the same login |
| Remote, ordinary connection | Neither approved address | Deny at the network boundary |
ಈ ಯೋಜನೆಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಮಧ್ಯದ ಸಾಲಿನಲ್ಲಿ ಮುರಿಯುತ್ತವೆ. ಮುಖ್ಯವಾದದ್ದು ಜಾರಿ ಮಾಡುವ ಸಾಧನ ನೋಡುವ ವಿಳಾಸ, ಲ್ಯಾಪ್ಟಾಪ್ ಸುರಂಗದೊಳಗೆ ಇಟ್ಟುಕೊಳ್ಳುವ ಖಾಸಗಿ ವಿಳಾಸವಲ್ಲ ಮತ್ತು ಅದರ LAN ವಿಳಾಸವೂ ಅಲ್ಲ. 10.8.0.6 ನಂತಹ ಮೌಲ್ಯ ಸಾರ್ವಜನಿಕ ಸೈಟ್ಗೆ ಏನನ್ನೂ ಅರ್ಥೈಸುವುದಿಲ್ಲ, 192.168.1.44 ಕೂಡ ಅಲ್ಲ. ಸುರಂಗದ ವಿಳಾಸ ಸುರಂಗದ ವಿಳಾಸೀಕರಣದ ವಿವರ, ಸೈಟ್ ಪರಿಶೀಲಿಸಬಹುದಾದ ಯಾವುದೇ ರುಜುವಾತಲ್ಲ.
ನಿಮ್ಮ VPN ಸ್ಥಿರ, ದಾಖಲಿತ ನಿರ್ಗಮನವನ್ನು ಒದಗಿಸಲಾಗದಿದ್ದರೆ, ಮ್ಯಾಟ್ರಿಕ್ಸ್ಗೆ ಮಾನ್ಯವಾದ ಮಧ್ಯದ ಸಾಲಿಲ್ಲ ಮತ್ತು ಎಷ್ಟೇ ಅನುಮತಿ ಪಟ್ಟಿಗಳಾದರೂ ಒಂದನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಆ ಕ್ಷಣದ ಪ್ರಾಮಾಣಿಕ ಆಯ್ಕೆಗಳೆಂದರೆ ಸ್ಪಷ್ಟ ಖಾಸಗಿ ಮಾರ್ಗಗಳ ಮೂಲಕ ತಲುಪುವ ಖಾಸಗಿ ಸೈಟ್, ಅಥವಾ ಅನ್ವಯದ ಮುಂದೆ ಗುರುತನ್ನು ಅರಿತ ಪ್ರವೇಶ ದ್ವಾರ. ಎರಡಕ್ಕೂ ಸಾರ್ವಜನಿಕ ಅನುಮತಿ ಪಟ್ಟಿಗಿಂತ ಬೇರೆ ಒಪ್ಪಂದವಿದೆ, ಮತ್ತು ಎರಡನ್ನೂ ಲೆಕ್ಕಪರಿಶೋಧಕರಿಗೆ ವಿವರಿಸುವುದು ಆಕಸ್ಮಿಕವಾಗಿ ಕೆಲಸ ಮಾಡುವವರೆಗೆ ಬೆಳೆದ ಪಟ್ಟಿಗಿಂತ ಸುಲಭ.
ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವಲ್ಲಿಯೇ ಮೂಲವನ್ನು ಓದಿ
ನಿರ್ಬಂಧವನ್ನು ವಿನಂತಿಯನ್ನು ಮುಗಿಸುವ ಸಾಧನದ ಮೇಲೆ ಇರಿಸಿ, ಮತ್ತು ಯಾವುದೇ ಪರ್ಯಾಯ ಮೂಲ ಮಾರ್ಗ ಅದನ್ನು ತಪ್ಪಿಸದಂತೆ ಖಚಿತಪಡಿಸಿ. Nginx ಪ್ರವೇಶ ಮಾಡ್ಯೂಲ್ allow ಮತ್ತು deny ನಿರ್ದೇಶನಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ, ಮೊದಲ ಹೊಂದಾಣಿಕೆ ಗೆಲ್ಲುತ್ತದೆ, ಮತ್ತು ಸುತ್ತುವರಿದ ಬ್ಲಾಕ್ನಿಂದ ಬಂದ ನಿಯಮಗಳು location ಒಳಗೆ ಇನ್ನೂ ಅನ್ವಯವಾಗುತ್ತವೆ. ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಸಂಕುಚಿತ allow ವಿಶಾಲ allow ಪಕ್ಕದಲ್ಲಿದ್ದರೆ ಸಾಮಾನ್ಯವಾಗಿ ವಿಶಾಲವೇ ನಿರ್ಧರಿಸುತ್ತದೆ. ಅದರ ಒಂದು ಸಾಲನ್ನೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಆ location ನ ಸಂಪೂರ್ಣ ಪರಿಣಾಮಕಾರಿ ಸಂರಚನೆಯನ್ನು ಓದಿ.
server {
listen 443 ssl;
server_name intranet.example.com;
set_real_ip_from 10.20.0.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
location /app/ {
allow 203.0.113.24; # office public exit
allow 198.51.100.77; # approved VPN egress
deny all;
proxy_pass http://app_backend;
}
}ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅಥವಾ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯ ಹಿಂದೆ ಆ ನಿಯಮ ಪ್ರಾಕ್ಸಿಯನ್ನು ನೋಡುತ್ತದೆ, ನೀವು ಬೇರೆ ಹೇಳದಿದ್ದರೆ. ಕರೆ ಮಾಡುವವರ ವಿಳಾಸವನ್ನು ಬೆಂಬಲಿತ ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಾಕ್ಸಿ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕವೇ ಮರುಸ್ಥಾಪಿಸಿ, ಪ್ರಾಕ್ಸಿ ವಿಳಾಸಗಳ ಸ್ಪಷ್ಟ ಪಟ್ಟಿಯೊಂದಿಗೆ. ಅನುಮೋದಿತ ವಿಳಾಸವನ್ನು ಹೇಳಿಕೊಳ್ಳುವ ವಿನಂತಿ ಶೀರ್ಷಿಕೆ ಕರೆ ಮಾಡುವವರು ಅದನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂಬ ಸಾಕ್ಷ್ಯವಲ್ಲ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಶ್ರೋತೃದಲ್ಲಿ ಪರಿಶೀಲಿಸದ ಮುಂದಕ್ಕೆ ರವಾನಿಸಿದ ಶೀರ್ಷಿಕೆ ಅನುಮತಿ ಪಟ್ಟಿಯನ್ನು ಅಲಂಕಾರವಾಗಿಸುತ್ತದೆ.
ನಂತರ ಇನ್ನೊಂದು ವಿಳಾಸ ಕುಟುಂಬವನ್ನು ಪರಿಶೀಲಿಸಿ. ಕೇವಲ IPv4 ಅನ್ನು ಒಳಗೊಂಡ ನಿಯಮ ಗುಂಪು AAAA ನಲ್ಲೂ ಉತ್ತರಿಸುವ ಹೋಸ್ಟ್ ಹೆಸರಿಗೆ ಅಪೂರ್ಣ ನಿರ್ಧಾರ, ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುವ IPv6 ಇರುವ ಕ್ಲೈಂಟ್ ಅದೇ ಅನ್ವಯವನ್ನು ನೀವು ಎಂದೂ ಪರಿಶೀಲಿಸದ ಮಾರ್ಗದಿಂದ ತಲುಪುತ್ತದೆ.
ವಿಭಜಿತ ಸುರಂಗ: ಎಂದೂ ಒಳಗೆ ಬಾರದ ವಿನಂತಿ
ವಿಭಜಿತ ಸುರಂಗ ತನ್ನ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಮಾತ್ರ ಸಾಗಿಸುತ್ತದೆ. ಕಚೇರಿಯ ಒಳಗಿನ ಉಪಜಾಲಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಆ ಪಟ್ಟಿಗೆ ಸೇರುತ್ತವೆ; ಸಾರ್ವಜನಿಕ ಜಾಲತಾಣ ಸೇರುವುದಿಲ್ಲ. ಬ್ರೌಸರ್ ಹೆಸರನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಆಯ್ಕೆಮಾಡಿದ ವಿಳಾಸವನ್ನು ಮಾರ್ಗ ಕೋಷ್ಟಕದೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ, ಮತ್ತು ಹಾಗಿದ್ದರೂ ಮುಂದೆ ಸ್ಥಳೀಯ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇಯನ್ನು ಕಾಣುತ್ತದೆ.
ಹಾಗಾಗಿ ವಿನಂತಿ ಬಳಕೆದಾರರ ಮನೆ ಸಂಪರ್ಕದಿಂದ ಬರುತ್ತದೆ, ನಿರಾಕರಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ವರದಿ VPN ಮುರಿದಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಆದರೆ ಸುರಂಗವು ಅದಕ್ಕಾಗಿ ಸಂರಚಿಸಲಾದ ಕೆಲಸವನ್ನೇ ಮಾಡುತ್ತಿದೆ. ಎರಡು ಸರಿಪಡಿಸುವಿಕೆಗಳು ಕಾನೂನುಬದ್ಧ: ಆ ಗಮ್ಯವನ್ನು ಸುರಂಗದ ಮೂಲಕ ಕಳುಹಿಸಿ ಮತ್ತು ಅನುಮೋದಿತ ನಿರ್ಗಮನ ಅದನ್ನು ಸಾಗಿಸಲಿ, ಅಥವಾ ಸೈಟ್ಗೆ ನೇರವಾಗಿ ತಲುಪುತ್ತದೆ ಎಂದು ಒಪ್ಪಿಕೊಂಡು ದೂರಸ್ಥ ಬಳಕೆದಾರರಿಗೆ ಪ್ರವೇಶ ದ್ವಾರದಂತಹ ಇನ್ನೊಂದು ಅನುಮೋದಿತ ಮಾರ್ಗ ನೀಡಿ. ಮನೆ ವಿಳಾಸ ಆಕಸ್ಮಿಕವಾಗಿ ಸೇರುವವರೆಗೆ ಸೈಟ್ನ ಸಾರ್ವಜನಿಕ ಅನುಮತಿ ಪಟ್ಟಿಯನ್ನು ವಿಸ್ತರಿಸುವುದು ಎರಡೂ ಅಲ್ಲ, ಮತ್ತು ಅದು ವಿನ್ಯಾಸ ಜಾರಿಗೊಳಿಸಬೇಕಿದ್ದ ಗಡಿಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಮೊದಲೆರಡು ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಇಡುತ್ತವೆ; ಮೂರನೆಯದು ಅದರಿಂದ ಒಂದು ಸಾಲನ್ನು ಮೌನವಾಗಿ ಅಳಿಸುತ್ತದೆ.
ನಿರಾಕರಣೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ, ನಂತರ ಚೇತರಿಕೆಯನ್ನು
ಕೋಷ್ಟಕದ ಪ್ರತಿ ಸಾಲಿನಲ್ಲಿ ನಿಂತಿರುವ ಕ್ಲೈಂಟ್ನಿಂದ ನಿಜವಾದ ನಿರ್ಧಾರವನ್ನು ಬಳಸುವ ವಿನಂತಿಯೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ. ಯಾವುದೋ ಸಂಬಂಧವಿಲ್ಲದ ವಿಳಾಸ ತೋರಿಸುವ ಪುಟಕ್ಕೆ ತಲುಪುವಿಕೆಯ ಪರಿಶೀಲನೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಆ ಗಮ್ಯ ಅನ್ವಯಕ್ಕಿಂತ ಬೇರೆ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಬಹುದು.
curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'ಗಡಿಯ ಪ್ರವೇಶ ದಾಖಲೆಯನ್ನು ಕೋಷ್ಟಕ ಮುನ್ಸೂಚಿಸಿದ್ದರೊಂದಿಗೆ ಹೋಲಿಸಿ. ನಂತರ ಸುರಂಗವನ್ನು ಇಳಿಸಿ ಮತ್ತು ನಿರಾಕರಿಸಬೇಕಾದ ಹೊಸ ವಿನಂತಿ ಮಾಡಿ; ಈಗಾಗಲೇ ಲೋಡ್ ಆದ ಪುಟ ಅಥವಾ ಈಗಾಗಲೇ ತೆರೆದ ಸಂಪರ್ಕ ಏನನ್ನೂ ಪರೀಕ್ಷಿಸುವುದಿಲ್ಲ. ಯಾವುದೇ ನಿರಾಕರಣೆ ಕಾಣದಿದ್ದರೆ, ಜಾರಿ ಬಿಂದು ನೀವು ಭಾವಿಸುವ ಸ್ಥಳದಲ್ಲಿಲ್ಲ.
ಜಾಲರಿಗೆ ಪ್ರವೇಶದ ನಂತರ ಅನ್ವಯ ದೃಢೀಕರಣವನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಕಚೇರಿ ನಿರ್ಗಮನ ಮತ್ತು VPN ನಿರ್ಗಮನ ಪ್ರತಿಯೊಂದೂ ಅನೇಕ ಜನರನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ ಮತ್ತು ಯಾವುದೂ ವ್ಯಕ್ತಿಯನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ. ಬಳಕೆದಾರರಿಗೆ ಸೂಚನೆ ಚಿಕ್ಕದಾಗಿರುತ್ತದೆ: ಅನುಮೋದಿತ ಸುರಂಗವನ್ನು ಎತ್ತಿ, ನಂತರ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ. ಇದೇ ಒಂದು URL ಅನ್ನು ಅನುಕೂಲಕರವಾಗಿ ಇಡುತ್ತದೆ, ಮೂಲ ನಿಯಮವು ಊಹೆಯ ಬದಲು ನಿರ್ಧಾರವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ.