Docker ਕੰਟੇਨਰ VPN ਪਿੱਛੇ ਦੇ ਹੋਸਟਾਂ ਤੱਕ ਕਿਉਂ ਨਹੀਂ ਪਹੁੰਚਦਾ

ਕਾਰਪੋਰੇਟ VPN ਪਿੱਛੇ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਤੱਕ ਨਾ ਪਹੁੰਚਣ ਵਾਲਾ ਕੰਟੇਨਰ ਆਮ ਤੌਰ 'ਤੇ ਟਨਲ ਤੋਂ ਵੱਖਰੇ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਹੋਸਟ ਕਲਾਇੰਟ ਦੇ ਰੂਟ, DNS ਸਰਵਰ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਸ਼ਾਨ ਹੋਸਟ ਦੇ ਸਟੈਕ ਦੇ ਹੁੰਦੇ ਹਨ; ਬ੍ਰਿਜ ਨੈੱਟਵਰਕ ਕੰਟੇਨਰ ਦਾ ਆਪਣਾ ਸਟੈਕ ਹੁੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਤੱਥ ਪਲੇਟਫਾਰਮ ਟੀਮ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੀਆਂ ਬਹੁਤੀਆਂ ਰਿਪੋਰਟਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਵੀ ਕਾਰਨ ਹੈ ਕਿ «VPN ਟੁੱਟੀ ਹੋਈ ਹੈ» ਅਤੇ «Docker VPN ਨੂੰ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ» ਦੋਵੇਂ ਇੱਕੋ ਸਮੇਂ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ। ਇੱਕ ਲੱਛਣ ਪਿੱਛੇ ਦੋ ਬਿਲਕੁਲ ਵੱਖਰੇ ਸੈੱਟਅਪ ਲੁਕੇ ਹੋਏ ਹਨ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਸੈਟਿੰਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜਾ ਹੈ।

ਪਤਾ ਲਗਾਓ ਕਿ ਟਨਲ ਕਿਸਦੇ ਨੇਮਸਪੇਸ ਦੀ ਹੈ

macOS ਜਾਂ Windows ਲਈ Docker Desktop 'ਤੇ ਕੰਟੇਨਰ Linux ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੇ ਅੰਦਰ ਚੱਲਦੇ ਹਨ। ਡੈਸਕਟਾਪ 'ਤੇ ਸਥਾਪਿਤ VPN ਕਲਾਇੰਟ ਡੈਸਕਟਾਪ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਟਨਲ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਉਸਨੂੰ ਕਦੇ ਨਹੀਂ ਦੇਖਦੀ। ਕੋਈ ਵੀ ਕੰਟੇਨਰ ਕਨਫਿਗਰੇਸ਼ਨ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦੀ, ਕਿਉਂਕਿ ਕੰਟੇਨਰ ਨੂੰ ਜਿਸ ਇੰਟਰਫੇਸ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਉਹ ਉਸਦੇ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਵਿੱਚ ਬਿਲਕੁਲ ਨਹੀਂ ਹੈ।

Linux ਹੋਸਟ 'ਤੇ ਟਨਲ ਹੋਸਟ ਦੇ ਨੇਮਸਪੇਸ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਬ੍ਰਿਜ ਕੰਟੇਨਰ ਆਮ ਤੌਰ 'ਤੇ ਬਾਹਰ ਜਾਂਦੇ ਸਮੇਂ ਸਰੋਤ NAT ਲਾਗੂ ਕੀਤੇ ਹੋਸਟ ਦੀ ਰਾਊਟਿੰਗ ਟੇਬਲ ਰਾਹੀਂ ਉਸ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ। ਜਦੋਂ ਉਹ ਰਾਹ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਕਾਰਨ ਆਮ ਤੌਰ 'ਤੇ ਗੁੰਮ ਰੂਟ ਨਹੀਂ, ਸਗੋਂ ਫਾਰਵਰਡਿੰਗ ਨੀਤੀ, ਰਿਵਰਸ-ਪਾਥ ਫਿਲਟਰਿੰਗ ਜਾਂ ਓਵਰਲੈਪਿੰਗ ਸਬਨੈੱਟ ਹੁੰਦਾ ਹੈ। ਅੱਗੇ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸ ਦੁਨੀਆ ਵਿੱਚ ਹੋ:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

