ਕੇਵਲ Docker ਕੰਟੇਨਰਾਂ ਦੀ ਟ੍ਰੈਫਿਕ OpenVPN ਰਾਹੀਂ ਕਿਵੇਂ ਰੂਟ ਕਰੀਏ

ਹੋਸਟ ਨੂੰ ਇਸ ਦੇ ਆਮ ਅਪਲਿੰਕ 'ਤੇ ਰੱਖੋ ਅਤੇ ਇੱਕ ਕੰਟੇਨਰ ਸਬਨੈੱਟ ਟਨਲ ਵਿੱਚ ਪਾਓ: NAT ਕ੍ਰਮ, ਸਰੋਤ ਨਿਯਮ, OpenVPN iroute ਅਤੇ MSS ਜਾਂਚਾਂ।

ਕੰਟੇਨਰ ਦਾ ਪੈਕਟ ਕਦੇ ਵੀ tun0 ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਅਤੇ ਕੰਟੇਨਰ ਉੱਤੇ ਵਾਧੂ ਸਮਰੱਥਾਵਾਂ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲਣਗੀਆਂ। ਮਹਿਮਾਨ ਅਤੇ ਟਨਲ ਵਿਚਕਾਰ ਦੋ ਰੂਟ ਖੋਜਾਂ ਹਨ: ਇੱਕ ਮਹਿਮਾਨ ਦੇ ਨੈੱਟਵਰਕ ਨਾਮਸਥਾਨ ਦੇ ਅੰਦਰ, ਇੱਕ ਫਰੇਮ ਬ੍ਰਿਜ ਉੱਤੇ ਉਤਰਨ ਤੋਂ ਬਾਅਦ ਹੋਸਟ ਉੱਤੇ, ਅਤੇ ਦੂਜਾ ਵੱਖਰੇ ਮਿਲਾਣ ਨਿਯਮਾਂ ਵਾਲੀ ਵੱਖਰੀ ਸਾਰਣੀ ਨੂੰ ਪੁੱਛਦਾ ਹੈ। ਮੇਰਾ ਹਵਾਲਾ ਲੇਆਉਟ ਇੱਕ Linux ਹੋਸਟ ਹੈ ਜਿਸ ਉੱਤੇ OpenVPN ਕਲਾਇੰਟ ਚੱਲਦਾ ਹੈ, ਜੋ 10.8.0.10 ਨੂੰ tun0 ਉੱਤੇ ਰੱਖਦਾ ਹੈ, 172.18.0.0/16 ਉੱਤੇ Docker ਬ੍ਰਿਜ, ਅਤੇ ਇੱਕ ਨਿੱਜੀ ਪਤਾ ਜਿਸ ਤੱਕ ਸਿਰਫ਼ ਟਨਲ ਵਾਲਾ ਪਾਸਾ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਟੀਚਾ ਤੰਗ ਹੀ ਰਹਿੰਦਾ ਹੈ: ਉਹ ਮਹਿਮਾਨ ਸਬਨੈੱਟ ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ, ਹੋਸਟ ਆਪਣਾ ਆਮ ਅਪਲਿੰਕ ਰੱਖਦਾ ਹੈ।

VPN ਕਲਾਇੰਟ ਨੂੰ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਚਲਾਉਣਾ ਦੂਜਾ ਡਿਜ਼ਾਈਨ ਹੈ, ਸ਼ਾਰਟਕੱਟ ਨਹੀਂ। ਫਿਰ ਕੰਟੇਨਰ ਆਪਣਾ ਟਨਲ ਅਤੇ ਆਪਣੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਕੰਮ iptables ਵਿੱਚ ਰਹਿਣ ਦੀ ਥਾਂ Dockerfile ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ।

ਫਾਰਵਰਡਿੰਗ ਮੰਜ਼ਿਲ ਮੁਤਾਬਕ ਰੂਟ ਚੁਣਦੀ ਹੈ, ਫਿਰ NAT ਸਰੋਤ ਮੁੜ ਲਿਖਦਾ ਹੈ

