VPN ਅਤੇ ਵੈੱਬ ਲਈ ਇੱਕ ਹੀ ਜਨਤਕ ਹੋਸਟ: ਭੂਮਿਕਾਵਾਂ ਕਿਵੇਂ ਵੰਡੀਆਂ ਜਾਣ

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

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

ਪੋਰਟਾਂ ਤੋਂ ਪਹਿਲਾਂ ਪਤੇ ਦਾ ਮਾਲਕ ਚੁਣੋ

ਟਨਲ ਦਾ ਆਖ਼ਰੀ ਬਿੰਦੂ ਅਤੇ ਵੈੱਬ ਸਰਵਰ ਇੱਕ ਹੀ ਕਰਨਲ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹਨ; ਇੱਕੋ ਸਮੇਂ ਇੱਕ ਪਤਾ, ਪੋਰਟ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਸਾਂਝਾ ਕਰਨਾ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ। WireGuard ਆਮ ਤੌਰ 'ਤੇ UDP 51820 ਲੈਂਦਾ ਹੈ, OpenVPN UDP 1194 ਜਾਂ TCP 443 ਲੈਂਦਾ ਹੈ, ਅਤੇ ਵੈੱਬ ਸਰਵਰ TCP 443 ਲੈਂਦਾ ਹੈ। ਦੁਖਦੀ ਜੋੜੀ HTTPS ਦੇ ਕੋਲ TCP 443 'ਤੇ OpenVPN ਹੈ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਇੱਕੋ ਸਾਕਟ ਚਾਹੁੰਦੇ ਹਨ ਅਤੇ ਕਰਨਲ ਇਹ ਪਹਿਲਾਂ ਬਾਈਂਡ ਕਰਨ ਵਾਲੇ ਨੂੰ ਦਿੰਦਾ ਹੈ। ਸਿਰਫ਼ ਅੱਗੇ ਵਾਲਾ ਡੀਮਲਟੀਪਲੈਕਸਰ, ਜਿਵੇਂ sslh ਜਾਂ TLS ਸਮਝਣ ਵਾਲਾ ਪ੍ਰਾਕਸੀ, ਉਨ੍ਹਾਂ ਨੂੰ ਇਹ ਪੋਰਟ ਸਾਂਝਾ ਕਰਨ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਅਜਿਹਾ ਹਿੱਸਾ ਜੋੜਦਾ ਹੈ ਜਿਸਦੀ ਨਾਕਾਮੀ ਫਾਇਰਵਾਲ ਸਮੱਸਿਆ ਵਰਗੀ ਦਿਸਦੀ ਹੈ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕਾਂ ਵੱਲ ਦੇਖੋ: ss -lntup ਹਰ ਸੁਣਦੇ ਸਾਕਟ ਦਾ ਸਥਾਨਕ ਪਤਾ, ਪੋਰਟ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਛਾਪਦਾ ਹੈ। ਦਿਖਾਉਣ ਵਾਲੀਆਂ ਦੋ ਲਾਈਨਾਂ 0.0.0.0:443 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦੂਜੀ ਸੇਵਾ ਕਦੇ ਬਾਈਂਡ ਨਹੀਂ ਹੋਈ, ਭਾਵੇਂ ਉਸਦੀ init ਸਕ੍ਰਿਪਟ ਕਿੰਨੀ ਵੀ ਖ਼ੁਸ਼ ਹੋਵੇ। ਬ੍ਰਿਜਿੰਗ ਵੀ ਮਾਲਕ ਨੂੰ ਹਿਲਾਉਂਦੀ ਹੈ। ਜਦੋਂ eth0 ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ br0 ਤਾਂ IP br0 'ਤੇ ਚਲਾ ਜਾਂਦਾ ਹੈ ਅਤੇ eth0 ਦਾ ਨਾਮ ਲੈਣ ਵਾਲਾ ਹਰ ਫਾਇਰਵਾਲ ਨਿਯਮ ਮੇਲ ਖਾਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਸੇਵਾਵਾਂ ਨੂੰ ਬ੍ਰਿਜ 'ਤੇ ਬਾਈਂਡ ਕਰੋ ਅਤੇ ip -br addr ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ।

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

ਦੋ LAN ਵਿਚਕਾਰ ਰੂਟ ਕਰੋ ਜਾਂ ਇੱਕ ਪਾਸਾ NAT ਕਰੋ

ਜੋ ਦੋ LAN ਇੱਕ ਦੂਜੇ ਨੂੰ ਨਹੀਂ ਦੇਖਦੇ, ਉਹ ਦੋਵੇਂ ਜਨਤਕ ਹੋਸਟ ਨੂੰ ਡਾਇਲ ਕਰ ਸਕਦੇ ਹਨ, ਜੋ ਫਿਰ ਟਨਲਾਂ ਵਿਚਕਾਰ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ। ਇਸ ਰੂਟਡ ਡਿਜ਼ਾਈਨ ਲਈ ਤਿੰਨ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ, ਹਰ ਦੂਰਲੇ ਪ੍ਰੀਫਿਕਸ ਵੱਲ ਰੂਟ, ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਨੀਤੀ ਜੋ ਟਰਾਂਜ਼ਿਟ ਲੰਘਣ ਦਿੰਦੀ ਹੈ। sysctl -w net.ipv4.ip_forward=1 ਪਹਿਲੀ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ip route add 10.20.0.0/24 dev wg1 ਦੂਜੀ ਨੂੰ, ਅਤੇ nftables ਦੀ ਲਾਈਨ ਜਿਵੇਂ nft add rule inet filter forward iifname "wg0" oifname "wg1" accept ਤੀਜੀ ਨੂੰ।

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

