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

ਹਰ ਪਰਿਵਾਰ ਕੀ ਕਰਦਾ ਹੈ

ਸਾਰਣੀ ਚਾਰ ਲਾਈਨਾਂ ਵਿੱਚ ਕਾਰਜਵਿਧੀ ਹੈ, ਅਤੇ ਇੱਕ ਲਾਈਨ ਬਹੁਤੀ ਉਲਝਣ ਸਮਝਾ ਦਿੰਦੀ ਹੈ।

BehaviourIPv4IPv6
Router fragments an oversized packetAllowed while DF is clearNever
Signal returned to the senderICMP Fragmentation NeededICMPv6 Packet Too Big
Size that must always work68 bytes1280 bytes
Fragmentation possibleRouters or sourceSource only

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

ਸੁਰੰਗ ਰਾਹ ਨੂੰ ਚੁੱਪਚਾਪ ਤੰਗ ਕਰਦੀ ਹੈ

VPN ਪੈਕੇਟ ਦੇ ਹੋਸਟ ਛੱਡਣ ਤੋਂ ਪਹਿਲਾਂ ਬਾਹਰੀ ਹੈਡਰ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਐਨਕ੍ਰਿਪਟਿਡ ਹਾਲਤ ਵਿੱਚ ਅਖੰਡਤਾ ਡੇਟਾ ਵੀ ਜੋੜਦਾ ਹੈ। ਅੰਦਰਲਾ ਪੈਕੇਟ ਉਸ ਇੰਟਰਫ਼ੇਸ MTU ਵਿੱਚ ਫਿੱਟ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਇਹ ਦੇਖਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਬਾਹਰੀ ਪੈਕੇਟ ਅਗਲੀ ਕੜੀ ਦੀ ਹੱਦ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਇਹ ਪਹਿਲਾਂ ਸੁਰੰਗ ਵਿੱਚ ਦਿਸਦਾ ਹੈ। ਸੁਰੰਗ ਇੰਟਰਫ਼ੇਸ ਦਾ MTU ਜਾਣ-ਬੁੱਝ ਕੇ ਘਟਾਓ, ਜਾਂ ਰਾਹ ਵਿੱਚ TCP MSS ਕੱਸੋ, ਅਤੇ ਤੁਸੀਂ ਕਿਹੜੀ ਸੰਖਿਆ ਚੁਣੀ ਅਤੇ ਕਿਉਂ ਲਿਖੋ।

ESP ਦਾ ਓਵਰਹੈਡ ਮੋਡ ਅਤੇ ਐਲਗੋਰਿਦਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸਹੀ ਸੁਰੰਗ MTU ਗਣਨਾ ਹੈ, ਰੀਤ ਨਹੀਂ। ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਇਹ ਪੂਰੇ 1280 ਬਾਈਟ ਅੰਦਰਲੇ IPv6 ਪੈਕੇਟ ਲਈ ਥਾਂ ਛੱਡਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਹਰ IPv6 ਕੜੀ ਨੇ ਓਨਾ ਢੋਣਾ ਪੈਂਦਾ ਹੈ। ਜੋ ਸੁਰੰਗ 1280 ਬਾਈਟ IPv6 ਨਹੀਂ ਢੋ ਸਕਦੀ, ਉਹ ਟਿਊਨਿੰਗ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ; ਉਹ ਉਸ ਪਰਿਵਾਰ ਲਈ ਟੁੱਟਾ ਰਾਹ ਹੈ। ਇਹੀ ਰੁਕਾਵਟ ਉਦੋਂ ਹਟਦੀ ਹੈ ਜਦੋਂ MTU ਮੁੱਲ ਕਿਸੇ ਸਿਰਫ਼-IPv4 ਤੈਨਾਤੀ ਤੋਂ ਨਕਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਲੱਛਣ ਅਟਕਣ ਵਰਗਾ ਕਿਉਂ ਦਿਸਦਾ ਹੈ

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