ਉਹਨਾਂ ਦੋ ਰਾਊਟਿੰਗ ਟੇਬਲਾਂ ਵਿਚਕਾਰ ਫਰਕ ਇੱਕ ਸਕ੍ਰੀਨ 'ਤੇ ਪੂਰੀ ਸਮੱਸਿਆ ਹੈ। ਜੇ ਹੋਸਟ ਦੇ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਟਨਲ ਇੰਟਰਫੇਸ ਹੈ ਅਤੇ ਬ੍ਰਿਜ ਦੇ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਨਹੀਂ, ਤਾਂ ਤੁਸੀਂ ਨੇਮਸਪੇਸ ਅਲੱਗਾਅ ਦੇਖ ਰਹੇ ਹੋ, ਅਤੇ ਬਾਕੀ ਸਭ ਇਹ ਚੋਣ ਹੈ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਪਾਰ ਕਰਨਾ ਹੈ।

ਹੋਸਟ ਨੈੱਟਵਰਕਿੰਗ ਇੱਕ ਪਰਖ ਹੈ, ਡਿਜ਼ਾਈਨ ਨਹੀਂ

ਕੰਟੇਨਰ ਨੂੰ ਹੋਸਟ ਨੈੱਟਵਰਕਿੰਗ ਨਾਲ ਚਲਾਉਣਾ, ਜਿਸਨੂੰ Docker ਹੋਸਟ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਸਾਂਝਾ ਕਰਨ ਵਜੋਂ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਉਸਨੂੰ ਟਨਲ ਇੰਟਰਫੇਸ ਅਤੇ ਉਸਦੇ ਰੂਟ ਸਿੱਧੇ ਵਿਰਾਸਤ ਵਿੱਚ ਦਿੰਦਾ ਹੈ। ਜੇ ਉਹੀ ਬੇਨਤੀ ਫਿਰ ਸਫਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਰੂਟ ਸਿਧਾਂਤ ਪੁਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫੇਲ੍ਹਤਾ ਨੇਮਸਪੇਸ ਅਲੱਗਾਅ ਹੈ, ਪ੍ਰਮਾਣ ਪੱਤਰ, DNS ਜਾਂ ਪਹੁੰਚ ਨਿਯਮ ਨਹੀਂ।

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

ਇਸਨੂੰ ਨਿਦਾਨ ਵਜੋਂ ਰੱਖੋ। ਹੋਸਟ ਨੈੱਟਵਰਕਿੰਗ ਪੋਰਟ ਪ੍ਰਕਾਸ਼ਨ ਅਤੇ ਕੰਟੇਨਰ ਤੋਂ ਤੁਸੀਂ ਜੋ ਅਲੱਗਾਅ ਚਾਹੁੰਦੇ ਸੀ ਉਸਦਾ ਵੱਡਾ ਹਿੱਸਾ ਛੱਡ ਦਿੰਦੀ ਹੈ, ਅਤੇ Docker Desktop 'ਤੇ «host» ਦਾ ਅਰਥ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਹੈ, ਡੈਸਕਟਾਪ ਨਹੀਂ, ਇਸ ਲਈ ਉੱਥੇ ਦੀ ਸਫਲਤਾ ਜਾਂ ਫੇਲ੍ਹਤਾ ਤੁਹਾਨੂੰ ਭਰਮਾ ਸਕਦੀ ਹੈ ਜੇ ਤੁਸੀਂ ਭੁੱਲ ਜਾਓ ਕਿ ਕਿਹੜੇ ਹੋਸਟ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰ ਰਹੇ ਸੀ।

tun ਡਿਵਾਈਸ ਅਤੇ ਉਸਦੇ ਨਾਲ ਆਉਣ ਵਾਲੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ

ਕੰਟੇਨਰ ਦੇ ਅੰਦਰਲੇ VPN ਕਲਾਇੰਟ ਨੂੰ ਟਨਲ ਡਿਵਾਈਸ ਅਤੇ ਉਸਨੂੰ ਕਨਫਿਗਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਚਾਹੀਦੀ ਹੈ। ਆਮ ਸ਼ਾਰਟਕਟ --privileged ਹੈ, ਜੋ ਹਰ ਡਿਵਾਈਸ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪੂਰੇ ਕੰਟੇਨਰ ਵਿੱਚ ਸੁਰੱਖਿਆ ਨੀਤੀ ਢਿੱਲੀ ਕਰਦਾ ਹੈ। ਇਹ ਇਸ ਕੰਮ ਦੀ ਲੋੜ ਤੋਂ ਕਿਤੇ ਵੱਧ ਹੈ, ਅਤੇ ਸਮੀਖਿਆ ਵਿੱਚ ਇਸਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਣਾ ਔਖਾ ਹੈ।

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

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

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