ਜਦੋਂ net.ipv4.ip_forward=1 ਸੈੱਟ ਹੁੰਦਾ ਹੈ, ਫਾਰਵਰਡ ਕੀਤਾ ਪੈਕਟ ਮੁੱਖ ਸਾਰਣੀ ਵਿੱਚ ਸਿਰਫ਼ ਮੰਜ਼ਿਲ ਮੁਤਾਬਕ ਰੂਟ ਹੁੰਦਾ ਹੈ। ਉਸ ਫੈਸਲੇ ਵਿੱਚ ਸਰੋਤ ਦਾ ਕੋਈ ਹਿੱਸਾ ਨਹੀਂ। ਰੂਟ ਚੁਣੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਹੀ ਕਰਨਲ POSTROUTING ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਉੱਥੇ ਹੀ Docker ਦਾ ਆਪਣਾ ਨਿਯਮ ਬੈਠਦਾ ਹੈ: -s 172.18.0.0/16 ! -o br-appnet -j MASQUERADE। ਬ੍ਰਿਜ ਛੱਡ ਕੇ ਦੂਜੇ ਇੰਟਰਫੇਸ ਵੱਲ ਜਾਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਦਾ ਅਨੁਵਾਦ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਿਹੜਾ ਪਤਾ ਬਣਦੀ ਹੈ ਇਹ ਉਸ ਇੰਟਰਫੇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜਿਸ ਵੱਲ ਰੂਟ ਨੇ ਇਸਨੂੰ ਭੇਜਿਆ।

ਇਹ ਨਿਯਮ ਮੈਨੂੰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਬਹੁਤੇ ਲੱਛਣ ਸਮਝਾਉਂਦਾ ਹੈ। ਜੇ ਮੁੱਖ ਸਾਰਣੀ ਵਿੱਚ ਨਿੱਜੀ ਮੰਜ਼ਿਲ ਲਈ ਰੂਟ ਨਹੀਂ ਹੈ, ਪੈਕਟ ਹੋਸਟ ਦੇ ਭੌਤਿਕ ਪਤੇ ਨਾਲ ਅਪਲਿੰਕ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਡਾ ਪ੍ਰਦਾਤਾ ਮੰਜ਼ਿਲ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਦੂਰ ਦੀ ਸਾਈਟ ਉਹ RFC 1918 ਸਰੋਤ ਛੱਡ ਦਿੰਦੀ ਹੈ ਜਿਸਦੀ ਉਸਨੂੰ ਕਦੇ ਉਮੀਦ ਨਹੀਂ ਸੀ, ਅਤੇ ਟਨਲ ਚੱਲਦਾ ਅਤੇ ਸਿਹਤਮੰਦ ਰਹਿੰਦਿਆਂ ਕੰਟੇਨਰ ਦਾ ਸਮਾਂ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। tun0 ਉੱਤੇ ਕੈਪਚਰ ਕੁਝ ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਅਤੇ ਇਹੀ ਸੰਕੇਤ ਹੈ। ਜੇ ਰੂਟ ਸੱਚਮੁੱਚ tun0 ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, MASQUERADE ਸਰੋਤ ਨੂੰ 10.8.0.10 ਉੱਤੇ ਮੁੜ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਕੰਟੇਨਰ ਤੁਸੀਂ ਕੁਝ ਛੂਹੇ ਬਿਨਾਂ ਚੱਲਦਾ ਹੈ।

ਉਹ ਖੋਜ ਮੰਗੋ ਜੋ ਮਹਿਮਾਨ ਦੇ ਸਰੋਤ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ। from ਅਤੇ iif ਤੋਂ ਬਿਨਾਂ ਹੋਸਟ ਆਪਣੇ ਹੀ ਸਾਕਟ ਲਈ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਹ ਰਾਹ ਦੱਸਦਾ ਹੈ ਜਿਸ 'ਤੇ ਫਾਰਵਰਡ ਕੀਤਾ ਪੈਕਟ ਕਦੇ ਨਹੀਂ ਜਾਵੇਗਾ:

ip route get 192.168.11.222 from 172.18.0.5 iif br-appnet

ਜੇ ਉਹ ਜਵਾਬ ਅਪਲਿੰਕ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਟਨਲ ਤਸਵੀਰ ਵਿੱਚ ਨਹੀਂ ਹੈ ਅਤੇ ਟਨਲ ਪਾਸੇ ਦੀ ਕੋਈ ਸੈਟਿੰਗ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ।

ਮਹਿਮਾਨ ਨੂੰ ਟਨਲ ਦੇ ਆਪਣੇ ਪਤੇ 'ਤੇ ਲਿਆਓ

