ਤੁਹਾਡਾ LAN VPN ਕਲਾਇੰਟ ਦੀ ਸੇਵਾ ਤੱਕ ਕਿਉਂ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ

ਤੁਹਾਡੀ ਟਨਲ ਚਾਲੂ ਹੈ, ਸੇਵਾ ਸੁਣ ਰਹੀ ਹੈ, ਅਤੇ ਦਫ਼ਤਰ ਦਾ LAN ਅਜੇ ਵੀ ਕੁਝ ਵਾਪਸ ਨਹੀਂ ਪਾ ਰਿਹਾ। ਕਿਸੇ ਨੇ VPN ਨਹੀਂ ਤੋੜਿਆ। LAN ਦੇ ਪਾਸਿਓਂ, ਲੈਪਟਾਪ ਦਾ ਟਨਲ ਪਤਾ ਤਦ ਤੱਕ ਮੌਜੂਦ ਨਹੀਂ ਹੁੰਦਾ ਜਦ ਤੱਕ ਕੋਈ LAN ਨੂੰ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਉੱਥੇ ਕਿਵੇਂ ਪਹੁੰਚਣਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਉਸੇ ਰਾਹ ਤੋਂ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਰਾਹੋਂ ਬੇਨਤੀ ਬਾਹਰ ਗਈ ਸੀ। ਮੈਂ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੰਦਰੁਸਤ ਟਨਲ ਤਿੰਨ ਵਾਰ ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਦੇਖਿਆ ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕਿਸੇ ਨੇ ਵਾਪਸੀ ਦੇ ਰਾਹ ਵੱਲ ਦੇਖਿਆ ਹੋਵੇ।

ਟੁੱਟੀ ਟਨਲ ਨਹੀਂ

ਦੋਵੇਂ ਸਿਰੇ ਨਿੱਜੀ ਰੇਂਜਾਂ ਉੱਤੇ ਬੈਠੇ ਹਨ, ਇਹ ਆਮ ਸਥਿਤੀ ਹੈ ਅਤੇ ਗ਼ਲਤ ਸੰਰਚਨਾ ਨਹੀਂ। 10.8.0.6 ਵਰਗਾ ਪਤਾ ਟਨਲ ਦੇ ਅੰਦਰ ਅਸਲੀ ਹੈ ਅਤੇ ਹੋਰ ਕਿਤੇ ਨਹੀਂ, ਇਸ ਲਈ LAN ਕੋਲ ਉੱਥੇ ਕੁਝ ਭੇਜਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ। ਰੂਟਿੰਗ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੇਵਾ ਟਨਲ ਦੇ ਅੰਦਰ ਪਹੁੰਚਯੋਗ ਹੈ ਵੀ ਜਾਂ ਨਹੀਂ: ਕਲਾਇੰਟ ਉੱਤੇ ss -ltn ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸਰੋਤਾ 127.0.0.1, LAN ਇੰਟਰਫ਼ੇਸ ਜਾਂ ਟਨਲ ਪਤੇ ਨਾਲ ਬੱਝਾ ਹੈ। ਸਿਰਫ਼ loopback ਨਾਲ ਬੱਝਾ ਡੈਮਨ ਆਪਣੇ ਤੋਂ ਬਿਨਾਂ ਕਿਸੇ ਨੂੰ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ, ਅਤੇ ਕੋਈ ਰੂਟ, DNAT ਜਾਂ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਇਸ ਨੂੰ ਨਹੀਂ ਬਦਲਦੀ।

ਪੋਰਟ 80 ਜਾਂ 443 ਉੱਤੇ ਪਰਾਕਸੀ ਵੱਖਰੀ ਦਿੱਖ ਵਾਲਾ ਵੱਖਰਾ ਸਾਧਨ ਹੈ। ਇਹ ਬੇਨਤੀਆਂ ਭੇਜਦੀ ਹੈ, ਪੈਕਟ ਨਹੀਂ, ਇਸ ਲਈ ਕੱਚੇ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਲਈ ਇਹ ਗ਼ਲਤ ਪਰਤ ਹੈ, ਅਤੇ ਇਸ ਵੱਲ ਹੱਥ ਵਧਾਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਇਹ ਸਮੱਸਿਆ ਕਿਸੇ ਦੇ ਕੁਝ ਮਾਪਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਸਾਧਨ ਡੂੰਘੀ ਹੋ ਜਾਂਦੀ ਹੈ।