ਬ੍ਰਿਜ NAT VPN ਦੇ ਦੇਖੇ ਸਰੋਤ ਨੂੰ ਬਦਲਦਾ ਹੈ

ਡਿਫਾਲਟ ਬ੍ਰਿਜ ਨਾਲ ਕੰਟੇਨਰ ਦਾ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਹੋਸਟ ਦੇ ਪਤੇ ਵਿੱਚ ਅਨੁਵਾਦ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ VPN ਪਿੱਛੇ ਕਾਰਪੋਰੇਟ ਪਾਸਾ ਕੰਟੇਨਰ ਦਾ ਨਹੀਂ, ਹੋਸਟ ਦੀ ਟਨਲ ਦਾ ਪਤਾ ਦੇਖਦਾ ਹੈ, ਸਰੋਤ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਨਿਯਮ ਇੰਝ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ ਜਿਵੇਂ ਬੇਨਤੀ ਹੋਸਟ ਨੇ ਭੇਜੀ ਹੋਵੇ, ਅਤੇ ਦੋ ਕੰਟੇਨਰ VPN ਸਰਵਰ ਲਈ ਅਭੇਦ ਹੋ ਜਾਂਦੇ ਹਨ।

macvlan ਜਾਂ ipvlan ਇਸਦੀ ਥਾਂ ਕੰਟੇਨਰ ਨੂੰ LAN ਪਤਾ ਦਿੰਦਾ ਹੈ, ਜੋ LAN ਖੋਜ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਨੂੰ ਸੈਗਮੈਂਟ ਉੱਤੇ ਬਰਾਬਰ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਹ ਹੋਸਟ ਦੀ ਟਨਲ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਅਜਿਹਾ ਕੰਟੇਨਰ ਸਿਰਫ-VPN ਪ੍ਰੀਫਿਕਸ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੇਗਾ ਜਦੋਂ ਤੱਕ VPN ਉਸ LAN ਤੋਂ ਵੀ ਪਹੁੰਚਯੋਗ ਨਹੀਂ।

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

DNS ਡੈਮਨ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ, ਟਨਲ ਦੀ ਨਹੀਂ

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

ਸੇਵਾ ਲਈ ਰਿਜ਼ੋਲਵਰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸੈੱਟ ਕਰੋ, ਜਾਂ ਇਸਨੂੰ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਅੰਦਰੂਨੀ ਰਿਜ਼ੋਲਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ। ਜੋ ਕੰਟੇਨਰ ਨਿੱਜੀ ਨਾਮ ਨੂੰ ਜਨਤਕ ਪਤੇ ਵਿੱਚ ਹੱਲ ਕਰਦਾ ਹੈ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਜਨਤਕ ਰਿਜ਼ੋਲਵਰ ਵਰਤਦਾ ਹੈ, ਟੁੱਟੇ ਰੂਟ ਤੋਂ ਪੀੜਤ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਸੁਧਾਰ compose ਫਾਈਲ ਜਾਂ ਡੈਮਨ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਹੈ।

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

ਟਿਕਟ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੈੱਕਲਿਸਟ: ਟਨਲ ਦਾ ਮਾਲਕ ਨੇਮਸਪੇਸ ਪਛਾਣੋ, ਹੋਸਟ ਨੈੱਟਵਰਕਿੰਗ ਨਾਲ ਰਾਹ ਸਾਬਤ ਕਰੋ, ਸਿਰਫ ਲੋੜੀਂਦਾ tun ਡਿਵਾਈਸ ਮੈਪ ਕਰੋ, NAT ਤੋਂ ਬਾਅਦ ਸਰੋਤ ਪਤਾ ਯਾਦ ਰੱਖੋ, ਰਿਜ਼ੋਲਵਰ ਸਪੱਸ਼ਟ ਸੈੱਟ ਕਰੋ ਅਤੇ ਪ੍ਰਤੀ-ਕੰਟੇਨਰ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਪਤਿਆਂ ਨੂੰ ਝੰਡਾ ਨਹੀਂ, ਆਰਕੀਟੈਕਚਰ ਫੈਸਲਾ ਮੰਨੋ।