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

ਦੋ ਵੱਖਰੀਆਂ ਪਰਤਾਂ 'ਤੇ ਦੋ ਅਸਫਲਤਾਵਾਂ

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

ਲੱੱਖਣ ਇਸ ਤਰਹਾਂ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ਼ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਸੰਦ ਦੇ ਵੇਖ ਸਕਦੇ ਹੋ। DNS ਅਸਫਲਤਾ ਤੁਰੰਤ ਅਤੇ ਸਥਿਰ ਹੁੰਦੀ ਹੈ: ਬ੍ਰਾਊਜ਼ਰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਸਰਵਰ ਨਹੀਂ ਲੱਭ ਰਿਹਾ। MTU ਅਸਫਲਤਾ ਅੰਸ਼ਕ ਹੁੰਦੀ ਹੈ: ਸਫ਼ਾ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਕੁਝ ਸਰੋਤ ਆਉੰਦੇ ਹਨ਼, ਅਤੇ ਵੱਡਾ ਜਵਾਬ ਜਾਂ ਅੱਪਲੋਡ ਅਟਕ ਜਾਂਦਾ ਹੈ।

ਜੇ ਤੁਹਾਡਾ ਲੱੱਖਣ ਅੰਸ਼ਕ ਹੈ, ਤਾਂ DNS ਵੱਲ ਦੇਖਣਾ ਬੰਦ ਕਰੋ।

ਪੜਾਅ 1: ਕੀ ਨਾਮ ਬਿਲਕੁਲ ਹੱਲ ਹੁਂਦਾ ਹੈ

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

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਜੋ ਰਿਜ਼ੋਲਵਰ ਵਰਤੇਗਾ ਉਸ ਨੂੰ ਪੁੱਛੋ, ਫਿਰ ਤੁਲਨਾ ਕਰੋ:

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

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

ਪੜਾਅ 2: ਟ੍ਰਾਂਸਫਰ ਕਿੱਥੇ ਰੁਕਦਾ ਹੈ

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

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

ਇੱਕ ਦੁਹਰਾਉਣਯੋਗ ਰੁਕਾਵਟ ਦਸ ਕਿੱਸਿਆਂ ਨਾਲੋਂ ਵੱਧ ਕੀਮਤੀ ਹੈ।

MTU ਸਿਰਫ਼ ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਬਾਅਦ ਹੀ ਕਿਉਂ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ

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

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

ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਆਕਾਰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਮਾਪੋ:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

ਇੱਕ ਪਰਤ ਬਦਲੋ, ਫਿਰ ਸਾਬਤ ਕਰੋ

ਨਾਮਾਂ ਲਈ ਰਿਜ਼ੋਲਵਰ ਨੀਤੀ ਬਦਲੋ ਅਤੇ ਉਹੀ ਲੁੱਕਅੱਪ ਦੁਬਾਰਾ ਚਲਾਓ। ਆਕਾਰ ਲਈ MTU ਪ੍ਰਕਿਰਿਆ ਵਰਤੋ, ਮੂਲ ਮੁੱਲ ਦਰਜ ਕਰਕੇ ਅਤੇ ਵਾਪਸ ਜਾਣ ਦੀ ਤੈਯਾਰੀ ਨਾਲ, ਕਿਉਂਕਿ ਟਨਲ ਦਾ ਅਸਲ MTU ਜਾਣੇ ਬਿਨਾਂ MSS ਸੀਮਤ ਕਰਨਾ ਇੱਕ ਰੁਕਾਵਟ ਨੂੰ ਦੂਜੇ ਨਾਲ ਬਦਲ ਦੇਣਾ ਹੈ।

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

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

ਸੰਬੰਧਿਤ ਲੇਖ