OpenVPN ਨਾਲ ਜੁੜੇ ਹੋ ਪਰ ਕੁਝ ਵੀ ਲੋਡ ਨਹੀਂ ਹੁੰਦਾ: ਕਲਾਇੰਟ ਤੋਂ ਬਾਹਰ ਵੱਲ ਇੱਕ ਯਾਤਰਾ

ਕਲਾਇੰਟ ਵਿੰਡੋ Connected ਕਹਿੰਦੀ ਹੈ, ਟਨਲ ਦਾ ਪਤਾ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਅਜੇ ਵੀ ਘੁੰਮ ਰਿਹਾ ਹੈ। ਇਹ ਸੰਜੋਗ ਆਮ ਹੈ, ਕਿਉਂਕਿ ਸਫਲ ਹੈਂਡਸ਼ੇਕ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਟਨਲ ਬਣ ਗਿਆ ਹੈ; ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਸਰਵਰ ਤੁਹਾਡੇ ਪੈਕਟ ਅੱਗੇ ਭੇਜੇਗਾ, ਉਨ੍ਹਾਂ ਦਾ ਸਰੋਤ ਦੁਬਾਰਾ ਲਿਖੇਗਾ, ਜਾਂ ਤੁਹਾਡੀਆਂ DNS ਪੁੱਛਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇਗਾ। ਬਹੁਤੇ ਲੋਕਾਂ ਦੀ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਉਹ ਪਹਿਲਾਂ ਸਰਵਰ ਕਨਫਿਗਰੇਸ਼ਨ ਖੋਲ੍ਹਦੇ ਹਨ। ਇਸ ਦੀ ਬਜਾਏ ਕਲਾਇੰਟ ਤੋਂ ਬਾਹਰ ਵੱਲ ਕੰਮ ਕਰੋ, ਕਿਉਂਕਿ ਹੇਠਾਂ ਦਾ ਹਰ ਕਦਮ ਦੱਸਦਾ ਹੈ ਕਿ ਅਗਲਾ ਕਦਮ ਜਾਂਚਣ ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ।

ਕਲਾਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਬਾਹਰ ਵੱਲ ਜਾਓ

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

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

ਦੋ ਕੈਪਚਰ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਪੈਕਟ ਕਿੱਥੇ ਰੁਕਦੇ ਹਨ

ਕਲਾਇੰਟ ਤੋਂ ਜਨਤਕ ਪਤੇ ਤੇ ping ਚੱਲਦੇ ਸਮੇਂ ਟਨਲ ਇੰਟਰਫੇਸ ਤੇ ਇੱਕ ਕੈਪਚਰ ਅਤੇ ਇੰਟਰਨੈੱਟ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੇ ਅੱਪਲਿੰਕ ਤੇ ਦੂਜਾ ਕੈਪਚਰ ਲਓ। ਦੋਵੇਂ ਇੱਕੋ ਸਮੇਂ ਚਲਾਓ ਤਾਂ ਜੋ ਸਮੇਂ ਦੀਆਂ ਮੋਹਰਾਂ ਮਿਲ ਜਾਣ।

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

ਅੱਪਲਿੰਕ ਦਾ ਨਾਮ ਟਿਊਟੋਰਿਅਲ ਤੋਂ ਨਹੀਂ, ਰਾਊਟਿੰਗ ਟੇਬਲ ਤੋਂ ਲਓ। ਕਲਾਊਡ ਇਮੇਜ ਅਤੇ ਨਾਮ ਬਦਲੇ ਐਡਾਪਟਰ ਗਾਈਡ ਦੇ ਉਦਾਹਰਨ ਇੰਟਰਫੇਸ ਨਾਲ ਘੱਟ ਹੀ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਗਲਤ ਡਿਵਾਈਸ ਤੇ ਲਿਆ ਕੈਪਚਰ ਬਿਲਕੁਲ ਉਸ ਸਰਵਰ ਵਰਗਾ ਦਿਸਦਾ ਹੈ ਜੋ ਅੱਗੇ ਨਹੀਂ ਭੇਜ ਰਿਹਾ:

ip -4 route get 9.9.9.9

ਉਸ ਆਉਟਪੁੱਟ ਦਾ dev ਖੇਤਰ ਉਹ ਨਾਮ ਹੈ ਜੋ NAT ਨਿਯਮ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਚਾਹੀਦਾ ਹੋਵੇਗਾ, ਇਸ ਲਈ ਇਸਨੂੰ ਰੱਖੋ।

ਅੱਗੇ ਭੇਜਣਾ ਕਰਨਲ ਦਾ ਇੱਕ ਸਵਿੱਚ ਅਤੇ ਫਾਇਰਵਾਲ ਦੀ ਨੀਤੀ ਹੈ

ਕਰਨਲ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਅੱਗੇ ਭੇਜਣ ਲਈ ਸਹਿਮਤ ਹੋਣਾ ਪਵੇਗਾ। ਮੌਜੂਦਾ ਮੁੱਲ ਪੜ੍ਹੋ, ਫਿਰ ਸੈਟਿੰਗ ਨੂੰ ਸਿਰਫ਼ ਚੱਲ ਰਹੇ ਕਰਨਲ ਵਿੱਚ ਲਿਖਣ ਦੀ ਬਜਾਏ ਪੱਕੀ ਬਣਾਓ:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

