ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਦਾ ਜਵਾਬ ਸੁਰੰਗ ਵਿੱਚੋਂ ਨਹੀਂ ਲੰਘਦਾ
ਸੁਰੰਗ ਨੂੰ ਛੱਡ ਜਾਣ ਵਾਲਾ ਜਵਾਬ ਦੂਰ ਦੇ ਪਾਸੇ ਦਾ ਰੂਟਿੰਗ ਫੈਸਲਾ ਹੈ। ਹੋਸਟ ਟੇਬਲ, ਸਿਲੈਕਟਰ ਅਤੇ rp_filter ਜਾਂਚੋ, ਫਿਰ ਰੂਟ ਜਾਂ NAT ਚੁਣੋ।
ਮੈਂ ਇੱਕ ਸਵੇਰ ਅਜਿਹੀ ਸੁਰੰਗ ਉੱਤੇ ਲਾਈ ਜੋ ਸਾਫ਼-ਸੁਥਰੀ ਚੜ੍ਹੀ ਅਤੇ ਟ੍ਰੈਫਿਕ ਬਿਲਕੁਲ ਇੱਕ ਹੀ ਦਿਸ਼ਾ ਵਿੱਚ ਲੈ ਗਈ: ਸ਼ਾਖਾ ਹੈੱਡਕੁਆਰਟਰ ਦੇ ਫਾਈਲ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੀ ਸੀ, ਅਤੇ ਹੈੱਡਕੁਆਰਟਰ ਤੋਂ ਸ਼ਾਖਾ ਵਿੱਚ ਖੁੱਲ੍ਹਣ ਵਾਲਾ ਹਰ ਕਨੈਕਸ਼ਨ ਪਹਿਲੇ SYN ਉੱਤੇ ਹੀ ਮਰ ਜਾਂਦਾ ਸੀ। SA ਚਾਲੂ ਸਨ, ਸੁਰੰਗ ਦੇ ਕਾਊਂਟਰ ਵੱਧ ਰਹੇ ਸਨ, ਅਤੇ ਹੈਂਡਸ਼ੇਕ ਕਦੇ ਵੀ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ। ਜਵਾਬ ਕਿਤੇ ਅਜਿਹੀ ਥਾਂ ਰੂਟ ਹੋ ਰਿਹਾ ਸੀ ਜਿੱਥੇ ਸੁਰੰਗ ਨਹੀਂ ਪਹੁੰਚਦੀ, ਅਤੇ ਇਹ ਚੋਣ ਦੂਰ ਦੇ ਪਾਸੇ ਦੀ ਹੈ। ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਸਿਰਫ਼ ਉਹ ਪੈਕੇਟ ਲੈ ਜਾਂਦਾ ਹੈ ਜੋ ਹੋਸਟ ਗੇਟਵੇ ਨੂੰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਹਰ ਹੋਸਟ ਇਹ ਚੋਣ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ, ਹਰ ਦਿਸ਼ਾ ਵਿੱਚ, ਆਪਣੀ ਰੂਟਿੰਗ ਟੇਬਲ ਤੋਂ ਕਰਦਾ ਹੈ।
ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ ਰੂਟ ਹੁੰਦੀਆਂ ਹਨ
IP ਗੱਲਬਾਤ ਦੀ ਦਿਸ਼ਾ ਦੀ ਕੋਈ ਯਾਦ ਨਹੀਂ ਰੱਖਦਾ। ਪੈਕੇਟ ਭੇਜਣ ਵਾਲਾ ਹਰ ਹੋਸਟ ਆਪਣੀ ਸਭ ਤੋਂ ਲੰਬੀ ਪ੍ਰੀਫਿਕਸ ਖੋਜ ਚਲਾਉਂਦਾ ਹੈ, ਇੱਕ ਅਗਲਾ ਹੌਪ ਚੁਣਦਾ ਹੈ ਅਤੇ ਫੈਸਲਾ ਭੁੱਲ ਜਾਂਦਾ ਹੈ। ਬੇਨਤੀ ਅਤੇ ਜਵਾਬ ਦੋ ਅਸੰਬੰਧਿਤ ਪੈਕੇਟ ਹਨ ਜੋ ਸੰਜੋਗ ਨਾਲ ਇੱਕ ਹੀ ਕਨੈਕਸ਼ਨ ਦੇ ਹਨ, ਅਤੇ ਸੁਰੰਗ ਇੱਕ ਹੌਪ ਹੈ ਜਿਸਨੂੰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਵਰਤ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। IKE ਦੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਵਿੱਚ ਕੁਝ ਵੀ ਦੂਰ ਦੇ ਸਰਵਰ ਨੂੰ ਇਹ ਨਹੀਂ ਸਿਖਾਉਂਦਾ ਕਿ ਤੁਹਾਡੇ ਸਬਨੈੱਟ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਣਾ ਹੈ; ਗੱਲਬਾਤ ਸਿਰਫ਼ ਇਸ ਉੱਤੇ ਸਹਿਮਤ ਹੁੰਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਪ੍ਰੀਫਿਕਸ ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਇਹ ਸਹਿਮਤੀ ਦੂਜਾ ਦਰਵਾਜ਼ਾ ਹੈ। strongSwan ਉੱਤੇ ਟ੍ਰੈਫਿਕ ਸਿਲੈਕਟਰ leftsubnet ਅਤੇ rightsubnet ਹਨ, ਅਤੇ ਜਿਸ ਪੈਕੇਟ ਦਾ ਸਰੋਤ ਜਾਂ ਮੰਜ਼ਿਲ ਤੈਅ ਕੀਤੀ ਜੋੜੀ ਤੋਂ ਬਾਹਰ ਪੈਂਦਾ ਹੈ ਉਹ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਹੁੰਦਾ, ਰੂਟਿੰਗ ਟੇਬਲ ਭਾਵੇਂ ਕੁਝ ਵੀ ਕਹੇ। ਸੁਰੰਗ ਵਿੱਚ ਰੂਟ ਹੋਣ ਵਾਲਾ ਪਰ ਸਿਲੈਕਟਰ ਵਿੱਚ ਨਾ ਹੋਣ ਵਾਲਾ ਪ੍ਰੀਫਿਕਸ ਇੱਕ ਸ਼ਾਂਤ ਇੱਕਤਰਫ਼ਾ ਫੇਲ੍ਹ ਹੈ: ਰੂਟ ਠੀਕ ਦਿਸਦਾ ਹੈ, ਪੈਕੇਟ ਫਿਰ ਵੀ ਖੁੱਲ੍ਹਾ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਜਾਂ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ charon ਲੌਗ ਸ਼ਿਕਾਇਤ ਕਰਦਾ ਹੈ।
ਦੂਰ ਦਾ ਹੋਸਟ ਤੁਹਾਡੀ ਸੁਰੰਗ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਜਾਣਦਾ
ਦੂਰ ਦੇ LAN ਦੇ ਅੰਦਰ ਜਵਾਬ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਨੂੰ ਭੇਜਿਆ ਇੱਕ ਆਮ ਪੈਕੇਟ ਹੈ। ਮੰਜ਼ਿਲ ਹੋਸਟ ਨੂੰ ਕੋਈ IPsec ਹੈਡਰ ਨਹੀਂ ਦਿਸਦਾ ਅਤੇ VPN ਗੇਟਵੇ ਨੂੰ ਤਰਜੀਹ ਦੇਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ; ਉਹ ਤੁਹਾਡਾ ਪ੍ਰੀਫਿਕਸ ਲੱਭਦਾ ਹੈ, ਆਪਣੇ ਡਿਫੌਲਟ ਰੂਟ ਤੋਂ ਵੱਧ ਖਾਸ ਕੁਝ ਨਹੀਂ ਲੱਭਦਾ ਅਤੇ ਉਸੇ ਨੂੰ ਫੜਦਾ ਹੈ। ਜੇ ਡਿਫੌਲਟ ਕਿਸੇ ਮੁੱਖ ਫਾਇਰਵਾਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਫਾਇਰਵਾਲ ਕੋਲ ਸੁਰੰਗ ਵਿੱਚ ਵਾਪਸ ਜਾਣ ਵਾਲਾ ਰੂਟ ਹੈ ਜਾਂ ਨਹੀਂ। ਨਾ ਹੋਵੇ ਤਾਂ ਤੁਹਾਨੂੰ ਸ਼ਾਂਤ ਡ੍ਰੌਪ, ICMP unreachable, ਜਾਂ ਇੰਟਰਨੈੱਟ ਵੱਲ ਦੇ ਇੰਟਰਫੇਸ ਵਿੱਚੋਂ ਨਿਕਲ ਕੇ ਮਰਨ ਵਾਲਾ ਜਵਾਬ ਮਿਲਦਾ ਹੈ।
ਰੂਟ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਦੂਜਾ ਇੰਟਰਫੇਸ ਇਸਨੂੰ ਤੋੜਨ ਲਈ ਕਾਫ਼ੀ ਹੈ। ਦੂਜੇ VLAN ਉੱਤੇ ਪ੍ਰਬੰਧਨ ਲਿੰਕ ਵਾਲਾ NAS, ਬੈਕਅਪ uplink ਵਾਲਾ ਸਰਵਰ, ਇੱਕ ਸਰੋਤ-ਸ਼੍ਰੇਣੀ ਦੂਜੀ ਟੇਬਲ ਵਿੱਚ ਭੇਜਣ ਵਾਲਾ ਨੀਤੀ ਨਿਯਮ: ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਜਵਾਬ ਫੜ ਸਕਦਾ ਹੈ। Linux ਉੱਤੇ, ip rule show ਅਤੇ ip route show table all ਉਹ ਨਿਯਮ ਅਤੇ ਟੇਬਲ ਦਿਖਾਉਂਦੇ ਹਨ ਜਿਹਨਾਂ ਨੂੰ ਡਿਫੌਲਟ ਸੂਚੀ ਲੁਕਾਉਂਦੀ ਹੈ।
ਜਵਾਬ ਭੇਜਣ ਵਾਲੀ ਮਸ਼ੀਨ ਉੱਤੇ ਫੈਸਲਾ ਪੜ੍ਹੋ
ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ, ਅਤੇ ਉਸਨੂੰ ਸਰੋਤ ਪਤਾ ਦਿਓ, ਕਿਉਂਕਿ ਸਰੋਤ-ਆਧਾਰਿਤ ਨਿਯਮ ਜਵਾਬ ਬਦਲ ਦਿੰਦੇ ਹਨ।
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"ਆਉਟਪੁੱਟ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਇੰਟਰਫੇਸ ਅਤੇ ਅਗਲਾ ਹੌਪ ਦੱਸਦੀ ਹੈ। ਜੇ ਇੰਟਰਫੇਸ ਉਹ ਨਹੀਂ ਜੋ VPN ਗੇਟਵੇ ਵੱਲ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਖਰਾਬੀ ਮਿਲ ਗਈ ਹੈ, ਅਤੇ ਬਾਕੀ ਕੰਮ ਇਹ ਤੈਅ ਕਰਨਾ ਹੈ ਕਿ ਰੂਟ ਕਿੱਥੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਗੇਟਵੇ ਤੋਂ ਕੀਤਾ ping ਇੱਥੇ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ: ਉਹ ਅਜਿਹੇ ਪਤੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਦੂਰ ਦਾ ਹੋਸਟ ਰੱਖ ਸਕੇ, ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਦੇ ਪਤੇ ਨਾਲ ਨਹੀਂ।
Windows ਉੱਤੇ ਬਰਾਬਰ Find-NetRoute -RemoteIPAddress 10.10.5.10 ਫੈਸਲੇ ਲਈ ਅਤੇ Get-NetRoute ਟੇਬਲ ਲਈ ਹਨ। ਡਿਫੌਲਟ ਤੋਂ ਵੱਧ ਮੈਟ੍ਰਿਕ ਵਾਲਾ New-NetRoute ਨਾਲ ਜੋੜਿਆ ਰੂਟ ਸ਼ਾਂਤ ਹੋ ਕੇ ਹਾਰ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਮੈਟ੍ਰਿਕ ਕਾਲਮ ਪੜ੍ਹੋ, ਐਂਟਰੀ ਨਹੀਂ। ਫਿਰ ਪੈਕੇਟ ਨਾਲ ਪੱਕਾ ਕਰੋ: ਦੂਰ ਦੇ LAN ਇੰਟਰਫੇਸ ਉੱਤੇ tcpdump -ni any "host 10.10.5.10 and tcp port 445" ਬੇਨਤੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਸੁਰੰਗ ਵਾਲੇ ਪਾਸੇ ਉਹੀ ਫਿਲਟਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਜਵਾਬ ਵਾਪਸ ਆਇਆ ਜਾਂ ਨਹੀਂ। ਬੇਨਤੀ ਦਿਸੇ ਪਰ ਜਵਾਬ ਨਾ ਹੋਵੇ ਦਾ ਮਤਲਬ ਜਵਾਬ ਕਿਤੇ ਹੋਰ ਰੂਟ ਹੋਇਆ ਜਾਂ ਸੁੱਟਿਆ ਗਿਆ; ਗਲਤ ਇੰਟਰਫੇਸ ਉੱਤੇ ਜਵਾਬ ਰੂਟ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਦੋਸ਼ੀ ਦੇ ਦਿੰਦਾ ਹੈ।
ਜਦੋਂ ਸਰਵਰ ਦਾ ਗੇਟਵੇ VPN ਦਾ ਸਿਰਾ ਨਹੀਂ ਹੁੰਦਾ
ਬਹੁਤ ਸਾਈਟਾਂ ਸਰਵਰ ਅਤੇ ਕੇਂਦਰੀਕਰਨ ਜੰਤਰ ਵਿਚਕਾਰ ਫਾਇਰਵਾਲ ਰੱਖਦੀਆਂ ਹਨ। ਉਹ ਫਾਇਰਵਾਲ ਜਵਾਬ ਅੱਗੇ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ ਉਸਨੂੰ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਪ੍ਰੀਫਿਕਸ ਲਈ VPN ਗੇਟਵੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਰੂਟ ਅਤੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਫਾਰਵਰਡਿੰਗ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ। ਸਟੇਟਫੁਲ ਜੰਤਰ ਇਸਨੂੰ ਹੋਰ ਵਿਗਾੜਦੇ ਹਨ: ਬੇਨਤੀ ਉਸ LAN ਹੋਸਟ ਤੋਂ ਫਾਇਰਵਾਲ ਪਾਰ ਕਰ ਗਈ ਜਿਸਨੂੰ ਉਸਨੇ ਆਗਿਆ ਦਿੱਤੀ ਸੀ, ਜਵਾਬ ਹੁਣ ਦੂਜੀ ਦਿਸ਼ਾ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਕਨੈਕਸ਼ਨ-ਟ੍ਰੈਕਿੰਗ ਐਂਟਰੀ ਹੁਣ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ, ਇਸ ਲਈ ਪੈਕੇਟ ਨੂੰ ਨਾਮਨਜ਼ੂਰ ਕਰਨ ਦੀ ਥਾਂ ਅਵੈਧ ਮੰਨ ਕੇ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਟ੍ਰੈਫਿਕ ਗਾਇਬ ਹੁੰਦੇ ਸਮੇਂ ਨੀਤੀ ਲੌਗ ਖਾਲੀ ਦਿਸਣ ਦਾ ਕਾਰਨ ਇਹੀ ਹੈ।
ਗੇਟਵੇ ਦਾ ਆਪਣਾ ਦੂਜਾ ਫਿਲਟਰ ਹੈ। Linux ਦੀ ਉਲਟ-ਰਾਹ ਫਿਲਟਰਿੰਗ ਉਹ ਪੈਕੇਟ ਸੁੱਟਦੀ ਹੈ ਜਿਹਨਾਂ ਦਾ ਸਰੋਤ ਉਸ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਜਿਸ ਉੱਤੇ ਉਹ ਆਏ, ਅਤੇ ਇਹ ਜਾਇਜ਼ ਅਸਮਮਿਤ ਵਾਪਸੀ ਰਾਹ ਦੀ ਬਿਲਕੁਲ ਉਹੀ ਸ਼ਕਲ ਹੈ। strongSwan ਦੀ ਫਾਰਵਰਡਿੰਗ ਗਾਈਡ ਇਸੇ ਕਾਰਨ net.ipv4.ip_forward ਅਤੇ ਢਿੱਲਾ net.ipv4.conf.all.rp_filter ਮੰਗਦੀ ਹੈ। ਕਿਸੇ ਵੀ ਗੇਟਵੇ ਉੱਤੇ ਸਖ਼ਤ ਮੁੱਲ 1 ਸਹੀ ਰੂਟ ਨੂੰ ਸ਼ਾਂਤ ਹੋ ਕੇ ਤੋੜ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ ਪਤਾ ਹੋਵੇ ਤਾਂ nstat -az ਡ੍ਰੌਪ ਦਿਖਾਉਂਦਾ ਹੈ।
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
ਰੂਟ ਕਰੋ ਜਾਂ ਅਨੁਵਾਦ ਕਰੋ, ਫਿਰ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਜਾਂਚੋ
ਦੋਵੇਂ ਮੁਰੰਮਤਾਂ ਬਰਾਬਰ ਨਹੀਂ। ਰੂਟ ਜੋੜਨ ਨਾਲ ਕਲਾਇੰਟ ਦਾ ਪਤਾ ਬਿਨਾਂ ਛੇੜਛਾੜ ਦੇ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਰੋਤ-ਆਧਾਰਿਤ ਨਿਯਮ, ਆਡਿਟ ਲੌਗ ਅਤੇ ਕਾਲ ਕਰਨ ਵਾਲੇ ਨੂੰ ਦਰਜ ਕਰਨ ਵਾਲੀਆਂ ਐਪਾਂ ਕੰਮ ਕਰਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ; ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਫੈਸਲਾ ਲੈਣ ਵਾਲੇ ਹਰ ਹੌਪ ਨੂੰ ਰੂਟ ਚਾਹੀਦਾ ਹੈ, ਭਾਵ ਗਲਤੀ ਦੇ ਹੋਰ ਥਾਂ। ਦੂਰ ਦੇ ਗੇਟਵੇ ਉੱਤੇ ਮਾਸਕਰੇਡ ਵਾਪਸੀ ਰਾਹ ਨੂੰ ਇੱਕ ਹੌਪ ਵਿੱਚ ਸੁੰਗੜ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਜਵਾਬ ਹੁਣ ਗੇਟਵੇ ਆਪਣੇ ਆਪ ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਲੁਕਾਉਂਦਾ ਹੈ ਕਿ ਕਿਸ ਕਲਾਇੰਟ ਨੇ ਕੀ ਕੀਤਾ।
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEਇਸਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣੋ: ਜਿਵੇਂ ਹੀ ਕਲਾਇੰਟ ਗੇਟਵੇ ਦੇ ਪਤੇ ਵਜੋਂ ਦਿਸਣ ਲੱਗਦੇ ਹਨ, ਸਰੋਤ-ਆਧਾਰਿਤ ACL ਉਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਪਛਾਣਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਜਵਾਬ ਨੂੰ ਸੁਰੰਗ ਵਿੱਚ ਵਾਪਸ ਲਿਖਣ ਲਈ conntrack ਨੂੰ ਮੈਪਿੰਗ ਰੱਖਣੀ ਪੈਂਦੀ ਹੈ। ਜੇ ਸਿਲੈਕਟਰ ਹਾਲੇ ਵੀ ਕਲਾਇੰਟ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਬਾਹਰ ਰੱਖਦੇ ਹਨ, ਤਾਂ NAT ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਕਿਉਂਕਿ ਬੇਨਤੀ ਕਦੇ ਸੁਰੰਗ ਵਿੱਚ ਦਾਖਲ ਨਹੀਂ ਹੋਈ।
ਇਸਨੂੰ ਠੀਕ ਕਿਹਾ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਚੀਜ਼ਾਂ ਕ੍ਰਮ ਨਾਲ ਪੱਕੀਆਂ ਕਰੋ: ਜਵਾਬ ਭੇਜਣ ਵਾਲੇ ਹੋਸਟ ਉੱਤੇ ਰੂਟ, ਉਸਨੂੰ ਫਾਰਵਰਡ ਕਰਨ ਵਾਲੇ ਹਰ ਹੌਪ ਉੱਤੇ ਰੂਟ, ਦੋਵੇਂ ਪ੍ਰੀਫਿਕਸ ਢਕਣ ਵਾਲੇ ਸਿਲੈਕਟਰ, ਅਤੇ ਅਜਿਹੀ ਕੈਪਚਰ ਜੋ ਦਿਖਾਵੇ ਕਿ ਜਵਾਬ ਤੁਹਾਡੀ ਉਮੀਦ ਵਾਲੇ ਸਰੋਤ ਨਾਲ ਸੁਰੰਗ ਵਿੱਚ ਦਾਖਲ ਹੋ ਰਿਹਾ ਹੈ। ਫਿਰ ਦੂਜੀ ਸਾਈਟ ਤੋਂ ਟੈਸਟ ਦੁਹਰਾਓ। ਇੱਕ ਦਿਸ਼ਾ ਦਾ ਪਾਸ ਹੋਣਾ ਅੱਧ-ਖੁੱਲ੍ਹਾ ਡਿਜ਼ਾਈਨ ਹੈ, ਅਤੇ ਦੂਜੀ ਦਿਸ਼ਾ ਆਮ ਤੌਰ ਉੱਤੇ ਉਸ ਨਾਲੋਂ ਵੱਖਰੇ ਕਾਰਨ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਹੁਣੇ ਠੀਕ ਕੀਤਾ।