ਰੂਟ ਦਾ ਆਕਾਰ: LAN ਨੂੰ ਦੱਸੋ ਕਿ ਤਾਲਾਬ ਕਿੱਥੇ ਹੈ

LAN ਗੇਟਵੇ ਉੱਤੇ ਸਥਿਰ ਰੂਟ ਸਭ ਤੋਂ ਸਾਫ਼ ਜਵਾਬ ਹੈ ਜਦੋਂ LAN ਅਤੇ ਟਨਲ ਤਾਲਾਬ ਇੱਕ ਦੂਜੇ ਉੱਤੇ ਨਹੀਂ ਆਉਂਦੇ। ਤਾਲਾਬ ਨੂੰ ਉਸ ਮਸ਼ੀਨ ਵੱਲ ਮੋੜੋ ਜੋ ਟਨਲ ਖ਼ਤਮ ਕਰਦੀ ਹੈ:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

ਇਹ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਠੀਕ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਬਦਲਾਅ ਦੇ ਅੱਧੇ-ਪੂਰੇ ਸੰਸਕਰਣ ਤਰੱਕੀ ਵਰਗੇ ਲੱਗਦੇ ਹਨ। ਟਨਲ ਦੇ ਪਾਸੇ ਨੂੰ ਵੀ ਮਿਲਦਾ ਅੱਧਾ ਹਿੱਸਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਜਵਾਬ ਕਲਾਇੰਟ ਨੂੰ ਉਸ ਦੇ ਆਪਣੇ ਡਿਫ਼ਾਲਟ ਰੂਟ ਰਾਹੀਂ ਛੱਡ ਦਿੰਦਾ ਹੈ ਅਤੇ ਰਾਹ ਵਿੱਚ ਮਰ ਜਾਂਦਾ ਹੈ:

push "route 192.168.1.0 255.255.255.0"

ਸਰਵਰ ਦੇ ਪਿੱਛੇ ਨਹੀਂ, ਇੱਕ ਕਲਾਇੰਟ ਦੇ ਪਿੱਛੇ ਵਾਲੇ ਸਬਨੈੱਟ ਲਈ ਸਰਵਰ ਨੂੰ ਸਿਸਟਮ ਰੂਟ ਅਤੇ ਉਸ ਕਲਾਇੰਟ ਦੀ ਫ਼ਾਈਲ ਵਿੱਚ iroute ਐਂਟਰੀ ਦੋਵੇਂ ਚਾਹੀਦੇ ਹਨ, ਜੋ client-config-dir ਅਧੀਨ ਹੁੰਦੀ ਹੈ। iroute ਤੋਂ ਬਿਨਾਂ, OpenVPN ਨੂੰ ਪਤਾ ਹੈ ਕਿ ਪ੍ਰੀਫ਼ਿਕਸ ਮੌਜੂਦ ਹੈ ਅਤੇ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ ਕਿਹੜਾ ਕਲਾਇੰਟ ਇਸ ਦਾ ਮਾਲਕ ਹੈ: ਪੈਕਟ ਆਉਂਦੇ ਹਨ ਅਤੇ ਡੈਮਨ ਕੋਲ ਉਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣ ਲਈ ਕੁਝ ਨਹੀਂ।

ਇੱਥੇ ਉਹ ਮਿੱਥ ਹੈ ਜਿਸ ਨੂੰ ਨਾਮ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਰੂਟ ਪਤੇ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦਾ ਹੈ; ਇਹ ਸਾਹਮਣੇ ਵਾਲੇ ਪਾਸੇ ਨੂੰ ਜਵਾਬ ਦੇਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕਰਦਾ। ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਸਾਥੀ ਉੱਤੇ ਇੱਕ ਹੋਰ ਪਰਤ ਜੋੜਦੇ ਹਨ, ਕਿਉਂਕਿ ਦੂਰ ਦਾ ਗੇਟਵੇ ਸਿਰਫ਼ ਆਪਣੀ ਨੀਤੀ ਵਿੱਚ ਦਰਜ ਪ੍ਰੀਫ਼ਿਕਸਾਂ ਦੇ ਅੰਦਰਲੇ ਸਰੋਤ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਘਰ ਦੇ ਤਾਲਾਬ ਤੋਂ ਆਉਣ ਵਾਲਾ ਲੈਪਟਾਪ ਉਨ੍ਹਾਂ ਦੇ ਅੰਦਰ ਨਹੀਂ ਹੁੰਦਾ।