ਸਭ ਤੋਂ ਛੋਟਾ ਕੰਮ ਕਰਨ ਵਾਲਾ ਬਦਲਾਅ ਬਾਹਰ ਜਾਂਦਿਆਂ ਸਪਸ਼ਟ ਸਰੋਤ ਮੁੜਲਿਖਣਾ ਹੈ। ਇਸਨੂੰ ਜੋੜਨ ਦੀ ਥਾਂ ਵਿੱਚ ਪਾਓ: Docker ਪਹਿਲਾਂ ਹੀ POSTROUTING ਦੇ ਸਿਰੇ 'ਤੇ ਬੈਠਾ ਹੈ, ਇਸ ਲਈ -A ਨਾਲ ਜੋੜਿਆ ਨਿਯਮ Docker ਦੇ ਨਿਯਮ ਤੋਂ ਬਾਅਦ ਮੁੱਲਾਂਕਣ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਦੇ ਨਹੀਂ ਚੱਲਦਾ।

iptables -t nat -I POSTROUTING 1 -s 172.18.0.0/16 -o tun0 -j SNAT --to-source 10.8.0.10

ਇਹ ਟਿਕੇਗਾ ਜਾਂ ਨਹੀਂ, ਦੋ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ। ਪਤਾ ਉਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਕੋਲ ਸੱਚਮੁੱਚ ਹੈ, ਇਸ ਲਈ ਹਰ ਕਲਾਇੰਟ ਲਈ ifconfig-push 10.8.0.10 255.255.255.0 ਵਾਲੀ ਐਂਟਰੀ ਨਾਲ ਇਸਨੂੰ ਪਿੰਨ ਕਰੋ; ਜੋ ਨਿਯਮ ਕਦੇ ਨਾ ਦਿੱਤੇ ਪਤੇ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਉਹ ਤਰੁੱਟੀ ਨਹੀਂ, ਖ਼ਾਮੋਸ਼ ਡ੍ਰੌਪ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਅਤੇ ਦੂਰ ਦੇ ਪਾਸੇ ਨੂੰ ਉਹ ਸਰੋਤ ਸਵੀਕਾਰ ਕਰਕੇ ਜਵਾਬ ਵਾਪਸ ਰੂਟ ਕਰਨੇ ਪੈਣਗੇ, ਇਸ ਲਈ ਉੱਥੋਂ ਦੀ ਇਜਾਜ਼ਤ ਸੂਚੀ ਮਹਿਮਾਨ ਸਬਨੈੱਟ ਨਹੀਂ, ਟਨਲ ਪਤੇ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ। ਜਦੋਂ ਕਲਾਇੰਟ ਪਤਾ ਗਤੀਸ਼ੀਲ ਹੋਵੇ, -j MASQUERADE ਨਾਲ -o tun0 ਇੰਟਰਫੇਸ ਕੋਲ ਜੋ ਹੈ ਉਸ ਦੀ ਪੈਰਵੀ ਕਰਦਾ ਹੈ, ਪਰ ਸਥਿਰ ਮੁੱਲ ਵਿਰੁੱਧ ਲਿਖ ਨਾ ਸਕਣ ਵਾਲੀ ਦੂਰ ਦੀ ਨੀਤੀ ਦੀ ਕੀਮਤ 'ਤੇ।

ਫਿਲਟਰਿੰਗ ਦੂਜਾ ਅੱਧਾ ਹੈ। Docker FORWARD ਨੀਤੀ ਨੂੰ drop 'ਤੇ ਰੱਖਦਾ ਹੈ ਅਤੇ ਹਰ ਡੈਮਨ ਰੀਸਟਾਰਟ 'ਤੇ ਆਪਣੀਆਂ ਚੇਨਾਂ ਖਾਲੀ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸਥਾਨਕ ਨੀਤੀ DOCKER-USER ਵਿੱਚ ਰੱਖੋ, ਜੋ ਟਿਕਦੀ ਹੈ:

