ਦੋ ਸੈਲੂਲਰ ਸਾਈਟਾਂ, ਕੋਈ ਇਨਬਾਊਂਡ ਪੋਰਟ ਨਹੀਂ: ਕੰਮ ਕਰਨ ਵਾਲਾ ਹੱਬ ਬਣਾਓ

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

ਕਿਸੇ ਵੀ ਸਾਈਟ ਨੂੰ ਡਾਇਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਇਸ ਲਈ ਦੋਵਾਂ ਨੂੰ ਬਾਹਰ ਡਾਇਲ ਕਰਨਾ ਪਵੇਗਾ

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

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

ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਦੀ ਸਾਈਟ ਦੇ ਪਤੇ ਵਾਲੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੋ ਕਮਾਂਡ ਦਿੰਦੀਆਂ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਸਾਈਟ ਦੇ ਰਾਊਟਰ 'ਤੇ ਚਲਾਓ, ਇਸ ਦੇ ਪਿੱਛੇ ਵਾਲੇ ਲੈਪਟਾਪ 'ਤੇ ਨਹੀਂ:

ip -4 addr show scope global
ip -6 addr show scope global

ਕੌਣ ਪੀਅਰਾਂ ਦੀ ਜਾਣ-ਪਛਾਣ ਕਰਾਉਂਦਾ ਹੈ ਅਤੇ ਕੌਣ ਪੈਕਟ ਢੋਂਦਾ ਹੈ

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

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

ਹਰ ਸਾਈਟ ਲਈ ਇੱਕ ਰੂਟ, ਪੀਅਰ ਦੀ ਮਾਲਕੀ ਵਿੱਚ

ਹੱਬ ਨੂੰ ਹਰ ਸਾਈਟ ਲਈ ਇੱਕ ਟਨਲ, ਹਰ ਇੱਕ ਦੇ ਪਿੱਛੇ ਵੱਖਰਾ LAN ਪ੍ਰੀਫ਼ਿਕਸ, ਅਤੇ ਹਰ ਪ੍ਰੀਫ਼ਿਕਸ ਲਈ ਮਾਲਕ ਦਾ ਨਾਮ ਦੱਸਣ ਵਾਲਾ ਰੂਟ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਿੱਚ ਹੱਬ 10.61.0.1 ਹੈ, ਸਾਈਟ A ਉਹ ਹੈ ਜਿਸਦਾ LAN 10.60.10.0/24 ਵਾਲਾ 10.61.0.11 ਹੈ, ਅਤੇ ਸਾਈਟ B ਉਹ ਹੈ ਜਿਸਦਾ LAN 10.60.20.0/24 ਵਾਲਾ 10.61.0.12 ਹੈ। ਹੇਠਾਂ ਦਾ ਹਰ ਰੂਟ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਵੱਲ ਨਹੀਂ, ਪ੍ਰੀਫ਼ਿਕਸ ਵਾਲੇ ਪੀਅਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

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

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

ਹਰ ਮੈਪਿੰਗ ਨੂੰ ਓਪਰੇਟਰ ਰਾਹੀਂ ਜੀਵਿਤ ਰੱਖੋ

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

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

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

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਸਾਬਤ ਕਰੋ, ਫਿਰ ਬਹਾਲੀ ਸਾਬਤ ਕਰੋ

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

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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