ਲੈਪਟਾਪ ਲਈ ਇੰਟਰਨੈੱਟ ਐਗਜ਼ਿਟ ਵਜੋਂ ਕੰਮ ਕਰਨਾ ਉਸੇ ਬਾਕਸ ਨੂੰ ਆਉਂਦੀਆਂ ਟਨਲਾਂ ਖ਼ਤਮ ਕਰਨ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ। ਸਿਰਫ਼ ਓਵਰਲੈਪਿੰਗ ਪਤੇ ਹੀ ਰੋਕਦੇ ਹਨ, ਅਤੇ ਇਸੇ ਲਈ ਪਤਾ ਯੋਜਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਦਸਤਾਵੇਜ਼ ਹੈ।

ਦੋ ਭੂਮਿਕਾਵਾਂ ਬੰਦ ਹੋਣ 'ਤੇ ਵੰਡ ਦੀ ਜਾਂਚ ਕਰੋ

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

ਤਿੰਨ ਕਮਾਂਡਾਂ ਉਸ ਜਾਂਚ ਨੂੰ ਠੋਸ ਬਣਾਉਂਦੀਆਂ ਹਨ। curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਥਾਨਕ ਸਰੋਤਾ ਬਾਹਰੀ DNS ਤੋਂ ਬਿਨਾਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, wg show ਕਲਾਇੰਟ 'ਤੇ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਹੋਇਆ, ਅਤੇ tcpdump -ni any port 51820 ਹੱਬ 'ਤੇ ਰੂਟਿੰਗ ਸਮੱਸਿਆ ਨੂੰ ਕੁੰਜੀ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਕੈਪਚਰ ਵਿੱਚ ਕਦੇ ਨਾ ਦਿਸਣ ਵਾਲਾ ਹੈਂਡਸ਼ੇਕ ਹੋਸਟ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਮਰ ਗਿਆ: ਪ੍ਰਦਾਤਾ ਦਾ ਫਾਇਰਵਾਲ, ਗ਼ਲਤ ਜਨਤਕ ਪਤਾ ਜਾਂ ਰਾਹ ਵਿੱਚ NAT ਨਿਯਮ।

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

ਭੂਮਿਕਾਵਾਂ ਘਟਾਉਂਦੇ ਸਮੇਂ ਨਿਯਮ ਸਮੂਹ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ। nft list ruleset ਨੂੰ ਹਰ ਉਸ ਦਿਸ਼ਾ ਲਈ ਇੱਕ ਮਨਜ਼ੂਰੀ ਨਿਯਮ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਸਭ ਕੁਝ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲੀ ਫਾਰਵਰਡ ਚੇਨ ਵੱਖਰਾਪਣ ਨਹੀਂ, ਉਹ ਚੱਲਦਾ ਡੈਮੋ ਹੈ।

ਸਿਰਫ਼ IPv6 ਪਹੁੰਚ ਲਾਈਨਾਂ ਅਤੇ IPv4 ਸੇਵਾਵਾਂ

ਕੁਝ ਪਹੁੰਚ ਲਾਈਨਾਂ ਸਿਰਫ਼ IPv6 ਪਹੁੰਚ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਸੇਵਾਵਾਂ ਅਜੇ ਵੀ IPv4 ਉੱਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ ਹਨ। ਟਨਲ ਆਪ ਅਜੇ ਵੀ ਟ੍ਰੈਫਿਕ ਲੰਘਾਉਣ ਵਾਲੇ ਪਰਿਵਾਰ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਪ੍ਰਕਾਸ਼ਿਤ ਸੇਵਾ ਟਨਲ ਦੇ ਅੰਦਰਲੇ ਪਤੇ 'ਤੇ ਬੈਠਦੀ ਹੈ। ਇਹ ਆਮ ਧਾਰਨਾ ਨੂੰ ਉਲਟਾਉਂਦਾ ਹੈ ਅਤੇ ਨਿਗਰਾਨੀ ਨੂੰ ਚੁੱਪਚਾਪ ਤੋੜਦਾ ਹੈ: IPv4 ਰਾਹ ਲਈ ਲਿਖਿਆ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜਾਂ ਅਪਟਾਈਮ ਜਾਂਚ ਹੁਣ ਅਜਿਹੇ ਇੰਟਰਫੇਸ ਨੂੰ ਦੇਖਦੀ ਹੈ ਜੋ ਕੁਝ ਨਹੀਂ ਢੋਂਦਾ।

ਹਰ ਪਰਿਵਾਰ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ curl -4 ਅਤੇ curl -6 ਨਾਲ, ਕਿਉਂਕਿ ਇੱਕ ਸਫਲ ਬੇਨਤੀ ਉਸ ਰਾਹ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਅਜ਼ਮਾਇਆ। ਪੋਰਟ ਦੀ ਮਾਲਕੀ ਪਰਿਵਾਰਾਂ ਵਿਚਕਾਰ ਨਹੀਂ ਬਦਲਦੀ, ਪਰ ਸਰੋਤਾ ਬਦਲਦਾ ਹੈ: ss -lntup IPv4 ਅਤੇ IPv6 ਸਾਕਟਾਂ ਨੂੰ ਵੱਖਰੀਆਂ ਲਾਈਨਾਂ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ 0.0.0.0:443 ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ [::]:443 ਜਦੋਂ ਤੱਕ ਪ੍ਰਕਿਰਿਆ ਨੇ dual-stack ਸਾਕਟ ਨਾ ਮੰਗਿਆ ਹੋਵੇ।

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