OpenVPN route-nopull ಸರ್ವರ್ ಏನನ್ನು ತಳ್ಳುವುದನ್ನು ನಿಜವಾಗಿ ತಡೆಯುತ್ತದೆ
route-nopull ತಳ್ಳಲಾದ ಮಾರ್ಗಗಳು ಮತ್ತು DHCP ಆಯ್ಕೆಗಳನ್ನು ಬಿಡುತ್ತದೆ, ಹ್ಯಾಂಡ್ಶೇಕ್ ಅಲ್ಲ. ಅದು, pull-filter ಅಥವಾ ಏನೂ ಇಲ್ಲದಿರುವ ನಡುವೆ ಆಯ್ಕೆಮಾಡಿ, ನಂತರ ಮಾರ್ಗಗಳನ್ನು ನೀವೇ ಸೇರಿಸಿ.
ಟನೆಲ್ ನಿಮ್ಮ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ನುಂಗದಂತೆ ತಡೆಯಲು ನೀವು ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ route-nopull ಇಟ್ಟಿದ್ದೀರಿ, ಮತ್ತು ಈಗ ಕಚೇರಿ ಸಬ್ನೆಟ್ ತಲುಪಲಾಗದಿದೆ ಆದರೆ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಎರಡೂ ಅವಲೋಕನಗಳು ನಿಜ, ಮತ್ತು ಯಾವುದೂ ವಿಫಲವಾಗಿಲ್ಲ. ಸರ್ವರ್ ತಳ್ಳುವ ಮಾರ್ಗಗಳು ಮತ್ತು DHCP ನಮೂದುಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಲು ಈ ಫ್ಲ್ಯಾಗ್ ಕ್ಲೈಂಟ್ಗೆ ಹೇಳುತ್ತದೆ, ಇದು ಸೇರಿಸುವಾಗ ಹೆಚ್ಚಿನ ಜನರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಕಿರಿದಾದ ಸೂಚನೆ. ಉಳಿಯುವುದು ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳು ಅದನ್ನು ಬಳಸಬೇಕು ಎಂಬ ಅಭಿಪ್ರಾಯವಿಲ್ಲದ ಕೆಲಸ ಮಾಡುವ ಟನೆಲ್.
ಆ ಕೊರತೆಯೇ ಈ ಲೇಖನದ ವಿಷಯವಾದ ಇಡೀ ನಿರ್ಧಾರ. ಒಂದೋ ಸರ್ವರ್ ನೆಟ್ವರ್ಕ್ ವಿವರಿಸುತ್ತದೆ, ಇಲ್ಲವೇ ಕ್ಲೈಂಟ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಫ್ಲ್ಯಾಗ್ ಆ ಕೆಲಸವನ್ನು ನಿಮಗಾಗಿ ಏನೂ ಮಾಡದೆ ಕ್ಲೈಂಟ್ಗೆ ಒಪ್ಪಿಸುತ್ತದೆ.
ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಫ್ಲ್ಯಾಗ್ ಏನನ್ನು ಆಫ್ ಮಾಡುತ್ತದೆ
ಎಳೆಯುವ OpenVPN ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ದೃಢೀಕರಣದ ನಂತರ ಸರ್ವರ್ನಿಂದ ಕಟ್ಟನ್ನು ಪಡೆಯುತ್ತದೆ: ಮಾರ್ಗಗಳು, ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇಯ ಮರುನಿರ್ದೇಶನ, DNS ಸರ್ವರ್ಗಳು ಮತ್ತು ಕೆಲವು ಟ್ಯೂನಿಂಗ್ ಸೂಚನೆಗಳು. route-nopull ಜಾರಿಯಲ್ಲಿದ್ದಾಗ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸೆಷನ್ ಸ್ವೀಕರಿಸುತ್ತದೆ, ಇನ್ನೂ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಇನ್ನೂ ಸೈಫರ್ಗಳು ಮತ್ತು keepalive ಬಗ್ಗೆ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ, ಮತ್ತು ಇನ್ನೂ ಇಂಟರ್ಫೇಸ್ ಎತ್ತುತ್ತದೆ. ಅದು ಬಿಡುವುದು ತಳ್ಳಲಾದ route ಸಾಲುಗಳ ಮತ್ತು ತಳ್ಳಲಾದ dhcp-option ಸಾಲುಗಳ ಅನ್ವಯ, DNS ಸೇರಿದಂತೆ.
ಗೊಂದಲ ಮೃತ ಅಪ್ಲಿಕೇಶನ್ ಪಕ್ಕದ ಹಸಿರು ಸೂಚಕದಿಂದ ಬರುತ್ತದೆ. ಟನೆಲ್ ಇದೆ; ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಆ ಟನೆಲ್ಗೆ ನಕ್ಷೆ ಮಾಡುವುದು ಇಲ್ಲ. ಕ್ಲೈಂಟ್ನ ಸ್ಥಿತಿ ಪ್ಯಾನೆಲ್ನಲ್ಲಿ «ಸಂಪರ್ಕಗೊಂಡು ಮಾರ್ಗನಿರ್ದೇಶನ ಮಾಡುತ್ತಿದೆ» ಮತ್ತು «ಸಂಪರ್ಕಗೊಂಡು ನಿಷ್ಕ್ರಿಯವಾಗಿದೆ» ನಡುವೆ ಯಾವುದೂ ವ್ಯತ್ಯಾಸ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಟನೆಲ್ನ ದೃಷ್ಟಿಯಿಂದ ಎರಡೂ ಒಂದೇ ಸ್ಥಿತಿ.
ಜೀವಂತ ಟನೆಲ್ ಇನ್ನೂ ಏಕೆ ಏನನ್ನೂ ಮಾರ್ಗನಿರ್ದೇಶಿಸಲಾರದು
ಇಂಟರ್ಫೇಸ್ ತನ್ನದೇ ವಿಳಾಸದೊಂದಿಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಲಿಂಕ್ನಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಪೀರ್ಗೆ ಇರುವ ಹೋಸ್ಟ್ ಮಾರ್ಗಕ್ಕಿಂತ ನಿರ್ದಿಷ್ಟವಾದದ್ದು ಏನೂ ಇರುವುದಿಲ್ಲ. ಖಾಸಗಿ ಸಬ್ನೆಟ್, ಸರಿಯಾದ ಪ್ರಿಫಿಕ್ಸ್ನೊಂದಿಗೆ ಆ ಇಂಟರ್ಫೇಸ್ಗೆ ಯಾವುದೋ ಮಾರ್ಗ ತೋರಿಸಿದಾಗ ಮಾತ್ರ ತಲುಪಬಹುದಾದ್ದಾಗುತ್ತದೆ, ಮತ್ತು ತಳ್ಳುವಿಕೆ ಆಫ್ ಆಗಿರುವಾಗ ಆ ಮಾರ್ಗ ಎಂದಿಗೂ ಬರುವುದಿಲ್ಲ. ಡೌನ್ಲೋಡ್ ಮಾಡಿದ ಪ್ರೊಫೈಲ್ ಕೂಡ ಸಾಮಾನ್ಯವಾಗಿ ಸಹಾಯ ಮಾಡಲಾರದು, ಏಕೆಂದರೆ ಸರ್ವರ್ ನಿಖರವಾಗಿ ಈ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ ಎಂಬ ಊಹೆಯ ಮೇಲೆ ಅದನ್ನು ಬರೆಯಲಾಗಿದೆ. ಆದ್ದರಿಂದ ಇಂಟರ್ಫೇಸ್ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ ಆದರೆ ಸಬ್ನೆಟ್ ಕತ್ತಲೆಯಾಗಿ ಉಳಿಯುತ್ತದೆ.
ಆದ್ದರಿಂದ ಪ್ರೊಫೈಲ್ ಓದುವುದು ಬಹಳ ಕಡಿಮೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಬದಲಾಗಿ ಸಂಪರ್ಕಗೊಂಡ ಯಂತ್ರದಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಸ್ಥಿತಿಯನ್ನು ಓದಿ:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10ಎರಡನೇ ಆದೇಶದಲ್ಲಿ ಸಬ್ನೆಟ್ ಮಾರ್ಗವಿಲ್ಲದ ವಿಳಾಸವೇ ಈ ಸಮಸ್ಯೆಯ ಸಹಿ. ಮೂರನೇ ಆದೇಶವು ನಂತರ ಬಳಕೆದಾರರಿಗೆ ನಿಜವಾಗಿ ಮುಖ್ಯವಾದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ನೀವು ಬಳಸುತ್ತದೆ ಎಂದು ಆಶಿಸಿದ ಪಟ್ಟಿಯ ಬದಲು ನಿರ್ದಿಷ್ಟ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಕರ್ನಲ್ ಆಯ್ಕೆ ಮಾಡುವ ಇಂಟರ್ಫೇಸ್ ಬಗ್ಗೆ ತಿಳಿಸುತ್ತದೆ. ಅದು ನಿಮ್ಮ ಭೌತಿಕ ಲಿಂಕ್ ಮೂಲಕ ಉತ್ತರಿಸಿದರೆ, ಟನೆಲ್ ಮಾರ್ಗದಲ್ಲೇ ಇಲ್ಲ.
ಹೆಸರು ಪರಿಹಾರವು ಪ್ರತ್ಯೇಕ ಕಾರಣದಿಂದಲ್ಲ, ಸಂಬಂಧಿತ ಕಾರಣದಿಂದ ವಿಫಲವಾಗುತ್ತದೆ. ತಳ್ಳಲಾದ dhcp-option DNS ನಮೂದುಗಳನ್ನು ಅದೇ ಫ್ಲ್ಯಾಗ್ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಆಂತರಿಕ ಹೋಸ್ಟ್ಗಳ ಪ್ರಶ್ನೆಗಳು ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ಒದಗಿಸಿದ ಯಾವುದೇ ಪರಿಹಾರಕಕ್ಕೆ ಹೋಗುತ್ತವೆ. ಆ ಪರಿಹಾರಕಕ್ಕೆ ಕಚೇರಿಗೆ ವಲಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರಶ್ನೆ ವಿಫಲವಾಗುತ್ತದೆ ಅಥವಾ ಸಾರ್ವಜನಿಕ ಉತ್ತರ ನೀಡುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯವು ಸರ್ವರ್ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ ಆದರೆ ಅದು ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯ ಸಮಸ್ಯೆ. ಹೆಸರಿಗಿಂತ ಮೊದಲು ವಿಳಾಸವನ್ನು ಪರೀಕ್ಷಿಸುವುದೇ ಎರಡನ್ನೂ ಬೇರ್ಪಡಿಸುತ್ತದೆ.
ಫ್ಲ್ಯಾಗ್ ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್ ಫಿಲ್ಟರ್ ನಡುವಿನ ಆಯ್ಕೆ
ಎರಡೂ ಆಯ್ಕೆಗಳು ಒಂದೇ ದೂರಿನ ಬೇರೆ ಬೇರೆ ರೂಪಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ, ಮತ್ತು ಕೆಟ್ಟ ಆಯ್ಕೆಯೇ «ಸಂಪರ್ಕಗೊಂಡಿದೆ ಆದರೆ ನಿಷ್ಪ್ರಯೋಜಕ» ಸ್ಥಿತಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಒಂದು ತಳ್ಳಲಾದ ನೀತಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಿಸುತ್ತದೆ, ಇನ್ನೊಂದು ಅದನ್ನು ಪ್ರಿಫಿಕ್ಸ್ ಮೂಲಕ ಸಂಪಾದಿಸುತ್ತದೆ. ಕೋಷ್ಟಕ ಸಂಕ್ಷಿಪ್ತ ಆವೃತ್ತಿಯನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಅದರ ನಂತರದ ಪ್ಯಾರಾಗ್ರಾಫ್ ಜನರನ್ನು ಹಿಡಿಯುವ ಭಾಗವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter ಮೂರು ಕ್ರಿಯಾಪದಗಳಿರುವ ಪ್ರಿಫಿಕ್ಸ್ ಹೊಂದಾಣಿಕೆದಾರ, ಆದ್ದರಿಂದ ಅದು ಸಾಲುಗಳ ಕುಟುಂಬವನ್ನು ಸ್ವೀಕರಿಸಬಹುದು, ಅವನ್ನು ಸದ್ದಿಲ್ಲದೆ ನಿರ್ಲಕ್ಷಿಸಬಹುದು, ಅಥವಾ ಪ್ರಿಫಿಕ್ಸ್ ಕಾಣಿಸಿಕೊಂಡಾಗ ಸಂಪರ್ಕವನ್ನೇ ನಿರಾಕರಿಸಬಹುದು. ಕೊನೆಯ ನಡವಳಿಕೆಯೇ ತಿಳಿಯಲು ಯೋಗ್ಯವಾದದ್ದು: ನಿರಾಕರಣೆ ನಿಯಮವು ನೀತಿ ಭಿನ್ನಾಭಿಪ್ರಾಯವನ್ನು ಸದ್ದಿಲ್ಲದ ಬಿಟ್ಟುಬಿಡುವಿಕೆಯ ಬದಲು ವಿಫಲ ಹ್ಯಾಂಡ್ಶೇಕ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. OpenVPN 2.6 ಕೈಪಿಡಿ ಸ್ವೀಕೃತ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಮತ್ತು ಪ್ರತಿ ಕ್ರಿಯಾಪದದ ನಿಖರ ಅರ್ಥವನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.
ಸಾಮಾನ್ಯ ಮಧ್ಯಮ ಮಾರ್ಗವೆಂದರೆ redirect-gateway ಅನ್ನು ಮಾತ್ರ ನಿರಾಕರಿಸಿ ಕಚೇರಿ ಮಾರ್ಗಗಳು ಮತ್ತು DNS ಉದ್ದೇಶಿಸಿದಂತೆ ಬರಲು ಬಿಡುವುದು. ಇದು ಸರ್ವರ್ ನಿಮಗಿಂತ ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಭಾಗಗಳಿಗೆ ತಳ್ಳುವಿಕೆಯನ್ನು ಕಾರ್ಯನಿರ್ವಹಿಸುವಂತೆ ಇಡುತ್ತದೆ, ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ವಶಪಡಿಸಿಕೊಳ್ಳುತ್ತಿದ್ದ ಆ ಒಂದೇ ಸಾಲನ್ನು ತಡೆಯುತ್ತದೆ.
ಕೈಯಿಂದ ಮಾರ್ಗಗಳು ಮತ್ತು ಪರಿಹಾರಕ ಸೇರಿಸುವುದು
ನೀವು ಫ್ಲ್ಯಾಗ್ ಇಟ್ಟುಕೊಂಡರೆ, ಪ್ರೊಫೈಲ್ ಸರ್ವರ್ ಹೇಳುತ್ತಿದ್ದುದನ್ನು ಹೇಳಬೇಕು. ಕ್ಲೈಂಟ್ ಬದಿಯ route ಸೂಚನೆಗಳು ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯ ನಂತರ ಅನ್ವಯವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವು ಫ್ಲ್ಯಾಗ್ ಜೊತೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಅದರಿಂದ ನಿರ್ಬಂಧಿಸಲ್ಪಡುವುದಿಲ್ಲ. ಅವನ್ನು ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಇಡಿ, ಸಂವಾದಾತ್ಮಕ ಆದೇಶ ಸಾಲಿನಲ್ಲಿ ಅಲ್ಲ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ಮರುಸಂಪರ್ಕ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸ್ಥಿತಿಯನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS ಸಾಲು ಅಹಿತಕರ ಸ್ಥಾನದಲ್ಲಿದೆ: ಇದು ಕ್ಲೈಂಟ್ ಬದಿಯ ಸೂಚನೆ, ಆದರೆ ಕೆಲವು ಕ್ಲೈಂಟ್ಗಳು ಅದನ್ನು ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ DNS ಏಕೀಕರಣದ ಮೂಲಕ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತವೆ, ಅದು ಲಿಂಕ್ ಬದಲಾದಾಗ ಅದರ ಮೇಲೆ ಬರೆಯಬಹುದು. systemd ಹೋಸ್ಟ್ನಲ್ಲಿ ಪರಿಹಾರಕವನ್ನು ನೇರವಾಗಿ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಹೊಂದಿಸುವುದು ಕ್ಲೈಂಟ್ ಆದ್ಯತಾ ಸ್ಪರ್ಧೆಯನ್ನು ಗೆಲ್ಲುತ್ತದೆ ಎಂದು ಆಶಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಊಹಿಸಬಹುದಾದದ್ದು:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comಮಾರ್ಗನಿರ್ದೇಶನ ಡೊಮೇನ್ ವಿಳಾಸದಷ್ಟೇ ಮುಖ್ಯ. ಅದಿಲ್ಲದೆ ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳ ಪ್ರಶ್ನೆಗಳು ಸಹ ಆಂತರಿಕ ಪರಿಹಾರಕಕ್ಕೆ ಕಳುಹಿಸಬಹುದು, ಮತ್ತು ಪುನರಾವರ್ತನೆಯನ್ನು ನಿರಾಕರಿಸುವ ಯಾವುದೇ ಆಂತರಿಕ ಪರಿಹಾರಕವು ಖಾಸಗಿ ವಲಯ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೂ ಬ್ರೌಸಿಂಗ್ ಮುರಿಯುತ್ತದೆ. ಅದರೊಂದಿಗೆ ಆ ಪ್ರತ್ಯಯದ ಅಡಿಯ ಹೆಸರುಗಳು ಮಾತ್ರ ಟನೆಲ್ ಪರಿಹಾರಕಕ್ಕೆ ಮಾರ್ಗನಿರ್ದೇಶನಗೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಉಳಿದೆಲ್ಲವೂ ಭೌತಿಕ ಲಿಂಕ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತವೆ.
ಫಲಿತಾಂಶ ಪರಿಶೀಲನೆ: ವಿಳಾಸ, ಹೆಸರು ಮತ್ತು ಹೊರಗಿನ ಮಾರ್ಗ
ಮೂರು ಪರೀಕ್ಷೆಗಳು ಸಂಭಾವ್ಯ ವೈಫಲ್ಯಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತವೆ. ಮೊದಲು IP ಮೂಲಕ ಖಾಸಗಿ ವಿಳಾಸ ಪಡೆಯಿರಿ, ನಂತರ ಹೆಸರಿನಿಂದ ಅದೇ ಹೋಸ್ಟ್, ನಂತರ ಸಾಮಾನ್ಯ ಸಾರ್ವಜನಿಕ ಸೈಟ್. ಕೆಲಸ ಮಾಡುವ IP ಮತ್ತು ವಿಫಲ ಹೆಸರು ಪರಿಹಾರಕದತ್ತ ಸೂಚಿಸುತ್ತದೆ; ವಿಫಲ IP ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಹೆಸರು ಮಾರ್ಗನಿರ್ದೇಶನದತ್ತ ಸೂಚಿಸುತ್ತದೆ; ಎರಡೂ ವಿಫಲವಾದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಟನೆಲ್ ಮಾರ್ಗದಲ್ಲಿಲ್ಲ.
ನಂತರ ಒಳಗೆ ಅಲ್ಲ, ಹೊರಗೆ ನೋಡಿ. ಟನೆಲ್ನ ಅಂತ್ಯ ಬಿಂದುವಿನ ಸ್ವಂತ ಮಾರ್ಗ ಬದಲಾವಣೆಯನ್ನು ಉಳಿದುಕೊಳ್ಳಬೇಕು, ಮತ್ತು ಯಾವುದೇ ತಡೆಯುವ ವೈಫಲ್ಯವು ಅಂತ್ಯ ಬಿಂದುವನ್ನು ಹಿಡಿಯದೆ ಟನೆಲ್ಗೆ ಸೀಮಿತವಾಗಿರಬೇಕು. ಟನೆಲ್ ಬಿದ್ದ ನಂತರವೂ ಬ್ರೌಸಿಂಗ್ ಮುಂದುವರಿಸುವ ಕ್ಲೈಂಟ್ ಮಾರ್ಗನಿರ್ದೇಶನ ಸಮಸ್ಯೆಯಲ್ಲ, ನೀತಿ ಸಮಸ್ಯೆ, ಮತ್ತು ಅದು ಮೇಲಿನ ಮೂರು ಪರೀಕ್ಷೆಗಳ ಯಾವುದರಲ್ಲೂ ಕಾಣಿಸುವುದಿಲ್ಲ.
ಅಂತಿಮ ಪಟ್ಟಿಯನ್ನು ಪ್ರೊಫೈಲ್ನ ದಾಖಲಾತಿಯಲ್ಲಿ ಬರೆಯಿರಿ: ಮಾರ್ಗಗಳು, ಪರಿಹಾರಕ, ಡೊಮೇನ್ಗಳು ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಇರುವ ಕಾರಣ. ಅದೇ ಕೋಷ್ಟಕವನ್ನು ಮರುಸೃಷ್ಟಿಸುವ ಮರುಸಂಪರ್ಕವೇ ಸ್ಥಳೀಯ ನೀತಿ ಪೂರ್ಣವಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ಏಕೈಕ ಸಾಕ್ಷ್ಯ. ಟನೆಲ್ ಮೇಲಿರುವಾಗ ಮತ್ತು ಮೂರೂ ಪರೀಕ್ಷೆಗಳು ಉತ್ತೀರ್ಣವಾಗಿದ್ದರೂ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಮುಂದೆ ನೋಡಬೇಕಾದ ಸ್ಥಳವು ಈಗಾಗಲೇ ಪರಿಶೀಲಿಸಿದ ಪ್ರಮಾಣಪತ್ರಗಳಲ್ಲ, ಬದಲಾಗಿ «ಸಂಪರ್ಕಗೊಂಡಿದೆ ಆದರೆ ಆಫ್ಲೈನ್» ಸಮಸ್ಯೆಗಳ ವರ್ಗ.