ਜੇ ICMPv6 ਦੇ ਪੈਕੇਟ ਬਹੁਤ ਵੱਡਾ ਸੁਨੇਹੇ ਫਿਲਟਰ ਹੋ ਜਾਣ, ਤਾਂ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਕਦੇ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਅਤੇ ਉਹੀ ਆਕਾਰ ਦੁਹਰਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ। ਉਹ ਕਾਲਾ ਟੋਆ ਹੈ, ਹੌਲੀ ਰਾਹ ਨਹੀਂ, ਅਤੇ ਇਸ ਦੀ ਪਹਿਚਾਣ ਬੇਤਰਤੀਬ ਨੁਕਸਾਨ ਨਹੀਂ, ਦੁਹਰਾਉਣਯੋਗ ਆਕਾਰ-ਹੱਦ ਹੈ। ਸੰਬੰਧਿਤ ਨਿਯੰਤਰਣ ਟ੍ਰੈਫਿਕ ਨੂੰ ਆਗਿਆ ਦੇਣਾ ਕੰਮ ਕਰਦੀ IPv6 ਤੈਨਾਤੀ ਦਾ ਹਿੱਸਾ ਹੈ, ਉਪਕਾਰ ਨਹੀਂ।

ਜਿਨ੍ਹਾਂ ਸੁਨੇਹਿਆਂ 'ਤੇ ਤੁਹਾਡਾ ਆਪਣਾ ਰਾਹ ਨਿਰਭਰ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਬੰਦ ਕਰਕੇ ਫਿਰ ਨਤੀਜੇ ਨੂੰ IPv6 ਦੀ ਖਰਾਬੀ ਨਾ ਕਹੋ। ਇਹੀ ਦਲੀਲ IPv4 ਦੇ Fragmentation Needed ਸੁਨੇਹਿਆਂ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਜੋ ਫਾਇਰਵਾਲ ਲੇਖਕਾਂ ਵਿੱਚ ਓਨੇ ਹੀ ਗੈਰ-ਮਕਬੂਲ ਅਤੇ ਓਨੇ ਹੀ ਜ਼ਰੂਰੀ ਹਨ।

ਹੱਦ ਮਾਪੋ, ਫਿਰ ਪਰਤ ਸੁਧਾਰੋ

ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਜਾਂਚੋ: IPv4 'ਤੇ don't-fragment ਝੰਡਾ ਅਤੇ IPv6 'ਤੇ ਨਿਸ਼ਚਿਤ ਪੇਲੋਡ ਆਕਾਰ ਵਰਤੋ, ਅਤੇ ਦਰਜ ਕਰੋ ਕਿ ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ ਕਿੱਥੇ ਰੁਕਦੀਆਂ ਹਨ। ping -M do -s 1472 ਅਤੇ ping -6 -s 1400 ਸਮੱਸਿਆ ਦਾ ਆਕਾਰ ਤੈਅ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹਨ, ਅਤੇ tracepath ਰਾਹ ਵਿੱਚ ਲੱਭਿਆ ਮਾਰਗ MTU ਦੱਸਦਾ ਹੈ।

ਫਿਰ ਉਸ ਪਰਤ ਨੂੰ ਸੁਧਾਰੋ ਜਿਸ ਕੋਲ ਉਹ ਸੰਖਿਆ ਹੈ: ਸੁਰੰਗ ਇੰਟਰਫ਼ੇਸ ਦਾ MTU, TCP ਲਈ MSS ਕੱਸਣਾ, ਜਾਂ ਰਾਹ ਖੁਦ। IPv6 ਨਿਯਮ ਲਈ RFC 8200 ਸੰਦਰਭ ਹੈ, ਅਤੇ ਇਹ ਉਸ ਘਟਨਾ ਨਾਲੋਂ ਛੋਟਾ ਪਾਠ ਹੈ ਜਿਸ ਨੂੰ ਇਹ ਰੋਕਦਾ ਹੈ।

ਉਸ ਪਰਿਵਾਰ ਦੀ ਜਾਂਚ ਕਰੋ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਵਰਤਦਾ ਹੈ, ਕਿਉਂਕਿ ਦੋਹਰਾ-ਸਟੈਕ ਨਾਮ ਇੱਕ ਪਰਿਵਾਰ 'ਤੇ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ ਅਤੇ ਦੂਜੇ 'ਤੇ ਨਹੀਂ, ਅਤੇ ਨੈੱਟਵਰਕ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਐਪਲੀਕੇਸ਼ਨ ਬਦਲ ਸਕਦਾ ਹੈ। ਜਿਸ ਪਤੇ ਦੀ ਜਾਂਚ ਕੀਤੀ ਉਹ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ A ਰਿਕਾਰਡ ਦੇ ਮੁਕਾਬਲੇ ਨਤੀਜਾ AAAA ਰਿਕਾਰਡ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

ਆਕਾਰ-ਹੱਦ ਨੂੰ ਸਬੂਤ ਮੰਨੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