PPTP ਅਤੇ L2TP/IPsec ਵਰਤੋਂਕਾਰ ਨਾਮ ਦੀ ਪੁੱਛ ਤੋਂ ਪਹਿਲਾਂ ਕਿਉਂ ਰੁਕਦੇ ਹਨ?
ਵਰਤੋਂਕਾਰ ਨਾਮ ਦੀ ਪੁੱਛ ਨਾ ਆਉਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ PPP ਕਦੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ, ਇਸ ਲਈ ਖਰਾਬੀ ਟਰਾਂਸਪੋਰਟ, ਕੁੰਜੀ ਬਦਲੀ ਜਾਂ ਟਨਲ ਸੈਟਅਪ ਵਿੱਚ ਹੈ। ਦੁਬਾਰਾ ਇੰਸਟਾਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੜਾਵਾਂ ਦਾ ਕ੍ਰਮ ਜਾਂਚੋ।
ਵਰਤੋਂਕਾਰ ਨਾਮ ਦੀ ਪੁੱਛ ਨਾ ਆਉਣਾ ਇੱਕ ਨਿਦਾਨ ਦਾ ਤੋਹਫ਼ਾ ਹੈ: PPP ਅਜੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ, ਇਸ ਲਈ ਖਾਤਾ, ਪਾਸਵਰਡ ਅਤੇ ਡੋਮੇਨ ਨੀਤੀ ਅਜੇ ਪੁੱਛੀ ਨਹੀਂ ਗਈ। PPTP ਜਾਂ L2TP/IPsec ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣ ਪੱਤਰ ਤਾਂ ਹੀ ਮੰਗਦਾ ਹੈ, ਜਦੋਂ ਟਨਲ ਮੌਜੂਦ ਹੋਵੇ ਅਤੇ ਸਰਵਰ ਨੇ PPP ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕੀਤਾ ਹੋਵੇ। ਉਸ ਪਲ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਕੁਝ ਵੀ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ ਉਹ ਟਰਾਂਸਪੋਰਟ, ਕੁੰਜੀ ਬਦਲੀ ਜਾਂ ਟਨਲ ਸੈਟਅਪ ਹੈ, ਜੋ «VPN ਖਰਾਬ ਹੈ» ਤੋਂ ਬਹੁਤ ਛੋਟਾ ਖੇਤਰ ਹੈ।
ਗੁੰਮ ਪੁੱਛ ਖਰਾਬੀ ਨੂੰ ਤਿੰਨ ਪੜਾਵਾਂ ਤੱਕ ਸੀਮਤ ਕਰਦੀ ਹੈ
ਦਿਸਣ ਵਾਲਾ ਆਖਰੀ ਸਫਲ ਪੜਾਅ ਲਿਖ ਲਓ, ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਦਾ ਮਾਲਕ ਅਤੇ ਹੱਲ ਵੱਖਰਾ ਹੈ। ਦੋ ਪੜਾਅ ਪਹਿਲਾਂ ਅਟਕੇ ਹੋਣ ਵੇਲੇ ਖਾਤੇ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਦੁਪਹਿਰ ਕਿਵੇਂ ਗੁਆਚ ਜਾਂਦੀ ਹੈ ਦਾ ਤਰੀਕਾ ਹੈ।
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
ਪੁੱਛ ਤੋਂ ਬਿਨਾਂ ਸਮਾਂ ਖਤਮ ਹੋਣ ਵਾਲੇ ਕਲਾਇੰਟ ਨੂੰ ਕਦੇ IPsec ਸੰਗਠਨ ਨਹੀਂ ਮਿਲਿਆ, ਇਸ ਲਈ ਖਰਾਬੀ IKE ਵਿੱਚ ਹੈ ਜਾਂ ਇਸ ਵਿੱਚ ਕਿ ਤੁਹਾਡੇ ਪੈਕਟ ਗੇਟਵੇ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਜੋ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣ ਪੱਤਰ ਜਾਂਚਣ ਦੀ ਸੂਚਨਾ ਦੇ ਕੇ ਫਿਰ ਡਿੱਗਦਾ ਹੈ, ਉਹ ਸੁਨੇਹੇ ਦੇ ਸੰਕੇਤ ਤੋਂ ਅੱਗੇ ਗਿਆ ਸੀ। ਪੁੱਛ ਤੋਂ ਬਾਅਦ ਇਨਕਾਰ ਆਉਣਾ PPP ਪ੍ਰਮਾਣੀਕਰਨ ਹੈ, ਅਤੇ ਉਸ ਦੀ ਥਾਂ ਖਾਤੇ ਬਾਰੇ ਲੇਖ ਵਿੱਚ ਹੈ, ਇਸ ਲੇਖ ਵਿੱਚ ਨਹੀਂ।
ਪਹਿਲਾ ਪੜਾਅ: ਉਹ ਪ੍ਰੋਟੋਕੋਲ ਜਿਸਨੂੰ ਫਾਇਰਵਾਲ ਚੁੱਪਚਾਪ ਸੁੱਟ ਦਿੰਦਾ ਹੈ
PPTP ਨੂੰ ਆਪਣੇ ਕੰਟਰੋਲ ਚੈਨਲ ਲਈ TCP 1723 ਅਤੇ ਡੇਟਾ ਰਾਹ ਲਈ IP ਪ੍ਰੋਟੋਕੋਲ 47 ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਵੱਖਰੇ ਸਫ਼ਰ ਕਰਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ ਨੈੱਟਵਰਕ 1723 ਅੱਗੇ ਭੇਜਦੇ ਹਨ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ 47 ਸੁੱਟ ਦਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਅਜਿਹਾ ਟਨਲ ਬਣਦਾ ਹੈ ਜੋ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਕੁਝ ਵੀ ਨਹੀਂ ਢੋਂਦਾ। NAT ਕਰਨ ਵਾਲੇ ਰਾਊਟਰ ਨੂੰ GRE-ਸਮਰਥਿਤ ਪਾਸ-ਥਰੂ ਵੀ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ IPv6 ਵਾਲਾ ਪਹੁੰਚ ਰਾਹ ਕਿਸੇ ਵੀ ਸੰਰਚਨਾ ਵਿੱਚ PPTP ਨਹੀਂ ਢੋ ਸਕਦਾ।
IPsec ਉੱਤੇ L2TP IKE ਲਈ ਪੋਰਟ 500 ਅਤੇ NAT ਲੰਘਣ ਲਈ ਪੋਰਟ 4500 ਖਰਚਦਾ ਹੈ, ਫਿਰ L2TP ਟ੍ਰੈਫਿਕ ਨੂੰ ਹੀ 1701 ਵਿੱਚ ਲਪੇਟਦਾ ਹੈ, ਅਤੇ ਸੰਗਠਨ ਬਣਨ ਤੋਂ ਬਾਅਦ ESP ਸੁਰੱਖਿਅਤ ਪੇਲੋਡ ਢੋਂਦਾ ਹੈ। ਦੋਵੇਂ ਕੰਟਰੋਲ ਪੋਰਟਾਂ ਦੀ ਆਗਿਆ ਦਿਓ ਪਰ ESP ਦੀ ਨਹੀਂ, ਅਤੇ ਤੁਹਾਨੂੰ ਠੀਕ ਸਿਰਲੇਖ ਵਾਲਾ ਲੱਛਣ ਮਿਲੇਗਾ: ਦਿਸਣ ਵਾਲੀ ਤਰੱਕੀ, ਫਿਰ ਕਿਸੇ ਵੀ ਪ੍ਰਮਾਣ ਪੱਤਰ ਸੰਵਾਦ ਤੋਂ ਪਹਿਲਾਂ ਮਰਿਆ ਕਲਾਇੰਟ। ਫੋਨ ਹਾਟਸਪਾਟ ਤੋਂ ਪਰਖਣਾ ਕਲਾਇੰਟ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਰਾਹ ਦੀ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਨ ਦਾ ਸਸਤਾ ਤਰੀਕਾ ਹੈ।
ਦੂਜਾ ਪੜਾਅ: ਜੋ ਕੁੰਜੀ ਕੁੰਜੀ ਨਹੀਂ, ਜੋ ਪੇਸ਼ਕਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ
ਨਾ ਮਿਲਦੀ ਪਹਿਲਾਂ-ਸਾਂਝੀ ਕੁੰਜੀ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਆਮ ਰੂਪ ਉਹ ਕੁੰਜੀ ਹੈ ਜੋ ਸਕ੍ਰੀਨ ਉੱਤੇ ਸਹੀ ਦਿਸਦੀ ਹੈ ਪਰ ਪੇਸਟ ਕੀਤਾ ਲਾਈਨ ਬ੍ਰੇਕ ਜਾਂ ਅੰਤ ਵਿੱਚ ਸਪੇਸ ਰੱਖਦੀ ਹੈ। Linux ਕਲਾਇੰਟ ਉੱਤੇ ਸੰਵਾਦ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਸੱਚ ਦਾ ਸਰੋਤ ਹੋਵੇ: NetworkManager ਦਾ L2TP ਪਲੱਗਇਨ ਭੇਦ /etc/ipsec.d/ ਹੇਠਲੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਅਤੇ /etc/ipsec.secrets ਹਾਲੇ ਵੀ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੀ ਪੁਰਾਣੀ ਪ੍ਰਤੀ-ਕਨੈਕਸ਼ਨ ਫਾਈਲ ਤੁਹਾਡੇ ਹੁਣੇ ਟਾਈਪ ਕੀਤੇ ਦੀ ਥਾਂ ਵਰਤੀ ਜਾਵੇਗੀ। ਉਹ ਫਾਈਲ ਸੁਰੱਖਿਅਤ ਥਾਂ ਤੇ ਕਾਪੀ ਕਰੋ, ਸ਼ਾਮਲ ਕਰਨ ਦੇ ਰਾਹ ਤੋਂ ਹਟਾਓ, ਅਤੇ ਫਿਰ ਕੁੰਜੀ ਹੱਥ ਨਾਲ ਦੁਬਾਰਾ ਟਾਈਪ ਕਰੋ।
ਇਸ ਪੜਾਅ ਦਾ ਦੂਜਾ ਅੱਧ ਪੇਸ਼ਕਸ਼ ਹੈ। ਦੋਵੇਂ ਸਿਰਿਆਂ ਨੂੰ ਇੱਕੋ 1ਲੇ ਪੜਾਅ ਦੇ ਐਲਗੋਰਿਦਮ ਸੈੱਟ — ਇਨਕ੍ਰਿਪਸ਼ਨ, ਅਖੰਡਤਾ ਅਤੇ Diffie-Hellman ਸਮੂਹ — ਅਤੇ 2ਲੇ ਪੜਾਅ ਲਈ ਮਿਲਦੇ ESP ਰੂਪਾਂਤਰਨਾਂ ਉੱਤੇ ਸਹਿਮਤ ਹੋਣਾ ਪਵੇਗਾ, ਨਹੀਂ ਤਾਂ ਸੰਗਠਨ ਬਣਦਾ ਹੀ ਨਹੀਂ। ਜੋ ਗੇਟਵੇ ਸਿਰਫ਼ 3DES, SHA1 ਅਤੇ MODP1024 ਦਿੰਦਾ ਹੈ ਉਹ ਮਜ਼ਬੂਤ ਐਲਗੋਰਿਦਮ ਲਈ ਸੈੱਟ ਕਲਾਇੰਟ ਨੂੰ ਇਨਕਾਰ ਕਰੇਗਾ, ਅਤੇ ਉਸ ਦਾ ਲਾਗ ਇਨਕਾਰ ਕੀਤੇ ਰੂਪਾਂਤਰਨ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ। ਸੇਵਾ ਦੁਬਾਰਾ ਚਾਲੂ ਕਰਨ ਦੀ ਥਾਂ ਲਾਗ ਪੜ੍ਹੋ ਤਾਂ ਲਾਗ ਹੀ ਅਸੰਗਤੀ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ। ਫੋਰਮ ਥ੍ਰੈਡ ਤੋਂ ਐਲਗੋਰਿਦਮ ਦੀ ਲੜੀ ਕਾਪੀ ਕਰਨ ਦੀ ਥਾਂ ਗੇਟਵੇ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਰੂਪਾਂਤਰਨਾਂ ਦੀ ਗੱਲਬਾਤ ਕਰੇਗਾ: ਉਸ ਦੇ ਪਤੇ ਵੱਲ ਤਾਕਿਆ ike-scan ਉਹ ਰੂਪਾਂਤਰਨ ਮੋੜਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਉਹ ਗੱਲਬਾਤ ਕਰੇਗਾ। ਜੇ ਇੱਕੋ ਪੇਸ਼ਕਸ਼ ਅਜਿਹੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਹੈ ਜਿਸ ਦੀ ਤੁਹਾਡੀ ਨੀਤੀ ਹੁਣ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੀ, ਤਾਂ ਸੁਧਾਰ ਗੇਟਵੇ ਉੱਤੇ ਹੈ, ਕਲਾਇੰਟ ਨੂੰ ਹੇਠਾਂ ਲਾਹੁਣ ਵਿੱਚ ਨਹੀਂ।
Windows ਵਿੱਚ ਕੁੰਜੀ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਢੰਗ VPN ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਅਸੰਗਤੀ ਪ੍ਰਮਾਣ ਪੱਤਰ ਦੀ ਪੁੱਛ ਤੋਂ ਪਹਿਲਾਂ ਦਿਸਦੀ ਹੈ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ। ਜਿੱਥੇ ਪ੍ਰਾਪਤਕਰਤਾ Windows Server ਹੈ, ਉੱਥੇ ਦੂਰਸਥ ਪਹੁੰਚ ਭੂਮਿਕਾ ਸਥਾਪਿਤ ਹੋਣ, ਪ੍ਰਮਾਣ ਪੱਤਰ ਉਸ ਨਾਮ ਨਾਲ ਮਿਲਣ ਜਿਸ ਉੱਤੇ ਕਲਾਇੰਟ ਜੁੜਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਪੋਰਟ ਫਿਲਟਰ ਉੱਪਰਲੇ ਪ੍ਰੋਟੋਕੋਲਾਂ ਤੋਂ ਸੰਕਰਾ ਨਾ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਤੀਜਾ ਪੜਾਅ: ਟਨਲ ਹੈ ਅਤੇ PPP ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ
IKE ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਪੁੱਛ ਨਾ ਆਵੇ ਤਾਂ ਫਾਇਰਵਾਲ ਨਹੀਂ, ਟਨਲ ਡੈਮਨ ਵੇਖੋ। L2TP ਨੂੰ UDP 1701 ਉੱਤੇ ਸੁਣਨ ਵਾਲਾ ਕੁਝ ਚਾਹੀਦਾ ਹੈ — Linux ਵਿੱਚ xl2tpd ਜਾਂ kl2tpd, Windows ਵਿੱਚ ਦੂਰਸਥ ਪਹੁੰਚ ਸੇਵਾ — ਅਤੇ ਸਥਾਪਿਤ ਪਰ ਬੰਦ ਸੇਵਾ ਕਲਾਇੰਟ ਵੱਲੋਂ ਸੁੱਟੇ ਪੈਕਟ ਵਾਂਗ ਹੀ ਦਿਸਦੀ ਹੈ। ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਂਚੇ ਨਿਯਮ ਦੁਬਾਰਾ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਸੁਣਨ ਵਾਲੇ ਦੀ ਜਾਂਚ ਕਰੋ। ਫਿਰ PPP ਨੇ ਗੱਲਬਾਤ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਪਹਿਲੀ LCP ਬਦਲੀ ਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਚੁੱਪ ਫੇਲ੍ਹ ਹੋਣਾ ਆਮ ਤੌਰ ਤੇ ਉੱਤਰਦਾ ਹੈ।
ਇਸ ਪੜਾਅ ਦਾ ਇੱਕ ਜਾਲ ਨੈੱਟਵਰਕ ਦੀ ਖਰਾਬੀ ਬਿਲਕੁਲ ਨਹੀਂ ਹੈ: Windows ਇੱਕ ਸਮੇਂ ਦਿੱਤੇ VPN ਕਿਸਮ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਕਨੈਕਸ਼ਨ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਦੂਜੀ ਕੋਸ਼ਿਸ਼ ਗਲਤੀ 937 ਦਿੰਦੀ ਹੈ, «ਇਸ ਕਿਸਮ ਦਾ ਦੂਜਾ ਕਨੈਕਸ਼ਨ ਵਰਤੋਂ ਵਿੱਚ ਹੈ»। ਇਹ ਸਥਾਨਕ ਨਿਯਮ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਬਚਣ ਦਾ ਰਾਹ ਦੂਜਾ ਯੰਤਰ, ਦੂਜੀ ਟਨਲ ਕਿਸਮ, ਜਾਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਇੱਕੋ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਹੈ।
ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਪੜਾਵਾਂ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਲਾਗ ਪੜ੍ਹੋ
ਕਲਾਇੰਟ ਬੰਦ ਕਰੋ, ਦੁਬਾਰਾ ਚਾਲੂ ਕਰੋ, ਅਤੇ ਹਿੱਸੇ ਉਸ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ ਜਿਸ ਵਿੱਚ ਉਹ ਲਾਗ ਲਿਖਦੇ ਹਨ। ਭਾਵ ਪਹਿਲਾਂ IPsec ਡੈਮਨ — strongSwan ਜਾਂ Libreswan, ਅਤੇ ipsec --version ਦੱਸਦਾ ਹੈ ਕਿਹੜਾ — ਫਿਰ L2TP ਡੈਮਨ, ਫਿਰ pppd। ਫੇਲ੍ਹ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਜਿਸ ਹਿੱਸੇ ਨੇ ਆਖਰੀ ਲਿਖਿਆ, ਉਹ ਜਾਂਚਣ ਵਾਲਾ ਪੜਾਅ ਦਰਸਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਕ੍ਰਮ ਵਿੱਚ ਉਸ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲਾ ਕੁਝ ਵੀ ਚੱਲਿਆ ਨਹੀਂ।
ਸੰਭਾਲੇ ਸੈਸ਼ਨ ਦੀ ਥਾਂ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਕੈਸ਼ ਤੋਂ ਦੁਬਾਰਾ ਜੁੜਨ ਵਾਲਾ ਕਲਾਇੰਟ ਬਦਲੀ ਦੇ ਹਿੱਸੇ ਛੱਡ ਕੇ ਪੁਰਾਣਾ ਨਤੀਜਾ ਦੁਹਰਾ ਸਕਦਾ ਹੈ। ਪਹੁੰਚ, ਕੁੰਜੀ ਬਦਲੀ, ਟਨਲ ਅਤੇ PPP ਇੱਕ-ਇੱਕ ਕਰਕੇ, ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰੋ। ਤਦ ਗੁੰਮ ਪੁੱਛ ਬੁਝਾਰਤ ਰਹਿਣਾ ਛੱਡ ਦਿੰਦੀ ਹੈ ਅਤੇ ਅਜਿਹੀ ਸੂਚੀ ਦੀ ਦੂਜੀ ਲਾਈਨ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿਸ ਉੱਤੇ ਸੱਚਮੁੱਚ ਕੰਮ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਉਹੀ ਸੂਚੀ ਤੁਸੀਂ ਨੈੱਟਵਰਕ ਟੀਮ ਨੂੰ ਦਿੰਦੇ ਹੋ, ਜਿਸਨੂੰ ਨਹੀਂ ਤਾਂ ਨਾ ਚੱਲਦੇ ਡੈਮਨ ਵਿੱਚ ਰਹਿਣ ਵਾਲੀ ਖਰਾਬੀ ਲਈ ਫਾਇਰਵਾਲ ਜਾਂਚਣ ਲਈ ਕਿਹਾ ਜਾਵੇਗਾ।