ಕಿಲ್ ಸ್ವಿಚ್ ಯಾವುದೇ ಸಂಚಾರ ಹರಿಯುವ ಮೊದಲು VPN ಸರ್ವರ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ
ಕಿಲ್ ಸ್ವಿಚ್ ಯಾವ ಹಂತವನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ: ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹುಡುಕಾಟ, ಹೊರಗಿನ ಮಾರ್ಗ, ಹಿಂತಿರುಗುವ ದಾರಿ ಮತ್ತು ಹಳೆಯ ಪೀರ್ ವಿನಾಯಿತಿಗಳು — ಊಹೆಗಳ ಬದಲು ಕೌಂಟರ್‌ಗಳೊಂದಿಗೆ.
ಕಿಲ್ ಸ್ವಿಚ್‌ಗಳು ಜನರು ನಿರೀಕ್ಷಿಸದ ದಿಕ್ಕಿನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ: ಅವು ಸುರಂಗ ಕೆಳಗಿರುವಾಗ ಸಂಚಾರವನ್ನು ನಿರ್ಬಂಧಿಸಲು ನಿರ್ಮಿಸಲಾಗಿವೆ, ಮತ್ತು ಸುರಂಗವನ್ನು ನಿರ್ಮಿಸುವ ಪ್ಯಾಕೆಟ್‌ಗಳೇ ಸಂಚಾರ. ಇದೇ ಇಡೀ ದೋಷ. ಸುರಂಗದ ಮೂಲಕ ಹೊರಗೆ ಹೋಗದ ಎಲ್ಲವನ್ನೂ ಬಿಡುವ ನಿಯಮಗಳ ಗುಂಪು ಸುರಂಗವನ್ನು ಎತ್ತುವ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನೂ ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಲೂಪ್‌ನಲ್ಲಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ ಮತ್ತು ದೋಷವು ಮೊದಲು ಪರಿಶೀಲಿಸಿದ ಹಂತಕ್ಕೆ ಸೇರುತ್ತದೆ. ಫೈರ್‌ವಾಲ್ ಅನ್ನು ವಿಸ್ತರಿಸುವ ಮೊದಲು ಮೂರು ಹಂತಗಳಲ್ಲಿ ಯಾವುದನ್ನು ನಿರಾಕರಿಸಲಾಗುತ್ತಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ: ಹೆಸರಿನ ಹುಡುಕಾಟ, ಪೀರ್‌ಗೆ ಹೋಗುವ ಹೊರಗಿನ ಪ್ಯಾಕೆಟ್, ಅಥವಾ ಹಿಂತಿರುಗಿ ಬರುವ ಉತ್ತರ.
ಸುರಂಗ ಮತ್ತು ಅದರ ಸ್ವಂತ ಸಾಗಣೆ ಪರಸ್ಪರ ಹೇಗೆ ಅವಲಂಬಿತವಾಗಿವೆ
VPN ಕ್ಲೈಂಟ್ ಅನ್ನು ಒಂದೇ ಸಾಕೆಟ್ ಮಾರ್ಗವನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಎರಡು ನೆಟ್‌ವರ್ಕ್ ಸ್ಥಿತಿಗಳಾಗಿ ಓದಿ. ಸುರಂಗ ಇರುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ಭೌತಿಕ ಅಡಾಪ್ಟರ್‌ನಲ್ಲಿ ಸಾಕೆಟ್ ತೆರೆದು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಫ್ರೇಮ್‌ಗಳನ್ನು ಪೀರ್‌ನ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಆ ವಿನಿಮಯ ಯಶಸ್ವಿಯಾದ ನಂತರವೇ ಅದು ಸುರಂಗ ಸಾಧನವನ್ನು ರಚಿಸಿ ಮಾರ್ಗಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಕಿಲ್ ಸ್ವಿಚ್ ಎರಡನೇ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ನೀತಿ, ಎರಡಕ್ಕೂ ಅನ್ವಯವಾಗುವಷ್ಟು ವಿಶಾಲವಾಗಿ ಬರೆಯಲಾಗಿದೆ.
ಇಂಟರ್‌ಫೇಸ್ ಆಧಾರಿತ ನಿಯಮಗಳು ಸಾಮಾನ್ಯ ರೂಪ: ಇದರ ಮೂಲಕ ಹೊರಗೆ ಹೋಗುವುದನ್ನು ಸ್ವೀಕರಿಸಿ tun0 ಅಥವಾ wg0, ಉಳಿದ ಔಟ್‌ಪುಟ್ ಮಾರ್ಗವನ್ನು ಬಿಡಿ. ಈ ಸೂತ್ರೀಕರಣವು ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ಸರ್ವರ್ ಸಂಪರ್ಕಕ್ಕೆ ವಿನಾಯಿತಿ ನೀಡಲಾಗದು, ಆದ್ದರಿಂದ ಸರಿಯಾದ ಅನುಷ್ಠಾನವು ಆ ವಿನಾಯಿತಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ನೀವೂ ಕೈಯಿಂದ ನಿಯಮ ಬರೆಯುವಾಗ ಹಾಗೆ ಮಾಡುತ್ತೀರಿ. Windows ಮತ್ತು macOS ನಲ್ಲಿ ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ನಿಯಮಗಳು ಇಂಟರ್‌ಫೇಸ್ ಬದಲು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೊಂದಿಸಿ ಇದರ ಒಂದು ಭಾಗವನ್ನು ತಪ್ಪಿಸುತ್ತವೆ, ಆದರೆ ಪ್ರಕ್ರಿಯೆಯೂ ಸುರಂಗ ಇರುವ ಮೊದಲು ಹೊರಗೆ ಹೋಗಬೇಕು.
ಮೂರು ಹಂತಗಳು, ಅವು ಸಂಭವಿಸುವ ಕ್ರಮದಲ್ಲಿ
ಮೊದಲ ಹಂತ ಪರಿಹಾರ. ಪ್ರೊಫೈಲ್ ಅಕ್ಷರಶಃ ವಿಳಾಸದ ಬದಲು ಹೋಸ್ಟ್‌ನಾಮ್ ಸಂಗ್ರಹಿಸಿದಾಗ, ಏನನ್ನಾದರೂ ಕಳುಹಿಸುವ ಮೊದಲು ಕ್ಲೈಂಟ್‌ಗೆ DNS ಉತ್ತರ ಬೇಕು. DNS ಅನ್ನು ಸುರಂಗದ ಪರಿಹಾರಕಕ್ಕೆ ತಿರುಗಿಸುವ ಪ್ರೊಫೈಲ್ ಒಂದು ಬಿಕ್ಕಟ್ಟು ಸೃಷ್ಟಿಸುತ್ತದೆ: ಪರಿಹಾರಕವು ಹುಡುಕಾಟ ಸಕ್ರಿಯಗೊಳಿಸಬೇಕಾದ ಸುರಂಗದ ಮೂಲಕವೇ ತಲುಪುತ್ತದೆ. ಸುರಂಗದ ಹೊರಗೆ ಪರಿಹರಿಸುವುದು, ಅಥವಾ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ವಿಳಾಸಕ್ಕೆ ಪಿನ್ ಮಾಡುವುದು, ಈ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ಎರಡನೇ ಹಂತ ಹೊರಗಿನ ಪ್ಯಾಕೆಟ್, ಅದು ಈ ಕ್ರಮದಲ್ಲಿ ಮೊದಲು ಮಾರ್ಗನಿರ್ದೇಶನ ನಂತರ ಫೈರ್‌ವಾಲ್ ದಾಟಬೇಕು. wireguard-tools WireGuard ಗಾಗಿ ಇದರ ಮಾರ್ಗನಿರ್ದೇಶನ ಅರ್ಧವನ್ನು ತನ್ನ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಗುರುತಿಸಿ, ಈಗ ಸ್ಥಾಪಿಸಿದ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬಿಟ್ಟುಬಿಡಲು ನೀತಿ ನಿಯಮ ಸೇರಿಸಿ ನಿರ್ವಹಿಸುತ್ತದೆ; wg-quick ನ ಕೈಪಿಡಿ ಪುಟ ಆ ನಿಯಮ ಮತ್ತು ಅದು ಬಳಸುವ ಕೋಷ್ಟಕವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಆ ಮಾರ್ಗನಿರ್ದೇಶನವನ್ನು ಕೈಯಿಂದ ಮತ್ತೆ ನಿರ್ಮಿಸಿ, ಅಥವಾ ಎರಡನೇ ಸಾಧನವು ನಿಯಮಗಳನ್ನು ಮತ್ತೆ ಬರೆಯಲು ಬಿಡಿ, ಗುರುತಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳು ಅವು ರಚಿಸಬೇಕಾದ ಸುರಂಗಕ್ಕೆ ಮತ್ತೆ ಕಳುಹಿಸಬಹುದು.
ಮೂರನೇ ಹಂತ ಹಿಂತಿರುಗುವ ದಾರಿ. ಉತ್ತರವಿಲ್ಲದ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಹೊರಹೋಗುವ ಬಿಡುವಿಕೆಯ ಸಾಕ್ಷ್ಯವಲ್ಲ; ಅದು ಸರ್ವರ್‌ನ ಒಳಬರುವ ನಿಯಮ ಅಥವಾ ಮ್ಯಾಪಿಂಗ್ ಮರೆತ NAT ಸಾಧನದೊಂದಿಗೂ ಸಮಾನವಾಗಿ ಹೊಂದುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಮುಟ್ಟುವ ಮೊದಲು ಇವನ್ನು ಬೇರ್ಪಡಿಸಿ.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
ಕ್ಲೈಂಟ್‌ಗಳು ಕಂಡುಕೊಂಡ ಲಕ್ಷಣವನ್ನು ದಾಖಲಿಸುತ್ತವೆ, ವಿಫಲವಾದ ಹಂತವನ್ನಲ್ಲ, ಆದ್ದರಿಂದ ಕೋಷ್ಟಕ ಸಾಮಾನ್ಯವಾಗಿ ಲಾಗ್‌ಗಿಂತ ವೇಗವಾಗಿರುತ್ತದೆ.
ಕೌಂಟರ್‌ಗಳು ಲಾಗ್‌ಗಳಿಗಿಂತ ವೇಗವಾಗಿ ನಿರ್ಧರಿಸುತ್ತವೆ
Linux ನಲ್ಲಿ, nft list ruleset ಅಥವಾ iptables -vnL OUTPUT ಪ್ರತಿ ನಿಯಮಕ್ಕೆ ಪ್ಯಾಕೆಟ್ ಕೌಂಟರ್ ಮುದ್ರಿಸುತ್ತದೆ. ಒಮ್ಮೆ ಸಂಪರ್ಕಿಸಿ, ವಿಫಲವಾಗಲು ಬಿಡಿ, ನಂತರ ಕೌಂಟರ್‌ಗಳನ್ನು ಮತ್ತೆ ಓದಿ. ಕೌಂಟರ್ ಚಲಿಸಿದ ನಿಯಮವೇ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಬಡಿದ ನಿಯಮ; ಎಲ್ಲೂ ಏನೂ ಚಲಿಸದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಎಂದೂ ಫೈರ್‌ವಾಲ್ ತಲುಪಲಿಲ್ಲ. ನಿಯಮಗಳ ಗುಂಪು ತನ್ನದೇ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಬಿಟ್ಟದ್ದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ, ಅದನ್ನು ಹೇಳಿದ್ದು ಕೌಂಟರ್‌ಗಳಷ್ಟೇ.
ಎಂದೂ ಫೈರ್‌ವಾಲ್ ತಲುಪಲಿಲ್ಲ ಮತ್ತು ಎಂದೂ ಹೋಸ್ಟ್ ಬಿಟ್ಟಿಲ್ಲ ಎಂಬುದನ್ನು ಬೇರ್ಪಡಿಸಲು, ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನೇ ಗಮನಿಸಿ. ip -s link show dev wlan0 ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು tcpdump -ni wlan0 udp port 51820 ಫ್ರೇಮ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತಿರುವಾಗ ಅದು ಸಮತಟ್ಟಾಗಿ ಉಳಿದರೆ, ದೋಷ netfilter ಮೇಲಿದೆ: ಕಾಣೆಯಾದ ಪೀರ್ ಮಾರ್ಗ, ಇನ್ನೂ ಇಲ್ಲದ ಸಾಧನಕ್ಕೆ ತೋರಿಸುವ ನೀತಿ ನಿಯಮ, ಅಥವಾ ಕ್ಲೈಂಟ್ ನುಂಗುವ ಸಾಕೆಟ್ ದೋಷ.
ವಿನಾಯಿತಿಗಳನ್ನು ದಾಖಲೆ ವಿಳಾಸಗಳ ಮೇಲೆ ಪರೀಕ್ಷಿಸಿ, ಉದಾಹರಣೆಗೆ 203.0.113.10, ತಪ್ಪು ಇನ್ನೊಬ್ಬರ ಹೋಸ್ಟ್ ಪರೀಕ್ಷಿಸದಂತೆ.
ಹಳೆಯ ಎಂಡ್‌ಪಾಯಿಂಟ್ ವಿನಾಯಿತಿ ಸರ್ವರ್ ನಿಂತಂತೆ ಓದುತ್ತದೆ
ಅತ್ಯಂತ ಗೊಂದಲದ ಆವೃತ್ತಿ ಪೀರ್‌ನ ವಿಳಾಸ ಬದಲಾದ ನಂತರ ಕಾಣಿಸುತ್ತದೆ: ಕ್ರಿಯಾತ್ಮಕ ವಿಳಾಸ ಸೇವೆ ಅದನ್ನು ಸರಿಸಿದೆ, ಹೋಸ್ಟ್ ಮತ್ತೆ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಅಥವಾ ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ನ ಹೊರಹೋಗುವ ವಿಳಾಸ ಬೇರೆ. ವಿನಾಯಿತಿ ಇನ್ನೂ ಹಳೆಯ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೊಸದಕ್ಕೆ ಹೋಗುವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಬಿಡುವ ನಿಯಮಕ್ಕೆ ಸಿಗುತ್ತವೆ. ಅದೇ ಸಂರಚನೆ ನಿನ್ನೆ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು, ಆದ್ದರಿಂದ ಜನರು ಸರ್ವರ್ ಪರಿಶೀಲನೆಯಿಂದ ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.
ಫೈರ್‌ವಾಲ್ ನಿಯಮದ ಒಳಗಿನ ಹೋಸ್ಟ್‌ನಾಮ್ ನಿಮ್ಮನ್ನು ಉಳಿಸುವುದಿಲ್ಲ. nftables ನಲ್ಲಿ ಹೆಸರು ನಿಯಮಗಳ ಗುಂಪು ಲೋಡ್ ಆಗುವಾಗ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಆ ಕ್ಷಣದಲ್ಲಿ ಇದ್ದ ವಿಳಾಸವನ್ನು ಪಿನ್ ಮಾಡಿ ಅಕ್ಷರಶಃ ವಿಳಾಸದಂತೆ ಹಳೆಯದಾಗುತ್ತದೆ. ಶಾಶ್ವತ ಪರಿಹಾರ ಎಂದರೆ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಬದಲಾದಾಗ ವಿನಾಯಿತಿ ನವೀಕರಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಸಣ್ಣದಾಗಿ ಇಡುವುದು: ಒಂದು ಪೀರ್ ವಿಳಾಸ, ಒಂದು ಸಾಗಣೆ ಪೋರ್ಟ್. ವಿಳಾಸ ಬದಲಾವಣೆಯನ್ನು ತಾಳಿಕೊಳ್ಳುವಷ್ಟು ಅಗಲವಾದ ಶ್ರೇಣಿ ಸಂಬಂಧವಿಲ್ಲದ ಸಂಚಾರವನ್ನೂ ಹೊರಬಿಡಲು ಸಾಕಷ್ಟು ಅಗಲವಾಗಿದೆ.
ಕಿಲ್ ಸ್ವಿಚ್ ಸರ್ವರ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಚಲಿಸಿದಾಗ
ಅದೇ ಅವಲಂಬನೆ ಇನ್ನೊಂದು ತುದಿಯಲ್ಲೂ ಇದೆ, ಮತ್ತು ಅಲ್ಲಿ ಅದನ್ನು ತಪ್ಪಿಸುವುದು ಸುಲಭ. ನಿಮ್ಮ VPN ಸರ್ವರ್ ಆಗಿರುವ ಯಂತ್ರವು ಕಿಲ್ ಸ್ವಿಚ್ ಇರುವ ಡೆಸ್ಕ್‌ಟಾಪ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಅಥವಾ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಿಂದ ನಕಲಿಸಿದ ಫೈರ್‌ವಾಲ್ ಪ್ರೊಫೈಲ್ ಅನ್ನೂ ಚಲಾಯಿಸಿದರೆ, ಅದರ ಬಿಡುವ ನಿಯಮಗಳು ಸುರಂಗಗಳನ್ನು ಮುಗಿಸುವ ಸೇವೆಗೆ ಅನ್ವಯವಾಗುತ್ತವೆ. ಕ್ಲೈಂಟ್‌ನ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ಗೆ ಉತ್ತರಗಳು ಬೀಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಸರ್ವರ್ ಆರೋಗ್ಯವಾಗಿ ಕಾಣುತ್ತಿದ್ದರೂ ಅದರ ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್ ಬಳಕೆಯಾಗದೆ ಇದ್ದರೂ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಲು ವಿಫಲವಾಗುತ್ತದೆ.
ಆ ಹೋಸ್ಟ್‌ಗೆ ಬಿಡುವ ಮೊದಲು ಮೂರು ಸಣ್ಣ ಸ್ವೀಕೃತಿಗಳು ಬೇಕು: ಭೌತಿಕ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಕೇಳುವ ಪೋರ್ಟ್, ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಸಂಚಾರಕ್ಕೆ ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್, ಮತ್ತು ಸುರಂಗದಿಂದ ಕ್ಲೈಂಟ್‌ಗಳು ತಲುಪಬೇಕಾದ ಕಡೆಗೆ ಮುಂದೂಡುವಿಕೆ. ಸ್ಥಾಪಿತ ಗುಂಪನ್ನು ಇದರಿಂದ ಓದಿ: nft list ruleset, iptables -S, ಅಥವಾ pfctl -sr ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು, ಮತ್ತು ಉಳಿಸಿದ ನಿಯಮಗಳ ಗುಂಪು ಮರುಬೂಟ್ ಅನ್ನು ಉಳಿದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನೆನಪಿಡಿ, ಆದ್ದರಿಂದ ಅಲ್ಲಿನ ತಪ್ಪು ಅದನ್ನು ಮಾಡಿದ ಪ್ರಕ್ರಿಯೆಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುತ್ತದೆ.
ಯಂತ್ರವನ್ನು ಮುಚ್ಚಿಟ್ಟುಕೊಳ್ಳುವ ಚೇತರಿಕೆ ಕ್ರಮ
ಪ್ರೊಫೈಲ್‌ನಿಂದ ಹೊರಮುಖವಾಗಿ ಕೆಲಸ ಮಾಡಿ. ಕ್ಲೈಂಟ್ ಬಳಸುವ ಪೀರ್ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಓದಿ, ಸುರಂಗ ಇಲ್ಲದೆ ಹೋಸ್ಟ್‌ನಾಮ್ ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಭೌತಿಕ ಅಡಾಪ್ಟರ್‌ನಲ್ಲಿ ಮಾತ್ರ ಆ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್‌ಗೆ ಒಂದು ವಿನಾಯಿತಿ ಸೇರಿಸಿ. ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಕಳುಹಿಸುವ ಕೌಂಟರ್ ಗಮನಿಸಿ; ಪೂರ್ಣಗೊಂಡ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಎರಡನೇ ಹಂತ ಸರಿಪಡಿಸಲಾಗಿದೆ ಎಂಬ ಸಂಕೇತ.
ಪರೀಕ್ಷಿಸುವಾಗ ಬಿಡುವ ಉಳಿದ ನೀತಿಯನ್ನು ಅದರ ಜಾಗದಲ್ಲೇ ಬಿಡಿ. ನಿರುಪದ್ರವ ಪರಿಶೀಲನೆ ಎಂದರೆ ಸಂಬಂಧವಿಲ್ಲದ ದಾಖಲೆ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕ ಪ್ರಯತ್ನಿಸಿ ಅದು ಇನ್ನೂ ಸಮಯ ಮುಗಿದು ನಿಲ್ಲುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುವುದು, ಇದು ಕಿಲ್ ಸ್ವಿಚ್ ಆಫ್ ಆಗಿಲ್ಲ ಎಂದಲ್ಲ, ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಸುರಂಗ ಸ್ಥಿರವಾದ ನಂತರ ವಿನಾಯಿತಿಯನ್ನು ಬಿಗಿಗೊಳಿಸಿ, ಮತ್ತು ಅನುಕೂಲ ಎಂದು ಕ್ಲೈಂಟ್ ಪ್ರೋಗ್ರಾಂಗೆ ಶಾಶ್ವತ ಎಲ್ಲದಕ್ಕೂ ಅನುಮತಿ ಬಿಡಬೇಡಿ.
ಸುರಂಗ ಏರಿದರೂ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಉಳಿದ ಹಂತಗಳು ಇದಲ್ಲ: ವಿಭಜಿತ DNS, MTU ಮತ್ತು ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಮಾರ್ಗನಿರ್ದೇಶನ ಪ್ರತಿಯೊಂದೂ ಸಂಪರ್ಕಿತ ಸುರಂಗದೊಂದಿಗೆ ಮುರಿದ ಸಂಚಾರವನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಮೊದಲ ಪರಿಶೀಲನೆ ಇದೆ.