NAT ਦਾ ਆਕਾਰ: ਅੰਦਰ DNAT, ਅਤੇ ਉਹ SNAT ਲਾਈਨ ਜੋ ਸਾਰੇ ਛੱਡ ਦਿੰਦੇ ਹਨ

ਜਦੋਂ ਤੁਸੀਂ LAN ਗੇਟਵੇ ਨੂੰ ਛੂਹ ਨਹੀਂ ਸਕਦੇ, ਜਾਂ ਬਿਲਕੁਲ ਇੱਕ ਪੋਰਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, VPN ਹੋਸਟ ਉੱਤੇ ਅਨੁਵਾਦ LAN ਉੱਤੇ ਕਿਸੇ ਵੀ ਰੂਟ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਪੋਰਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, ਫਾਰਵਰਡ ਕਰੋ, ਅਤੇ ਟਨਲ ਵੱਲ ਜਾਂਦੇ ਰਾਹ ਵਿੱਚ ਸਰੋਤ ਦਾ ਅਨੁਵਾਦ ਕਰੋ:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

ਤੀਜੀ ਲਾਈਨ ਹੀ ਉਹ ਹੈ ਜੋ ਗੁੰਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਸ ਨੂੰ ਛੱਡ ਦਿਓ ਅਤੇ ਕਲਾਇੰਟ ਮੂਲ LAN ਪਤੇ ਨੂੰ ਸਰੋਤ ਵਜੋਂ ਦੇਖਦਾ ਹੈ, ਆਪਣੇ ਡਿਫ਼ਾਲਟ ਰੂਟ ਰਾਹੀਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਜਵਾਬ LAN ਵੱਲ ਵਾਪਸ ਜਾਣ ਦੀ ਬਜਾਏ ਟਨਲ ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ। ਕਨੈਕਸ਼ਨ ਬਚੇਗਾ ਜਾਂ ਨਹੀਂ ਇਹ ਫਿਰ ਉਸ ਰੂਟਿੰਗ ਉੱਤੇ ਨਿਰਭਰ ਹੈ ਜਿਸ ਦੀ ਤੁਸੀਂ ਕਦੇ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਈ। SNAT ਨਾਲ ਕਲਾਇੰਟ ਸਰਵਰ ਦਾ ਟਨਲ ਪਤਾ ਦੇਖਦਾ ਹੈ, ਇਸ ਲਈ ਜਵਾਬ ਟਨਲ ਰਾਹੀਂ ਵਾਪਸ ਉਸ ਇੱਕੋ ਹੋਸਟ ਤੱਕ ਜਾਂਦਾ ਹੈ ਜੋ ਅਨੁਵਾਦ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ।

ਖਪਤਕਾਰ ਫ਼ਰਮਵੇਅਰ ਆਪਣੇ ਚੇਨ ਨਾਮ ਵਰਤਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਲਈ ਉਹ ਅਨੁਵਾਦ ਨਹੀਂ ਬਣਾਉਂਦਾ। Tomato ਉੱਤੇ, ਇਨਬਾਊਂਡ ਨਿਯਮ WANPREROUTING ਵਿੱਚ ਡਿੱਗਦਾ ਹੈ ਅਤੇ ਫਿਰ wanin ਵਰਗੀ ਫ਼ਿਲਟਰ ਚੇਨ ਵਿੱਚ, ਅਤੇ ਪੂਰਾ ਦਿਸਦਾ ਨਿਯਮ ਸੈੱਟ ਵੀ ਅਜੇ ਹੱਥ ਨਾਲ ਲਿਖੀ POSTROUTING ਲਾਈਨ ਮੰਗਦਾ ਹੈ। ਇਹ ਫ਼ਰਮਵੇਅਰ ਬੱਗ ਨਹੀਂ; ਇਹ ਸਿਰਫ਼ ਇਨਬਾਊਂਡ ਟ੍ਰੈਫ਼ਿਕ ਲਈ ਲਿਖਿਆ ਨਿਯਮ ਸੈੱਟ ਹੈ।

