ਕਿੱਲ ਸਵਿੱਚ ਕਿਸੇ ਵੀ ਟ੍ਰੈਫਿਕ ਦੇ ਵਹਿਣ ਤੋਂ ਪਹਿਲਾਂ 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, ਅਤੇ ਪ੍ਰਤੀ-ਐਪਲੀਕੇਸ਼ਨ ਰੂਟਿੰਗ ਹਰ ਇੱਕ ਜੁੜਿਆ ਟਨਲ ਅਤੇ ਟੁੱਟਿਆ ਟ੍ਰੈਫਿਕ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਦੀ ਪਹਿਲੀ ਜਾਂਚ ਵੱਖਰੀ ਹੈ।