ਅੱਗੇ ਭੇਜਣਾ ਅੱਧਾ ਹੀ ਹੈ। UFW ਵਾਲੇ ਹੋਸਟ ਤੇ ਫਾਰਵਰਡ ਨੀਤੀ /etc/default/ufw ਵਿੱਚ ਸੈੱਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਰੀਲੋਡ ਲਾਗੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ACCEPT ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਫਾਰਵਰਡ ਮਾਰਗ ਤੇ ਡਿਫ਼ਾਲਟ ਡ੍ਰੌਪ ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿਹਤਮੰਦ ਰੱਖਦਾ ਹੈ ਅਤੇ ਟਨਲ ਵਿੱਚੋਂ ਬਾਹਰ ਨਿਕਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲਾ ਹਰ ਪੈਕਟ ਚੁੱਪਚਾਪ ਸੁੱਟ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਲੱਛਣ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ।

ਜੋ ਹੋਸਟ nftables ਸਿੱਧਾ ਸੰਭਾਲਦੇ ਹਨ ਉਨ੍ਹਾਂ ਕੋਲ ਉਹੀ ਸਵਾਲ ਦੂਜੇ ਵਾਕ-ਢਾਂਚੇ ਵਿੱਚ ਹੈ। ਕਲਾਇੰਟ ਟੈਸਟ ਚੱਲਦੇ ਸਮੇਂ ਫਾਰਵਰਡ ਚੇਨ ਦੇ ਕਾਊਂਟਰ ਵੇਖੋ, ਕਿਉਂਕਿ ਜਿਸ ਚੇਨ ਨੂੰ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜੋ ਚੇਨ ਸੁੱਟਦੀ ਹੈ, ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ।

NAT ਨਿਯਮ ਵਿੱਚ ਅਸਲ ਐਗਰੈਸ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ ਦਿਓ

ਸਰੋਤ ਤਰਜਮਾ ਉਸ ਇੰਟਰਫੇਸ ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸੱਚਮੁੱਚ ਹੋਸਟ ਛੱਡਦਾ ਹੈ, ਸਰਵਰ ਵੱਲੋਂ ਵੰਡੇ ਪੂਲ ਨਾਲ। ਉਸ ਨਿਯਮ ਦੇ ਦੋਵੇਂ ਅੱਧ ਸੱਚਾਈ ਦਾ ਵਰਣਨ ਕਰਨ, ਅਤੇ ਕੋਈ ਵੀ ਚੋਣਵਾਂ ਨਹੀਂ ਹੈ।

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

ਕਲਾਸਿਕ ਫੇਲ੍ਹ ਉਹ ਨਿਯਮ ਹੈ ਜੋ ਗਾਈਡ ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਗਿਆ ਅਤੇ -o eth0 ਕਹਿੰਦਾ ਹੈ ਉਸ ਮਸ਼ੀਨ ਤੇ ਜਿਸ ਦਾ ਐਡਾਪਟਰ ਕੁਝ ਹੋਰ ਅਖਵਾਉਂਦਾ ਹੈ। ਨਿਯਮ ਬਿਨਾਂ ਚੇਤਾਵਨੀ ਇੰਸਟਾਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਕਿਸੇ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ, ਅਤੇ ਕਲਾਇੰਟ ਕੋਲ ਇੰਟਰਨੈੱਟ ਨਹੀਂ ਆਉਂਦਾ। ਪੂਲ ਉਸੇ ਗਲਤੀ ਦਾ ਦੂਜਾ ਅੱਧ ਹੈ: ਜੇ ਸਰਵਰ 10.44.0.0/24 ਵੰਡਦਾ ਹੈ ਅਤੇ ਨਿਯਮ 10.8.0.0/24 ਨੂੰ ਢੱਕਦਾ ਹੈ, ਤਾਂ ਕੁਝ ਵੀ ਕਦੇ ਨਹੀਂ ਮਿਲੇਗਾ।

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

iptables -t nat -L POSTROUTING -v -n

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

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

DNS ਪਹਿਲੇ ਤੋਂ ਪਿੱਛੇ ਦੂਜੀ ਫੇਲ੍ਹ ਹੈ

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

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

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows ਕਲਾਇੰਟ ਫਿਰ ਵੀ ਸਥਾਨਕ ਰਿਜ਼ੌਲਵਰ ਤੇ ਵਾਪਸ ਆ ਸਕਦੇ ਹਨ, ਅਤੇ block-outside-dns ਠੀਕ ਇਹੀ ਰੋਕਣ ਲਈ ਹੈ, ਪਰ ਉਸ ਕੀਮਤ ਤੇ ਕਿ ਸਿਰਫ਼ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਜੋ ਨਾਮ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ ਉਹ ਗੁੰਮ ਹੋ ਜਾਣ। systemd-resolved ਵਰਤਣ ਵਾਲੇ Linux ਕਲਾਇੰਟ ਅਕਸਰ ਭੇਜੇ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ ਜਦ ਤੱਕ ਕੋਈ ਸਕ੍ਰਿਪਟ ਇਸਨੂੰ ਇੰਸਟਾਲ ਨਾ ਕਰੇ, ਇਸ ਲਈ ਇਹ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਭੇਜਣਾ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋਇਆ, ਟਨਲ ਡਿਵਾਈਸ ਲਈ resolvectl status ਵੇਖੋ।

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