ਸਹੀ ਦਿਸਦਾ ਨਿਯਮ ਵੀ ਪੈਕਟ ਕਿਉਂ ਡੇਗਦਾ ਹੈ

ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤੀਆਂ ਅਸਫ਼ਲਤਾਵਾਂ ਉਸ ਨਿਯਮ ਵਿੱਚ ਨਹੀਂ ਜਿਸ ਵੱਲ ਤੁਸੀਂ ਤੱਕ ਰਹੇ ਹੋ। ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਚਾਰ ਚੀਜ਼ਾਂ ਜਾਂਚੋ, ਅਤੇ ਜੋ ਪਹਿਲੀ ਸੱਚ ਨਾ ਹੋਵੇ ਉੱਥੇ ਰੁਕੋ:

• ਚੇਨ ਕ੍ਰਮ। iptables -I ਉੱਤੇ ਪਾਉਂਦਾ ਹੈ ਅਤੇ -A ਅੰਤ ਵਿੱਚ ਜੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਪਹਿਲਾਂ ਵਾਲਾ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਜਾਂ ਰੋਕਣ ਵਾਲਾ ਨਿਯਮ ਪਹਿਲਾਂ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ।
• ਗ਼ਲਤ ਚੇਨ। ਰਾਊਟਰ ਨੂੰ ਹੀ ਸੰਬੋਧਿਤ ਟ੍ਰੈਫ਼ਿਕ INPUT ਰਾਹੀਂ ਲੰਘਦਾ ਹੈ, ਅਤੇ ਫਾਰਵਰਡ ਕੀਤਾ ਟ੍ਰੈਫ਼ਿਕ ਇਸ ਨੂੰ ਕਦੇ ਨਹੀਂ ਛੂਹਦਾ। ਇੱਕ ਸੇਵਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ ਦੋਵਾਂ ਵਿੱਚ ਨਿਯਮ ਲੱਗ ਸਕਦੇ ਹਨ।
• ਦਿਸ਼ਾ ਫ਼ਲੈਗ। -i tun0 ਕਲਾਇੰਟਾਂ ਤੋਂ ਆਉਣ ਵਾਲੇ ਟ੍ਰੈਫ਼ਿਕ ਨਾਲ ਮਿਲਦਾ ਹੈ ਅਤੇ -o tun0 ਉਨ੍ਹਾਂ ਵੱਲ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫ਼ਿਕ ਨਾਲ। ਗ਼ਲਤ ਫ਼ਲੈਗ ਵਾਲਾ REJECT ਉਹ ਰੋਕ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਸੀ।
• ਸਰੋਤ ਸੀਮਾ। ਇੱਕ ਕਲਾਇੰਟ ਪਤਾ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਫਾਰਵਰਡਿੰਗ ਉਸ ਕਲਾਇੰਟ ਤੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਹਰ ਹੋਰ ਸਰੋਤ ਨੂੰ ਇੱਕ ਸ਼ਬਦ ਵੀ ਨਾ ਬੋਲ ਕੇ ਡੇਗ ਦਿੰਦਾ ਹੈ।

ਸਿਫ਼ਰ ਪੈਕਟ ਕਾਊਂਟਰ ਵਾਲਾ ਨਿਯਮ ਰਾਹ ਵਿੱਚ ਹੀ ਨਹੀਂ, ਅਤੇ ਕਾਊਂਟਰ ਪੜ੍ਹਨਾ ਗ਼ਲਤ-ਚੇਨ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਗ਼ਲਤ-ਨਿਯਮ ਦੀ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ।

ਸਥਾਨਕ ਫਾਰਵਰਡਿੰਗ, ਜਦੋਂ LAN ਉੱਤੇ ਕੁਝ ਵੀ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ

SSH ਸਥਾਨਕ ਫਾਰਵਰਡਿੰਗ ਪੂਰੇ ਸਵਾਲ ਨੂੰ ਬਚਾ ਲੈਂਦੀ ਹੈ। ਇਸ ਨੂੰ LAN ਉੱਤੇ ਰੂਟ, ਕਲਾਇੰਟ ਦੇ ਫ਼ਾਇਰਵਾਲ ਦੇ ਸਹਿਯੋਗ, ਅਤੇ ਕਿਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ ਦੀ ਲੋੜ ਨਹੀਂ:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

