VPN ਉੱਤੇ Docker ਕੰਟੇਨਰ ਨਹੀਂ ਪਹੁੰਚਦਾ? ਸਬਨੈੱਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ
Docker ਇੱਕ ਸਬਨੈੱਟ ਦਿੰਦਾ ਹੈ ਜਿਸ ਉੱਤੇ VPN ਵੀ ਦਾਅਵਾ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਪਤਾ ਯੋਜਨਾਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਅਜਿਹੀ ਮੁਰੰਮਤ ਚੁਣੋ ਜੋ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਵੀ ਟਿਕੇ।
ਕੰਟੇਨਰ ਦਫ਼ਤਰ ਦੇ LAN ਉੱਤੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਪਰ ਕੰਪਨੀ ਦਾ VPN ਜੁੜਦੇ ਹੀ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। ਕੰਟੇਨਰ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ: ਨਾ ਮੁੜ ਸ਼ੁਰੂ, ਨਾ ਇਮੇਜ ਅੱਪਡੇਟ, ਨਾ ਕਨਫਿਗ ਸੋਧ। ਜੋ ਬਦਲਿਆ ਹੈ ਉਹ ਹੋਸਟ ਦੀ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਹੈ, ਜਿੱਥੇ ਟਨਲ ਵੱਲੋਂ ਜੋੜਿਆ ਰਾਊਟ ਹੁਣ Docker ਵੱਲੋਂ ਦਿੱਤੇ ਪਤੇ ਨੂੰ ਢਕਦਾ ਹੈ। ਸਬਨੈੱਟ ਬਦਲਣ ਜਾਂ VPN ਛੋਟ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਪਤਾ ਯੋਜਨਾਵਾਂ ਨੂੰ ਨਾਲ-ਨਾਲ ਰੱਖੋ, ਕਿਉਂਕਿ ਹਰ ਮੁਰੰਮਤ ਵੱਖਰਾ ਸਮਾਂ ਲੈਂਦੀ ਹੈ।
ਕਨਫਿਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਰਾਊਟ ਪੜ੍ਹੋ
ਉਸ ਨੈੱਟਵਰਕ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ Docker ਨੇ ਅਸਲ ਵਿੱਚ ਬਣਾਇਆ। IPAM ਬਲਾਕ ਪਤਾ ਯੋਜਨਾ ਹੈ, ਅਤੇ ਸਬਨੈੱਟ ਉਹ ਲਾਈਨ ਹੈ ਜੋ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ:
docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]Compose ਹਰ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਲਈ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ /16 ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਦੋ ਸੇਵਾਵਾਂ 65,536 ਪਤਿਆਂ ਦੀ ਹੱਦ ਅੰਦਰ ਰਹਿ ਸਕਦੀਆਂ ਹਨ। ਇਹੀ ਚੌੜਾਈ ਕਾਰਨ ਹੈ ਕਿ ਓਵਰਲੈਪ ਆਮ ਹੁੰਦੇ ਹਨ: ਬੇਤਰਤੀਬ ਚੁਣਿਆ /16 ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਣ ਵਾਲੀ ਸਾਈਟ ਨੂੰ ਨਿਗਲਣ ਲਈ ਕਾਫ਼ੀ ਵੱਡਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਚਾਲੂ ਹੋਣ ਤੱਕ ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ।
ਫਿਰ ਇੱਕ ਕੰਟੇਨਰ ਪਤੇ ਲਈ ਰਾਊਟ ਚੋਣ ਦੀ ਤੁਲਨਾ ਕਰੋ — ਇੱਕ ਵਾਰ ਟਨਲ ਬੰਦ ਹੋਣ ’ਤੇ ਅਤੇ ਇੱਕ ਵਾਰ ਚਾਲੂ ਹੋਣ ’ਤੇ:
ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1ਜਵਾਬ ਦੀਆਂ ਦੋ ਸ਼ਕਲਾਂ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ਲੈ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਆਉਟਪੁੱਟ tun0, wg0 ਜਾਂ ਕੋਈ ਹੋਰ ਟਨਲ ਡਿਵਾਈਸ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਤਾਂ VPN ਪ੍ਰੀਫਿਕਸ ਘੱਟੋ-ਘੱਟ ਬ੍ਰਿਜ ਰਾਊਟ ਜਿੰਨਾ ਖਾਸ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪੈਕਟ ਕਦੇ ਵੀ ਕੰਟੇਨਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਜੇ ਇਹ ਅਜੇ ਵੀ ਬ੍ਰਿਜ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਤਾਂ ਹੋਸਟ ਕੰਟੇਨਰ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਗੜਬੜ ਫਿਲਟਰਿੰਗ, DNS ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਫੇਲ ਹੋਣ ਵਾਲਾ ਵਾਪਸੀ ਮਾਰਗ ਹੈ।
/16 ਟਕਰਾਅ ਆਸਾਨੀ ਨਾਲ ਕਿਉਂ ਹੁੰਦਾ ਹੈ
Docker ਬ੍ਰਿਜ ਨੈੱਟਵਰਕ ਨਿੱਜੀ ਪੂਲਾਂ ਵਿੱਚੋਂ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਡਿਫ਼ਾਲਟ ਪੂਲ 172.16.0.0/12 ਬਲਾਕ ਵਿੱਚੋਂ /16 ਟੁਕੜਿਆਂ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਕਾਰਪੋਰੇਟ ਨੈੱਟਵਰਕ ਅਕਸਰ ਉਹੀ ਨਿੱਜੀ ਥਾਂ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਰਿਮੋਟ-ਐਕਸੈਸ VPN ਉਹ ਪ੍ਰੀਫਿਕਸ ਹਰ ਜੁੜਨ ਵਾਲੇ ਕਲਾਇੰਟ ਤੱਕ ਧੱਕਦਾ ਹੈ। ਜਦੋਂ ਦੋਵੇਂ ਧਿਰਾਂ ਮੰਨਦੀਆਂ ਹਨ ਕਿ 172.18.0.0/16 ਉਨ੍ਹਾਂ ਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਵਿੱਚ ਦੋ ਵਿਰੋਧੀ ਦਾਅਵੇ ਹੁੰਦੇ ਹਨ।
ਪ੍ਰੀਫਿਕਸ ਲੰਬਾਈ ਜੇਤੂ ਤੈਅ ਕਰਦੀ ਹੈ, ਰਾਊਟਾਂ ਦਾ ਕ੍ਰਮ ਨਹੀਂ। 10.0.0.0/8 ਧੱਕਣ ਵਾਲਾ ਟਨਲ 172.18.0.0/16 ਦੇ ਬ੍ਰਿਜ ਰਾਊਟ ਨੂੰ ਨਹੀਂ ਹਰਾਉਂਦਾ, ਕਿਉਂਕਿ /8 ਘੱਟ ਖਾਸ ਹੈ। 172.18.0.0/16, ਜਾਂ ਉਸ ਅੰਦਰਲਾ 172.18.5.0/24, ਧੱਕਣ ਵਾਲਾ ਟਨਲ ਹਰਾ ਦਿੰਦਾ ਹੈ। ਇਸੇ ਲਈ ਇੱਕ ਲੈਪਟਾਪ ਦਫ਼ਤਰ ਦੇ ਨੈੱਟਵਰਕ ਉੱਤੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਉਸੇ VPN ਨਾਲ ਹੋਟਲ ਦੇ Wi-Fi ਉੱਤੇ ਫੇਲ ਹੁੰਦਾ ਹੈ: ਕਲਾਇੰਟ ਨੂੰ ਵੱਖਰੇ ਪ੍ਰੀਫਿਕਸ ਮਿਲਦੇ ਹਨ।
ਉਹੀ ਸਾਰਣੀ ਦੂਜੀ ਦਿਸ਼ਾ ਵੀ ਸੰਭਾਲਦੀ ਹੈ। 10.8.4.20 ਉੱਤੇ ਅੰਦਰੂਨੀ ਹੋਸਟ ਚਾਹੀਦਾ ਕੰਟੇਨਰ ਪੈਕਟ ਆਪਣੇ ਬ੍ਰਿਜ ਗੇਟਵੇ ਨੂੰ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਹੋਸਟ ਉਸਨੂੰ ਟਨਲ ਵਿੱਚ ਰਾਊਟ ਕਰਦਾ ਹੈ। ਉਹ ਮਾਰਗ ਆਮ ਤੌਰ ’ਤੇ ਚੱਲਦਾ ਹੈ ਕਿਉਂਕਿ ਹੋਸਟ NAT ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਾਰਪੋਰੇਟ ਧਿਰ ਸਿਰਫ਼ ਲੈਪਟਾਪ ਦਾ VPN ਪਤਾ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ, ਜਾਂ ਜਦੋਂ ਰਿਵਰਸ-ਪਾਥ ਫਿਲਟਰਿੰਗ ਅਸਮਾਨ ਜਵਾਬ ਸੁੱਟ ਦਿੰਦੀ ਹੈ।
ਤਿੰਨ ਮੁਰੰਮਤਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ
ਬਾਹਰ ਨਿਕਲਣ ਦੇ ਸਿਰਫ਼ ਤਿੰਨ ਰਾਹ ਹਨ, ਅਤੇ ਇਹ ਕਿਸ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣੀ ਹੈ ਅਤੇ ਇੱਕ ਲਾਗੂ ਕਰਦੇ ਸਮੇਂ ਕੀ ਟੁੱਟਦਾ ਹੈ ਵਿੱਚ ਵੱਖਰੇ ਹਨ।
| Repair | Who owns it | What it costs |
|---|---|---|
| Renumber the container network | You | Recreates the network, restarts services, invalidates literal addresses in configs and scripts |
| Exclude your range from the tunnel | Network team | Changes what every laptop sees, needs a change request and a client profile update |
| Reach the service through a published port | You and the client | One port only, no direct container-to-container routing across the tunnel |
ਮੁੜ-ਨੰਬਰੀ ਹੀ ਇੱਕੋ ਮੁਰੰਮਤ ਹੈ ਜੋ ਟਿਕਟ ਤੋਂ ਬਿਨਾਂ ਪੂਰੀ ਹੋ ਸਕਦੀ ਹੈ, ਇਸੇ ਲਈ ਬਹੁਤੇ ਲੇਖ ਉੱਥੇ ਹੀ ਰੁਕ ਜਾਂਦੇ ਹਨ। ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਉੱਤੇ ਇਹ ਸਸਤੀ ਹੈ, ਪਰ ਮਹਿੰਗੀ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਟੂਲ ਜਾਂ ਸੰਭਾਲੀ ਕਨੈਕਸ਼ਨ ਸਤਰ ਕਿਸੇ ਸ਼ਬਦੀ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ। YAML ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਹਵਾਲੇ ਗਿਣੋ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ।
ਜਦੋਂ ਓਵਰਲੈਪ ਤੁਹਾਡੀ ਕੰਪਨੀ ਦੀ ਸੱਚਮੁੱਚ ਮਾਲਕੀ ਵਾਲੀ ਹੱਦ ਵਿੱਚ ਹੋਵੇ, ਤਾਂ ਟਨਲ ਵਿੱਚੋਂ ਛੋਟ ਸਭ ਤੋਂ ਸਾਫ਼ ਜਵਾਬ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਹੌਲੀ ਵੀ ਹੈ, ਅਤੇ ਉਸ ਠੇਕੇਦਾਰ ਲਈ ਬੇਕਾਰ ਹੈ ਜੋ ਕਲਾਇੰਟ ਪ੍ਰੋਫ਼ਾਈਲ ਨਹੀਂ ਬਦਲ ਸਕਦਾ। ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ ਜਾਂ ਛੋਟਾ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਇਹ ਬਹਿਸ ਟਾਲਦਾ ਹੈ: ਕਲਾਇੰਟ ਉਸ ਪਤੇ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਟਨਲ ਪਹਿਲਾਂ ਹੀ ਸਹੀ ਰਾਊਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਉਹ ਪੋਰਟ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜਾਣ-ਬੁੱਝ ਕੇ ਹੱਦ ਤੈਅ ਕਰੋ
ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਲਈ, compose ਫ਼ਾਈਲ ਵਿੱਚ ਸਬਨੈੱਟ ਐਲਾਨੋ ਤਾਂ ਜੋ ਪ੍ਰੋਜੈਕਟ ਸਾਂਝੇ ਪੂਲ ਵਿੱਚੋਂ ਲੈਣਾ ਬੰਦ ਕਰੇ:
networks:
default:
ipam:
config:
- subnet: 10.201.7.0/24ਉਹ ਹੱਦ ਖੋਜਦਿਆਂ ਮਿਲੇ ਕਿਸੇ ਉਦਾਹਰਨ ਤੋਂ ਨਹੀਂ, ਸਗੋਂ ਤੁਹਾਡੀ ਟੀਮ ਦੇ ਰੱਖੇ ਰਜਿਸਟਰ ਤੋਂ ਲਓ। ਇਸਨੂੰ VPN ਵੱਲੋਂ ਧੱਕੇ ਪ੍ਰੀਫਿਕਸ, ਲੋਕਾਂ ਦੇ ਕੰਮ ਵਾਲੇ ਘਰ ਦੇ LAN ਅਤੇ ਉਸੇ ਹੋਸਟ ਦੇ ਹੋਰ ਕੰਟੇਨਰ ਨੈੱਟਵਰਕ ਨਾਲ ਜਾਂਚੋ। ਫਿਰ ਮੁੜ-ਨਿਰਮਾਣ ਦੀ ਯੋਜਨਾ ਬਣਾਓ, ਕਿਉਂਕਿ ਮੌਜੂਦਾ ਨੈੱਟਵਰਕ ਆਪਣਾ ਪੁਰਾਣਾ ਸਬਨੈੱਟ ਰੱਖਦਾ ਹੈ: docker compose down, ਫਿਰ up -d। ਐਂਡਪਾਇੰਟ ਜੁੜੇ ਹੋਣ ਸਮੇਂ docker network rm ਮਨਾਹੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਫ਼ਾਈਲ ਵਿੱਚ ਕੋਈ ਵੀ ipv4_address ਐਂਟਰੀ ਨਵੀਂ ਹੱਦ ਅੰਦਰ ਆਉਣੀ ਚਾਹੀਦੀ ਹੈ।
Docker ਵੱਲੋਂ ਆਪਣੇ ਆਪ ਬਣਾਏ ਨੈੱਟਵਰਕਾਂ ਲਈ, /etc/docker/daemon.json ਵਿੱਚ ਡੈਮਨ ਪੂਲ ਸੈੱਟ ਕਰੋ:
{
"default-address-pools": [
{ "base": "10.201.0.0/16", "size": 24 },
{ "base": "10.202.0.0/16", "size": 24 }
]
}ਇਹ ਪੂਲ ਡੈਮਨ ਮੁੜ ਚਾਲੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਬਣੇ ਨੈੱਟਵਰਕਾਂ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਬ੍ਰਿਜ ਆਪਣੇ ਪਤੇ ਰੱਖਦੇ ਹਨ। ਇਹ ਸੁਵਿਧਾਜਨਕ ਹੈ ਅਤੇ ਭੁੱਲਣਾ ਆਸਾਨ, ਇਸ ਲਈ ਪੁਰਾਣੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਅਜੇ ਵੀ ਓਵਰਲੈਪ ਮੰਨੋ ਜਦ ਤੱਕ ਕੋਈ ਉਸਦਾ ਨੈੱਟਵਰਕ ਮੁੜ ਨਾ ਬਣਾਵੇ। Docker ਦੀ ਇੰਜਣ ਨੈੱਟਵਰਕਿੰਗ ਦਸਤਾਵੇਜ਼ ਸਮੀਖਿਆ ਵਿੱਚ ਪੂਲ ਦਾ ਬਚਾਅ ਕਰਨਾ ਪਵੇ ਤਾਂ ਵੰਡ ਦੇ ਨਿਯਮ ਦੱਸਦੀ ਹੈ।
Linux ਬ੍ਰਿਜ ਅਤੇ Docker Desktop ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ
Linux ਹੋਸਟ ਉੱਤੇ, ਕੰਟੇਨਰ ਹੋਸਟ ਨੇਮਸਪੇਸ ਦੇ ਬ੍ਰਿਜਾਂ ਉੱਤੇ ਬੈਠਦੇ ਹਨ। ਇੱਕੋ ਸਾਰਣੀ ਸਭ ਤੈਅ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਉੱਪਰਲੀ ਤੁਲਨਾ ਹੀ ਪੂਰੀ ਕਹਾਣੀ ਹੈ: ਬ੍ਰਿਜ ਰਾਊਟ ਪੜ੍ਹੋ, ਟਨਲ ਰਾਊਟ ਪੜ੍ਹੋ, ਅਤੇ ਵੇਖੋ ਕਿ ਅਸਲੀ ਕੰਟੇਨਰ ਪਤੇ ਲਈ ਕੌਣ ਜਿੱਤਦਾ ਹੈ।
Docker Desktop ਕੰਟੇਨਰਾਂ ਨੂੰ ਆਪਣੇ NAT ਵਾਲੀ VM ਪਿੱਛੇ ਰੱਖਦਾ ਹੈ। ਹੋਸਟ ਕੋਲ ਕੰਟੇਨਰ ਪਤੇ ਤੱਕ ਕੋਈ ਰਾਊਟ ਨਹੀਂ ਹੁੰਦਾ; ਇਹ ਸੇਵਾ ਤੱਕ ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ ਰਾਹੀਂ ਪਹੁੰਚਦਾ ਹੈ, ਆਮ ਤੌਰ ’ਤੇ 127.0.0.1 ਨਾਲ ਬੱਝੀ। ਇਸ ਲਈ VPN ਕਲਾਇੰਟ ਬਿਨਾਂ ਕਿਸੇ ਸਬਨੈੱਟ ਓਵਰਲੈਪ ਦੇ ਸੇਵਾ ਤੋੜ ਸਕਦਾ ਹੈ: VM ਦੀ ਅੰਦਰੂਨੀ ਹੱਦ ਲਈ ਰਾਊਟ ਲਾ ਕੇ ਜਾਂ ਟਨਲ ਜੁੜੇ ਹੋਣ ਸਮੇਂ loopback ਟ੍ਰੈਫਿਕ ਰੋਕ ਕੇ। ਜੇ ਹੋਸਟ ਉੱਤੇ ip route get ਕੰਟੇਨਰ ਪਤੇ ਲਈ ਰਾਊਟ ਨਹੀਂ ਦੱਸਦਾ, ਤਾਂ ਇਹ ਉਮੀਦਵਾਰ ਹੈ, ਬੱਗ ਨਹੀਂ।
ਵਿਹਾਰਕ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਕਿੱਥੇ ਵੇਖਦੇ ਹੋ। Linux ਉੱਤੇ, ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। Desktop ਉੱਤੇ, ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ ਅਤੇ VPN ਕਲਾਇੰਟ ਦੇ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਜਾਂਚੋ ਕਿ VM ਦਾ ਅੰਦਰੂਨੀ ਸਬਨੈੱਟ ਟਨਲ ਵੱਲੋਂ ਧੱਕੀ ਕਿਸੇ ਚੀਜ਼ ਨਾਲ ਟਕਰਾਉਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਟਨਲ ਚਾਲੂ ਰੱਖ ਕੇ ਪਰਖੋ
ਇਸਨੂੰ ਠੀਕ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ VPN ਦੋ ਵਾਰ ਮੁੜ ਜੋੜੋ, ਕਿਉਂਕਿ ਜੁੜਨ ’ਤੇ ਰਾਊਟ ਧੱਕਣ ਅਤੇ ਟੁੱਟਣ ’ਤੇ ਉਹ ਵਾਪਸ ਲੈਣ ਵਾਲਾ ਪ੍ਰੋਫ਼ਾਈਲ ਪਹਿਲੇ ਯਤਨ ਤੋਂ ਬਾਅਦ ਸਹੀ ਲੱਗ ਸਕਦਾ ਹੈ। ਫਿਰ ਉਹ ਜਾਂਚਾਂ ਕਰੋ ਜੋ ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਕਰਦਾ ਹੈ:
- ਕੰਟੇਨਰ ਦਾ ਅਸਲੀ ਪਤਾ ਵਰਤ ਕੇ ਹੋਸਟ ਤੋਂ
ip route get। - ਸੇਵਾ ਆਪ ਸਿਹਤਮੰਦ ਹੈ ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਦੂਜੇ ਕੰਟੇਨਰ ਤੋਂ ਬੇਨਤੀ।
- ਟਨਲ ਚਾਲੂ ਹੋਣ ’ਤੇ ਕਲਾਇੰਟ ਤੋਂ
curl -sv http://127.0.0.1:8080/, ਫਿਰ LAN ਦੀ ਮਸ਼ੀਨ ਤੋਂ ਕੰਟੇਨਰ ਪਤੇ ਨੂੰtraceroute -n। - ਜੇ ਬੇਨਤੀ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ ਪਰ ਜਵਾਬ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ
sysctl net.ipv4.conf.all.rp_filter।
ਅੰਤ ਵਿੱਚ, ਚੁਣੀ ਹੱਦ ਨੂੰ ਉਸੇ ਰਜਿਸਟਰ ਵਿੱਚ ਲਿਖੋ ਜਿੱਥੋਂ ਇਹ ਚੁਣੀ ਸੀ, ਤਾਰੀਖ਼ ਅਤੇ ਇਸਦੀ ਮਾਲਕੀ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟ ਸਮੇਤ। ਅਗਲਾ ਓਵਰਲੈਪ ਕਿਸੇ ਅਜਿਹੇ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਆਵੇਗਾ ਜਿਸਨੂੰ ਕਿਸੇ ਨੇ ਦਰਜ ਨਹੀਂ ਕੀਤਾ, ਅਤੇ ਇੱਕੋ ਬਚਾਅ ਇਹ ਹੈ ਕਿ ਹੱਦ ਬੇਤਰਤੀਬ ਨਹੀਂ ਸਗੋਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਰਾਖਵੀਂ ਰੱਖੀ ਗਈ ਸੀ।