WireGuard ਹੈਂਡਸ਼ੇਕ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਇੰਟਰਨੈਟ ਨਹੀਂ: ਪੈਕੇਟ ਟਰੇਸ ਕਰੋ
ਹੈਂਡਸ਼ੇਕ ਸਿਰਫ਼ ਕੁੰਜੀਆਂ ਅਤੇ ਪਹੁੰਚ ਸਾਬਤ ਕਰਦਾ ਹੈ। AllowedIPs ਤੋਂ ਫਾਰਵਰਡਿੰਗ, NAT ਅਤੇ ਵਾਪਸੀ ਰੂਟ ਰਾਹੀਂ ਇੱਕ ਪੈਕੇਟ ਟਰੇਸ ਕਰੋ ਅਤੇ ਵੇਖੋ ਇਹ ਕਿੱਥੇ ਰੁਕਦਾ ਹੈ।
ਟਨਲ ਚਾਲੂ ਹੈ, wg show ਹਾਲੀਆ ਹੈਂਡਸ਼ੇਕ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਤੁਸੀਂ ਸਰਵਰ ਦੇ ਟਨਲ ਪਤੇ ਨੂੰ ਪਿੰਗ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਇਸ ਤੋਂ ਅੱਗੇ ਕੁਝ ਵੀ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ। ਪਹਿਲੀ ਪ੍ਰਵਿਰਤੀ ਕੁੰਜੀਆਂ ਦੁਬਾਰਾ ਬਣਾਉਣ ਜਾਂ ਕਾਨਫਿਗ ਦੁਬਾਰਾ ਸਾਂਝਾ ਕਰਨ ਦੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਠੀਕ ਉਸੇ ਹਿੱਸੇ ਨੂੰ ਬਦਲਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਦਾ ਸਾਬਤ ਹੋ ਚੁੱਕਾ ਹੈ।
ਪੂਰਾ ਹੋਇਆ ਹੈਂਡਸ਼ੇਕ ਕਹਿੰਦਾ ਹੈ ਕਿ ਦੋਵੇਂ ਧਿਰਾਂ ਕੁੰਜੀਆਂ ’ਤੇ ਸਹਿਮਤ ਹਨ, UDP ਅੰਤ ਬਿੰਦੂ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਕ੍ਰਿਪਟੋ ਰੂਟਿੰਗ ਪੈਕੇਟ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ। ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਪੈਕੇਟ ਬਾਅਦ ਵਿੱਚ ਸਰਵਰ ਛੱਡ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇਸ ਲਈ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਬਜਾਏ ਇੱਕ ਪੈਕੇਟ ਟਰੇਸ ਕਰੋ। ਚਾਰ ਥਾਵਾਂ ਹਨ ਜਿੱਥੇ ਇਹ ਮਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਵੱਖਰਾ ਨਿਸ਼ਾਨ ਛੱਡਦੀ ਹੈ।
ਹੈਂਡਸ਼ੇਕ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ
WireGuard ਇੱਕ UDP ਪ੍ਰੋਟੋਕਾਲ ਹੈ ਜੋ Noise ਹੈਂਡਸ਼ੇਕ ਨਾਲ ਸੈਸ਼ਨ ਸਥਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਸਾਥੀ ਲਈ ਪੈਕੇਟ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ। ਜਦੋਂ wg show ਕੁਝ ਸਕਿੰਟ ਪੁਰਾਣਾ ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਵਧਦਾ ਟ੍ਰਾਂਸਫਰ ਕਾਊਂਟਰ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਅੰਤ ਬਿੰਦੂ, ਕੁੰਜੀਆਂ ਅਤੇ ਸਾਥੀ ਦੀ ਜਨਤਕ ਕੁੰਜੀ ਸਭ ਸਹੀ ਹਨ।
ਜੋ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਉਹ ਹੈ: ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਇੰਟਰਨੈਟ ਵੱਲ ਜਾਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਇੰਟਰਫੇਸ ਵਿੱਚ ਭੇਜਦਾ ਹੈ ਵੀ ਜਾਂ ਨਹੀਂ, ਸਰਵਰ ਇਸਨੂੰ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ ਜਾਂ ਨਹੀਂ, ਜਾਂ ਜਵਾਬ ਵਾਪਸੀ ਦਾ ਰਾਹ ਲੱਭ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਹ ਕਰਨਲ ਰੂਟਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਦੇ ਫੈਸਲੇ ਹਨ, ਅਤੇ ਇਹ ਟਨਲ ਤੋਂ ਬਾਹਰ ਲਏ ਜਾਂਦੇ ਹਨ।
ਸਰਵਰ ਦੇ ਟਨਲ ਪਤੇ ਨੂੰ ਪਿੰਗ ਕਰਨਾ ਇੰਨਾ ਭਰਮਾਊ ਟੈਸਟ ਹੋਣ ਦਾ ਕਾਰਨ ਇਹੀ ਹੈ। ਉਹ ਪੈਕੇਟ ਸਰਵਰ ਨੂੰ ਹੀ ਸੰਬੋਧਿਤ, ਇਸ ਲਈ ਇਹ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ। ਇਸਨੂੰ ਕਦੇ ਫਾਰਵਰਡਿੰਗ, ਕਦੇ ਅਨੁਵਾਦ ਅਤੇ ਕਦੇ ਇੰਟਰਨੈਟ ਤੋਂ ਵਾਪਸੀ ਰੂਟ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ।
AllowedIPs ਇੱਕ ਰੂਟਿੰਗ ਫੈਸਲਾ ਹੈ
ਕਲਾਇੰਟ ’ਤੇ AllowedIPs ਦੋ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ ਕ੍ਰਿਪਟੋਕੁੰਜੀ ਰੂਟਿੰਗ ਟੇਬਲ ਹੈ ਜੋ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਮੰਜ਼ਿਲ ਪਤੇ ਇਸ ਸਾਥੀ ਦੇ ਟਨਲ ਵਿੱਚ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇਹ ਸਰੋਤ ਪਤਿਆਂ ਦੀ ਸੂਚੀ ਹੈ ਜੋ ਸਾਥੀ ਤੁਹਾਡੇ ਤੋਂ ਸਵੀਕਾਰ ਕਰੇਗਾ। ਜੇ ਕਲਾਇੰਟ ਕਾਨਫਿਗ ਵਿੱਚ ਸਿਰਫ਼ 10.8.0.0/24 ਹੈ, ਤਾਂ ਜਨਤਕ ਮੰਜ਼ਿਲਾਂ ਕਦੇ ਇੰਟਰਫੇਸ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੀਆਂ ਅਤੇ ਤੁਹਾਡਾ ਆਮ ਡਿਫਾਲਟ ਰੂਟ ਉਹਨਾਂ ਨੂੰ ਟਨਲ ਤੋਂ ਬਾਹਰ ਲੈ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਟਨਲ ਬਿਲਕੁਲ ਠੀਕ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਚਾਹੀ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਕਰਦਾ।
ਕਾਨਫਿਗ ਫਾਈਲ ਕੀ ਕਹਿੰਦੀ ਹੈ ਦੀ ਬਜਾਏ ਵੇਖੋ ਕਲਾਇੰਟ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਇੰਸਟਾਲ ਕੀਤਾ:
wg show wg0 allowed-ipsip route get 1.1.1.1
ਦੂਜਾ ਕਮਾਂਡ ਨਿਰਣਾਇਕ ਹੈ। ਜੇ ਜਵਾਬ ਤੁਹਾਡਾ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਅਤੇ ਆਮ ਗੇਟਵੇ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਪੈਕੇਟ ਟਨਲ ਵਿੱਚੋਂ ਨਹੀਂ ਜਾ ਰਿਹਾ ਅਤੇ ਸਰਵਰ ਪਾਸੇ ਦਾ ਕੋਈ ਬਦਲਾਅ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ। IPv4 ਲਈ 0.0.0.0/0 ਅਤੇ IPv6 ਲਈ ::/0 ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਸ਼ਾਮਲ ਕਰੋ; ਇੱਕ ਪਰਿਵਾਰ ਲਈ ਸਭ ਕੁਝ ਫੜਨ ਵਾਲਾ ਨਿਯਮ ਦੂਜੇ ਨੂੰ ਇਸਦੇ ਮੂਲ ਰਾਹ ’ਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕੰਮ ਕਰਦੇ IPv4 ਟਨਲ ਅਤੇ ਅਟਕੇ IPv6 ਖੋਜ ਦਾ ਆਮ ਕਾਰਨ ਹੈ।
ਗੇਟਵੇ ’ਤੇ ਪੈਕੇਟ ਕਿੱਥੇ ਮਰਦਾ ਹੈ
ਜੇ ਰੂਟ ਸਹੀ ਹੈ ਅਤੇ ਪੈਕੇਟ ਫਿਰ ਵੀ ਕਿਤੇ ਨਹੀਂ ਜਾਂਦਾ, ਤਾਂ ਇਹ ਸਰਵਰ ’ਤੇ ਪਹੁੰਚ ਕੇ ਉੱਥੇ ਹੀ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਚਾਰ ਜਾਂਚਾਂ ਜ਼ਿਆਦਾਤਰ ਗੇਟਵੇ ਕਵਰ ਕਰ ਲੈਂਦੀਆਂ ਹਨ।
ਫਾਰਵਰਡਿੰਗ। sysctl net.ipv4.ip_forward ਦਾ 0 ਵਾਪਸ ਕਰਨਾ ਕਲਾਸਿਕ ਜਵਾਬ ਹੈ, ਅਤੇ ਕਈ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਅਜੇ ਵੀ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ 0 ’ਤੇ ਹਨ। ਇਹ 1 ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਰੀਬੂਟ ’ਤੇ ਗਾਇਬ ਹੋਣ ਵਾਲੇ ਕਮਾਂਡ ਦੀ ਬਜਾਏ sysctl ਫਾਈਲ ਵਿੱਚ ਸਥਾਈ ਤੌਰ ’ਤੇ ਸੈੱਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। IPv6 ਫਾਰਵਰਡਿੰਗ ਵੱਖਰਾ ਸਵਿੱਚ ਹੈ।
ਫਿਲਟਰ ਨੀਤੀ। ਡਿਫਾਲਟ drop ਨੀਤੀ ਵਾਲੀ FORWARD ਚੇਨ ਟਨਲ ਦਾ ਟ੍ਰੈਫਿਕ ਸੁੱਟ ਦੇਵੇਗੀ ਪਰ ਹੋਸਟ ਆਪਣੇ ਵੱਲ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਵੇਗੀ, ਜੋ ਲੱਛਣ ਨਾਲ ਬਿਲਕੁਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਸੰਭਾਲੀ ਫਾਈਲ ਨਹੀਂ, ਜੀਵਤ ਨਿਯਮ-ਸਮੂਹ ਪੜ੍ਹੋ: nft list ruleset ਜਾਂ iptables -S।
ਅਨੁਵਾਦ ਜਾਂ ਰੂਟਿੰਗ। ਨਿੱਜੀ ਟਨਲ ਪਤੇ ਵਰਤਣ ਵਾਲੇ ਕਲਾਇੰਟ ਨੂੰ ਜਾਂ ਤਾਂ ਸਰਵਰ ਦੇ ਨਿਕਾਸ ਇੰਟਰਫੇਸ ’ਤੇ ਸਰੋਤ NAT ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਅਜਿਹਾ ਰੂਟ ਕੀਤਾ ਪ੍ਰੀਫਿਕਸ ਜਿਸਨੂੰ ਉੱਪਰਲਾ ਨੈੱਟਵਰਕ ਵਾਪਸ ਭੇਜਣਾ ਜਾਣਦਾ ਹੋਵੇ। ਦੋਨਾਂ ਵਿਚਕਾਰ ਚੋਣ ਪਤਾ ਯੋਜਨਾ ਦੇ ਅਨੁਸਾਰ ਹੁੰਦੀ ਹੈ। ਜਿਸ ਨੈੱਟਵਰਕ ਵਿੱਚ ਤੁਹਾਡਾ ਪ੍ਰੀਫਿਕਸ ਪਹਿਲਾਂ ਹੀ ਵਾਪਸ ਰੂਟ ਹੁੰਦਾ ਹੈ ਉੱਥੇ MASQUERADE ਜੋੜਨਾ ਨੁਕਸਾਨਦੇਹ ਨਹੀਂ ਪਰ ਬੇਮਤਲਬ ਹੈ, ਅਤੇ ਜਿੱਥੇ ਕੋਈ ਰੂਟ ਨਹੀਂ ਉੱਥੇ ਇਸਨੂੰ ਛੱਡ ਦੇਣ ਨਾਲ ਜਵਾਬ ਗੈਰ-ਰੂਟਯੋਗ ਨਿੱਜੀ ਰੇਂਜ ਵੱਲ ਸੰਬੋਧਿਤ ਰਹਿੰਦੇ ਹਨ।
ਵਾਪਸੀ ਰਾਹ। ਰੂਟ ਕੀਤੇ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚ ਉੱਪਰਲੇ ਰਾਊਟਰ ਨੂੰ ਤੁਹਾਡੇ ਸਰਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਰੂਟ ਚਾਹੀਦਾ ਹੈ। ਪ੍ਰਦਾਤਾ ਦਾ ਨੈੱਟਵਰਕ ਵੀ ਇਸਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ: ਕਈ ਕਲਾਊਡ ਇੰਸਟੈਂਸ ’ਤੇ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਜਾਂਚ ਸਰਗਰਮ ਕਰਦੇ ਹਨ, ਜੋ ਉਹਨਾਂ ਪੈਕੇਟਾਂ ਨੂੰ ਚੁੱਪਚਾਪ ਸੁੱਟ ਦਿੰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਸਰੋਤ ਇੰਸਟੈਂਸ ਦਾ ਆਪਣਾ ਪਤਾ ਨਹੀਂ, ਜਦੋਂ ਤੱਕ ਉਹ ਜਾਂਚ ਬੰਦ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।
DNS ਰੂਟਿੰਗ ਨਾਲੋਂ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਫੇਲ ਹੁੰਦਾ ਹੈ
ਜਾਣੇ ਪਤੇ ’ਤੇ ਪੈਕੇਟ ਅਤੇ ਨਾਮ ਦੀ ਖੋਜ ਦੋ ਵੱਖਰੀਆਂ ਅਸਫਲਤਾਵਾਂ ਹਨ, ਅਤੇ ਗਲਤੀ ਸੁਨੇਹੇ ਉਲਟ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਭਰਮਾਉਂਦੇ ਹਨ। ਜੇ ping 1.1.1.1 ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਕੁਝ ਵੀ ਲੋਡ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਰੂਟ ਠੀਕ ਹੈ ਅਤੇ ਨਾਮ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਨਹੀਂ। ਜੇ ਪਿੰਗ ਆਪ ਹੀ ਫੇਲ ਹੋਵੇ, ਤਾਂ DNS ਅਪ੍ਰਸੰਗਿਕ ਹੈ ਅਤੇ ਤੁਸੀਂ ਪਿਛਲੇ ਹਿੱਸੇ ’ਤੇ ਵਾਪਸ ਆ ਗਏ ਹੋ।
wg-quick ਕਾਨਫਿਗ ਦੀ DNS = ਲਾਈਨ ਤੋਂ ਰਿਜ਼ੌਲਵਰ ਸੈੱਟ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ systemd-resolved ਦਾ ਹਰ ਲਿੰਕ ਲਈ ਆਪਣਾ ਵਿਵਹਾਰ ਹੈ। ਜੋ VPN ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਸਿਰਫ਼ ਟਨਲ ਦੇ ਅੰਦਰ ਪਹੁੰਚ ਵਾਲੇ ਪਤੇ ਨਾਲ ਬਦਲਦਾ ਹੈ, ਉਹ ਟਨਲ ਡਿੱਗਦੇ ਹੀ ਹਰ ਖੋਜ ਫੇਲ ਕਰ ਦੇਵੇਗਾ, ਜੋ ਇੰਝ ਲੱਗਦਾ ਹੈ ਕਿ ਟਨਲ ਹੀ ਇੰਟਰਨੈਟ ਤੋੜ ਰਿਹਾ ਹੈ।
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
ਸਬੂਤ ਦੇਣ ਵਾਲਾ ਕ੍ਰਮ
ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਪਾਸੇ ਦੀ ਜਾਂਚ ਚਲਾਓ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਕਮਾਂਡ ਹੈ ਅਤੇ ਅੱਧੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰਵਰ ਇੰਟਰਨੈਟ ਨਿਕਾਸ ਵਜੋਂ ਬਣਾਇਆ ਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ; ਨਿੱਜੀ ਪਹੁੰਚ ਲਈ ਬਣਾਇਆ ਗੇਟਵੇ ਜਨਤਕ ਮੰਜ਼ਿਲਾਂ ਫੇਲ ਹੋਣ ’ਤੇ ਟੁੱਟਿਆ ਨਹੀਂ ਹੁੰਦਾ।
ਸਰਵਰ ’ਤੇ, ਕਲਾਇੰਟ ਤੋਂ ਪਿੰਗ ਭੇਜਦੇ ਸਮੇਂ ਇੰਟਰਫੇਸ ਵੇਖੋ: tcpdump -ni wg0 icmp ਨੇ ਬੇਨਤੀ ਦਿਖਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ tcpdump -ni eth0 icmp ਨੇ ਇਸਦੇ ਬਾਹਰ ਜਾਣਾ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਨੁਵਾਦਿਤ ਹੋਵੇ ਜਾਂ ਨਾ। ਜੇ ਇਹ ਪਹਿਲੇ ’ਤੇ ਦਿਸੇ ਅਤੇ ਦੂਜੇ ’ਤੇ ਕਦੇ ਨਾ ਦਿਸੇ, ਤਾਂ ਰੁਕਣਾ ਸਰਵਰ ’ਤੇ ਹੀ ਸਥਾਨਕ ਹੈ। ਜੇ ਇਹ ਬਾਹਰ ਜਾਵੇ ਅਤੇ ਕੋਈ ਜਵਾਬ ਵਾਪਸ ਨਾ ਆਵੇ, ਤਾਂ ਸਮੱਸਿਆ ਉੱਪਰ ਹੈ, ਅਤੇ ਉਹ ਵੱਖਰੀ ਗੱਲ ਹੈ।
ਅੰਤ ਵਿੱਚ ਸੁਧਾਰ ਨੂੰ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਵੀ ਟਿਕਣ ਵਾਲਾ ਬਣਾਓ। ਫਾਰਵਰਡਿੰਗ sysctl ਫਾਈਲ ਵਿੱਚ, ਫਾਇਰਵਾਲ ਨਿਯਮ ਉਹਨਾਂ ਨੂੰ ਲੋਡ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਵਿੱਚ, ਅਤੇ ਕਲਾਇੰਟ ਰੂਟ ਇੰਟਰਫੇਸ ਚੁੱਕਣ ਵਾਲੀ ਕਾਨਫਿਗ ਵਿੱਚ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਤੁਹਾਡੇ ਭੁੱਲਣ ਵਾਲੇ ਸ਼ੈੱਲ ਵਿੱਚ ਨਹੀਂ। ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰੋ, ਉਹੀ ਦੋ ਟੈਸਟ ਦੁਹਰਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਾਊਂਟਰ ਚੱਲ ਰਹੇ ਹਨ।