ਫਿਰ ਸੇਵਾ ਟਨਲ ਚਲਾਉਣ ਵਾਲੀ ਮਸ਼ੀਨ ਦੇ localhost:3000 ਉੱਤੇ ਦਿਸਦੀ ਹੈ, ਅਤੇ ਹੋਰ ਕਿਤੇ ਨਹੀਂ। ਇਹੀ ਹੱਦ ਹੈ: ਇੱਕ ਵਰਕਸਟੇਸ਼ਨ, ਇੱਕ ਪੋਰਟ, ਅਤੇ ਕੋਈ ਚੀਜ਼ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਨਾ ਕਰੇ ਤਾਂ ਫਾਰਵਰਡਿੰਗ ਸੈਸ਼ਨ ਨਾਲ ਹੀ ਮਰ ਜਾਂਦੀ ਹੈ। ਸਟੇਜਿੰਗ ਡੇਟਾਬੇਸ ਜਾਂਚਦੇ ਐਡਮਿਨ ਲਈ ਇਹ ਸਹੀ ਸਾਧਨ ਹੈ। ਜਿਨ੍ਹਾਂ ਕੈਮਰੇ ਜਾਂ ਸਕੈਨਰ ਤੱਕ ਹੋਰ ਲੋਕਾਂ ਨੂੰ ਪਹੁੰਚਣਾ ਹੈ, ਉਨ੍ਹਾਂ ਲਈ ਨਹੀਂ, ਕਿਉਂਕਿ ਹਰ ਵਰਤੋਂਕਾਰ ਨੂੰ ਆਪਣੀ ਫਾਰਵਰਡਿੰਗ ਚਾਹੀਦੀ ਹੋਵੇਗੀ।

ਹੋਰ ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਜਾਂਚੋ

ਅਨੁਵਾਦ ਨਿਸ਼ਾਨ ਛੱਡਦਾ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਤੋਂ ਬਿਹਤਰ ਹੈ। VPN ਹੋਸਟ ਉੱਤੇ, conntrack -L ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅਨੁਵਾਦ ਹੋਇਆ ਵੀ ਜਾਂ ਨਹੀਂ, iptables -t nat -L -n -v ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਾਊਂਟਰ ਹਿੱਲੇ ਜਾਂ ਨਹੀਂ, ਅਤੇ tcpdump -ni any port 3000 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਸਰੋਤ ਪਤਾ ਸੱਚਮੁੱਚ ਆਇਆ। ਕਲਾਇੰਟ ਉੱਤੇ, ss -ltn ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਸਰੋਤਾ ਉਸ ਪਤੇ ਉੱਤੇ ਹੈ ਜਿੱਥੇ ਟਨਲ ਪਹੁੰਚ ਸਕਦੀ ਹੈ।

ਫਿਰ ਤੁਸੀਂ ਰੱਖਣ ਵਾਲਾ ਆਕਾਰ ਚੁਣੋ। ਇੱਕ ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ, ਪੂਰੇ ਤਾਲਾਬ ਲਈ ਇੱਕ ਰੂਟ, ਅਤੇ ਇੱਕ ਐਡਮਿਨ ਲਈ ਇੱਕ ਫਾਰਵਰਡਿੰਗ — ਇਹ ਤਿੰਨ ਵੱਖਰੇ ਵਾਅਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਕੰਮ ਕਰਦੀ ਸੈਟਿੰਗ ਨੂੰ ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਕੋਈ ਸਮਝਾ ਨਾ ਸਕੇ ਅਜਿਹੀ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਹੈ। ਲਿਖੋ ਕਿ ਕਿਹੜਾ ਪਤਾ ਕਿੱਥੋਂ ਪਹੁੰਚਯੋਗ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵਾਲਾ ਅਗਲਾ ਵਿਅਕਤੀ ਟਨਲ ਦੀ ਬਜਾਏ ਜਵਾਬ ਤੋਂ ਸ਼ੁਰੂ ਕਰੇਗਾ।