iptables -I DOCKER-USER -i br-appnet -o tun0 -j ACCEPT
iptables -I DOCKER-USER -i tun0 -o br-appnet -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ਵਾਪਸੀ ਦਾ ਨਿਯਮ ਮਹੱਤਵਪੂਰਨ ਹੈ: tun0 ਉੱਤੇ ਆਉਣ ਵਾਲਾ ਜਵਾਬ ਬ੍ਰਿਜ ਰਾਹੀਂ ਖੋਲ੍ਹੇ ਕਨੈਕਸ਼ਨ ਲਈ ਸਿਰਫ਼ ਇਸ ਲਈ ਸਵੀਕਾਰ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਦਿਸ਼ਾ ਸਵੀਕਾਰ ਹੋਈ ਸੀ।

ਸਰੋਤ ਨਿਯਮ ਨਾਲ ਹੋਸਟ ਨੂੰ ਸਿੱਧਾ ਰੱਖੋ

ਜਦੋਂ ਪੂਰਾ ਬ੍ਰਿਜ ਟਨਲ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ ਪਰ ਹੋਸਟ 'ਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ, ਤਾਂ NAT ਛੱਡੋ ਅਤੇ ਉਸ ਸਰੋਤ ਨੂੰ ਆਪਣੀ ਸਾਰਣੀ ਦਿਓ। ਮਹਿਮਾਨ ਪਤੇ ਫਿਰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਦਿਸਦੇ ਰਹਿੰਦੇ ਹਨ।

echo "200 vpnbox" >> /etc/iproute2/rt_tables
ip rule add from 172.18.0.0/16 lookup vpnbox pref 1000
ip route add default dev tun0 table vpnbox

ਨਿਯਮ ਮੁੱਖ ਸਾਰਣੀ ਤੋਂ ਪਹਿਲਾਂ ਵੇਖੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ from ਸਰੋਤ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਟਨਲ ਦੇ ਆਪਣੇ ਬਾਹਰੀ ਪੈਕਟ ਹੋਸਟ ਦਾ ਭੌਤਿਕ ਸਰੋਤ ਢੋਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਕਦੇ ਵੀ from 172.18.0.0/16 ਨਾਲ ਨਹੀਂ ਮਿਲਦੇ ਅਤੇ ਟਨਲ ਆਪਣੇ ਆਪ ਨੂੰ ਵਾਪਸ ਅੰਦਰ ਰੂਟ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਹ ਸਵੈ-ਬਾਹਰ ਕੱਢਣਾ ਹੀ ਲੇਆਉਟ ਨੂੰ ਸਥਿਰ ਬਣਾਉਂਦਾ ਹੈ।

ਵਾਪਸੀ ਦੇ ਰਾਹ ਨੂੰ ਹੁਣ ਮਦਦ ਚਾਹੀਦੀ ਹੈ। ਦੂਰ ਦਾ ਪਾਸਾ ਅਨੁਵਾਦ ਨਾ ਕੀਤਾ 172.18.0.x ਵੇਖਦਾ ਹੈ ਅਤੇ ਉਹ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ ਇਹ ਜਾਣਨ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ। ਸਰਵਰ 'ਤੇ ਹਰ ਕਲਾਇੰਟ ਲਈ ਫਾਈਲ ਨੂੰ iroute 172.18.0.0 255.255.0.0 ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਸਰਵਰ ਦੀ ਅੰਦਰੂਨੀ ਸਾਰਣੀ ਉਹ ਪ੍ਰੀਫਿਕਸ ਇਸ ਕਲਾਇੰਟ ਨੂੰ ਦੇਵੇ, ਅਤੇ ਧੱਕਿਆ route 172.18.0.0 255.255.0.0 ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਹੋਰ ਕਲਾਇੰਟ ਜਾਣਨ ਕਿ ਇਹ ਮੌਜੂਦ ਹੈ।

ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਜਾਂਚਾਂ। ਚਲਾਓ ip route show default : redirect-gateway def1 ਨਾਲ ਸਾਰਣੀ ਵਿੱਚ 0.0.0.0/1 ਅਤੇ 128.0.0.0/1 ਹਨ tun0 ਰਾਹੀਂ, ਅਤੇ ਹੋਸਟ ਬਿਲਕੁਲ ਵੀ ਸਿੱਧਾ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਅੱਧ-ਡਿਫਾਲਟ default ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਜਿੱਤ ਜਾਂਦੇ ਹਨ। ip rule add ਨਾਲ ਜੋੜੇ ਨਿਯਮ ਵੀ ਰੀਬੂਟ 'ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ up ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਰੱਖੋ।

ਪੈਕਟ ਦਾ ਆਕਾਰ ਦੂਜੀ ਅਸਫਲਤਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਮਿਲੇਗੀ

1500 ਬਾਈਟ ਦਾ ਬ੍ਰਿਜ ਇੰਟਰਫੇਸ ਬਾਹਰੀ UDP ਅਤੇ IP ਹੈਡਰ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਟਨਲ ਨੂੰ ਇਸਦੀ ਸਮਰੱਥਾ ਤੋਂ ਵੱਧ ਦਿੰਦਾ ਹੈ। ਛੋਟੇ ਲੈਣ-ਦੇਣ ਪਾਰ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ DNS ਹੱਲ ਹੁੰਦਾ ਹੈ ਅਤੇ TLS ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਵੱਡਾ ਅਪਲੋਡ ਕਿਤੇ ਵੀ ਤਰੁੱਟੀ ਬਿਨਾਂ ਅਟਕ ਜਾਂਦਾ ਹੈ। ਭੇਜਣ ਵਾਲਾ ਉਹੀ ਸੈਗਮੈਂਟ ਆਕਾਰ ਦੁਹਰਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਛੋਟਾ ਹੋਣ ਦੱਸਣ ਵਾਲਾ ICMP ਟੁਕੜੀ-ਲੋੜ ਸੰਦੇਸ਼ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦਾ।

ਇਸਨੂੰ ਇੰਟਰਫੇਸ 'ਤੇ, MSS 'ਤੇ, ਜਾਂ ਦੋਵਾਂ 'ਤੇ ਠੀਕ ਕਰੋ। ਕਲੈਂਪਿੰਗ ਨੂੰ ਮਹਿਮਾਨ ਦੇ ਕਿਸੇ ਸਹਿਯੋਗ ਦੀ ਲੋੜ ਨਹੀਂ:

ip link set dev tun0 mtu 1400
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ਕਲੈਂਪ ਸਿਰਫ਼ TCP ਮੁੜ ਲਿਖਦਾ ਹੈ। UDP, QUIC ਸਮੇਤ, ਇਸਦੀ ਥਾਂ ਮਹਿਮਾਨ ਦਾ ਇੰਟਰਫੇਸ ਹੇਠਾਂ ਲਿਆਉਣ ਦੀ ਲੋੜ ਹੈ, --opt com.docker.network.driver.mtu=1400 ਨਾਲ ਨੈੱਟਵਰਕ ਬਣਾਉਂਦਿਆਂ ਜਾਂ ਮਿਲਦੀ compose ਕੁੰਜੀ ਨਾਲ।

DNS ਅਤੇ ਦੁਹਰਾਉਣ ਯੋਗ ਜਾਂਚਾਂ

ਨਾਮ ਹੱਲ ਉਸੇ ਰਾਹ ਚੱਲਦਾ ਹੈ। Docker ਦਾ ਅੰਦਰੂਨੀ ਰਿਜ਼ੌਲਵਰ 127.0.0.11 'ਤੇ ਹੋਸਟ ਦੇ ਸੰਰਚਿਤ ਸਰਵਰਾਂ ਵੱਲ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਕੰਟੇਨਰ ਹੋਸਟ ਜੋ ਵਰਤਦਾ ਹੈ ਉਹ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ। ਜਦੋਂ ਨਿੱਜੀ ਜ਼ੋਨ ਦਾ ਜਵਾਬ ਸਿਰਫ਼ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਣ ਵਾਲਾ ਰਿਜ਼ੌਲਵਰ ਦਿੰਦਾ ਹੈ, ਮਹਿਮਾਨ ਨੂੰ ਉਸ ਪਤੇ ਵੱਲ ਮੋੜੋ, ਅਤੇ getent hosts ਨਾਲ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਪਰਖੋ, ਹੋਸਟ 'ਤੇ ਨਹੀਂ।

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

ਸੂਚੀ ਹੇਠਾਂ ਚੱਲੋ ਅਤੇ ਪਹਿਲੀ ਅਸਫਲਤਾ 'ਤੇ ਰੁਕੋ। ਉਹੀ ਪਰਤ ਠੀਕ ਕਰਨੀ ਹੈ; ਹੇਠਾਂ ਜੋੜੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਸਿਰਫ਼ ਟੁੱਟਦੀ ਸੀਮਾ ਲੁਕਾਉਂਦੀ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