ਨੈਸਟਡ VPN ਟਨਲਾਂ: ਵੱਡੇ ਪੈਕਟਾਂ 'ਤੇ ਅੰਦਰਲੀ ਟਨਲ ਕਿਉਂ ਰੁਕਦੀ ਹੈ
ਹਰ ਟਨਲ ਅਗਲੀ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਰਾਹ ਦੇ ਪੈਕਟ ਬਜਟ ਦਾ ਹਿੱਸਾ ਖਰਚ ਕਰਦੀ ਹੈ। ਹੈਡਰ ਜੋੜੋ ਅਤੇ ਵੱਡੇ ਪੈਕਟਾਂ 'ਤੇ ਅੰਦਰਲਾ ਸੈਸ਼ਨ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ।
DNS ਹੱਲ ਹੁੰਦਾ ਹੈ, SSH ਸੈਸ਼ਨ ਕਾਇਮ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਵੱਡਾ ਅਪਲੋਡ ਰੁਕ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਉਸੇ ਹੋਸਟ ਨੂੰ ping ਅਜੇ ਵੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹ ਵਿਭਾਜਨ ਟੁੱਟੀ ਟਨਲ ਵੱਲ ਨਹੀਂ, ਸਗੋਂ ਪੈਕਟ ਦੇ ਆਕਾਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਨੈਸਟਡ ਟਨਲਾਂ ਉਹਨਾਂ ਆਕਾਰਾਂ 'ਤੇ ਉੱਥੇ ਪਹੁੰਚਦੀਆਂ ਹਨ ਜਿੱਥੇ ਕੋਈ ਇੱਕ ਟਨਲ ਇਕੱਲੀ ਨਹੀਂ ਪਹੁੰਚਦੀ। ਅੰਦਰਲਾ ਸੈਸ਼ਨ ਠੀਕ ਹੈ; ਇਸਨੂੰ ਹੁਣ ਨਾ ਵੜਨ ਵਾਲੇ ਪੈਕਟ ਦਿੱਤੇ ਜਾ ਰਹੇ ਹਨ।
ਰਾਹ ਦਾ MTU ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ
ਹਰ ਇੰਕੈਪਸੂਲੇਸ਼ਨ ਅਗਲੀ ਪਰਤ ਦੀ ਵਾਰੀ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਬਾਈਟ ਖਰਚਦਾ ਹੈ। ਇੱਕ Ethernet ਰਾਹ ਬਾਹਰਲੇ ਪੈਕਟ ਨੂੰ 1500 ਬਾਈਟ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਬਾਹਰਲੀ ਟਨਲ ਆਪਣਾ ਹਿੱਸਾ ਲੈ ਲੈਂਦੀ ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਇਸਦੇ ਅੰਦਰ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਪਤਾ ਦਿੱਤਾ ਜਾ ਸਕੇ। ਇੱਕ ਅੰਦਾਜ਼ਾ ਲਾਇਆ ਓਵਰਹੈਡ ਮੁੱਲ ਉੱਨਾ ਹੀ ਗਲਤ ਹੋਵੇਗਾ ਜਿੰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਪਰਤਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰੋ: ਪਹੁੰਚ ਰਾਹ, ਬਾਹਰਲੀ ਢੋਆ-ਢੁਆਈ, ਬਾਹਰਲੀ ਟਨਲ, ਅੰਦਰਲੀ ਢੋਆ-ਢੁਆਈ, ਅੰਦਰਲੀ ਟਨਲ, ਐਪਲੀਕੇਸ਼ਨ। ਹਰ ਹੈਡਰ ਨੂੰ ਇੱਕ ਵਾਰ ਗਿਣੋ, ਅਤੇ UDP ਨੂੰ ਟਨਲ ਦੇ ਆਪਣੇ ਹੈਡਰ ਅਤੇ ਟੈਗ ਤੋਂ ਵੱਖ ਰੱਖੋ।
ਦੋ WireGuard ਪਰਤਾਂ, ਇੱਕ ਵਾਰ ਗਿਣੀਆਂ
ਇੱਕ IPv4 ਪਹੁੰਚ ਰਾਹ ਲਵੋ, ਜਿਸਦੇ ਅੰਦਰ ਇੱਕ ਹੋਰ WireGuard ਟਨਲ ਹੈ। ਬਾਹਰਲੀ ਪਰਤ 20 ਬਾਈਟ IPv4, 8 ਬਾਈਟ UDP ਅਤੇ WireGuard ਡੇਟਾ ਹੈਡਰ ਤੇ ਇਸਦੇ ਪ੍ਰਮਾਣਿਕਤਾ ਟੈਗ ਲਈ 32 ਬਾਈਟ ਖਰਚਦੀ ਹੈ। ਇਸਦੇ ਅੰਦਰ ਅੰਦਰਲੀ ਟਨਲ ਨੂੰ ਆਪਣਾ 20 ਬਾਈਟ ਦਾ IPv4 ਹੈਡਰ ਅਤੇ 8 ਬਾਈਟ ਦਾ UDP ਹੈਡਰ ਚਾਹੀਦਾ ਹੈ, ਇਸਦੇ ਦੂਜੇ 32 ਬਾਈਟ WireGuard ਓਵਰਹੈਡ ਤੋਂ ਪਹਿਲਾਂ। ਬਾਕੀ ਬਚਿਆ ਹਿੱਸਾ IPv4 ਹੈਡਰ, TCP ਹੈਡਰ ਅਤੇ ਡੇਟਾ ਰੱਖਦਾ ਹੈ। ਬਾਹਰਲਾ IPv6 ਰਾਹ 20 ਦੀ ਥਾਂ 40 ਖਰਚਦਾ ਹੈ ਅਤੇ 1320 ਛੱਡਦਾ ਹੈ।
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
ਗਿਣਤੀ 1340 ਬਾਈਟ 'ਤੇ ਆਉਂਦੀ ਹੈ। ਉਹਨਾਂ ਹੀ ਨਿਯਮਾਂ ਨਾਲ ਇੱਕ ਪਰਤ TCP ਪੇਲੋਡ ਲਈ 1400 ਛੱਡਦੀ ਹੈ, ਭਾਵ 1500 ਵਿੱਚੋਂ 20, 8, 32, 20 ਅਤੇ 20 ਘਟਾ ਕੇ, ਅਤੇ 60 ਬਾਈਟ ਦਾ ਫਰਕ ਉਹੀ ਅੰਦਰਲਾ ਇੰਕੈਪਸੂਲੇਸ਼ਨ ਹੈ ਜੋ ਦੂਜੀ ਟਨਲ ਜੋੜਦੀ ਹੈ।
1400 ਨੂੰ ਨੈਸਟਡ ਰਾਹ 'ਤੇ ਲਾਗੂ ਕਰੋ ਅਤੇ ਅੰਦਰਲੀ ਟਨਲ 60 ਬਾਈਟ ਘੱਟ ਪੈਂਦੀ ਹੈ, ਜੋ ਪੈਕਟ ਦੇ ਉਹਨਾਂ ਦੀ ਲੋੜ ਜਿੰਨਾ ਵੱਡਾ ਹੋਣ ਤੱਕ ਅਦਿੱਖ ਰਹਿੰਦਾ ਹੈ। ਪੈਡਿੰਗ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਆਪਣਾ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਵਿਕਲਪ ਸੰਖਿਆਵਾਂ ਨੂੰ ਫਿਰ ਹਿਲਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਸਾਰਣੀ 'ਤੇ ਭਰੋਸਾ ਕਰੋ।
MTU, MSS ਅਤੇ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਵੱਖਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ
ਇੰਟਰਫੇਸ MTU ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਕਿ ਇੰਟਰਫੇਸ ਕੀ ਭੇਜੇਗਾ, ਜਦੋਂ ਕਿ TCP MSS ਕਲੈਂਪਿੰਗ ਬਦਲਦੀ ਹੈ ਕਿ TCP ਸਾਥੀ ਕੀ ਭੇਜਣ ਲਈ ਤਿਆਰ ਹੈ। ਕਲੈਂਪਿੰਗ TCP ਸੈਸ਼ਨ ਠੀਕ ਕਰਦੀ ਹੈ ਅਤੇ ਵੱਡੇ UDP ਡੇਟਾਗ੍ਰਾਮ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦੀ, ਇਸ ਤਰ੍ਹਾਂ ਇੱਕ ਸੁਧਾਰ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਸਫਲ ਦਿਸਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਨੂੰ ਚੁੱਪਚਾਪ ਖੁੰਝਾ ਦਿੰਦਾ ਹੈ। ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਆਪਣਾ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਵਿਕਲਪ ਆਪਣੀਆਂ ਅਸਫਲਤਾਵਾਂ ਵਾਲਾ ਤੀਜਾ ਲੀਵਰ ਹੈ। ਇੰਟਰਫੇਸ MTU ਆਮ ਪਹਿਲਾ ਕਦਮ ਅਤੇ ਸਭ ਤੋਂ ਮੋਟਾ ਹੈ।
ਬ੍ਰਿਜ ਕੀਤੀਆਂ ਅਤੇ ਰਾਊਟ ਕੀਤੀਆਂ ਟਨਲਾਂ ਵੱਖਰੇ ਫ੍ਰੇਮ ਢੋਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਕਿਸੇ ਹੋਰ ਤੈਨਾਤੀ ਦੇ ਸੰਖਿਆ ਅਕਸਰ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੇ। ਰਾਹ MTU ਖੋਜ, ਜਿਸਦਾ ਵਰਣਨ RFC 8201 ਵਿੱਚ ਹੈ, ਸਿਰਫ਼ ਤਦ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇਸ 'ਤੇ ਨਿਰਭਰ ICMP ਸੁਨੇਹਿਆਂ ਨੂੰ ਲੰਘਣ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਘੱਟ ਪੈਣ ਵਾਲੀ ਪਰਤ ਲੱਭਣਾ
ਜੇ ਲੋੜਾਂ ਤੁਲਨਾ ਦੀ ਆਗਿਆ ਦੇਣ, ਤਾਂ ਨੈਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਟਨਲ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ। ਸਥਿਰ ਆਕਾਰ ਦੀ ਪ੍ਰੋਬ ਇਹ ਤੈਅ ਕਰਦੀ ਹੈ: ping -M do -s 1472 -c 3 10.8.0.1 ਉਸ ਪਰਤ ਦੇ ਅੰਦਰ ਪੂਰਾ 1500 ਬਾਈਟ ਦਾ IPv4 ਪੈਕਟ ਭੇਜਦੀ ਹੈ। ਦੂਜੀ ਪਰਤ ਜੋੜੋ ਅਤੇ ਉਹੀ ਪ੍ਰੋਬ ਦੁਹਰਾਓ, ਤਾਂ ਜੋ ਕੋਈ ਵੀ ਅਸਫਲਤਾ ਕਿਸੇ ਜਾਣੇ-ਪਛਾਣੇ ਬਦਲਾਅ ਦੀ ਹੋਵੇ।
ਜਦੋਂ ਕੋਈ ਟ੍ਰਾਂਸਫਰ ਅਟਕਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਸਮੇਂ 'ਤੇ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਪੈਰਾਮੀਟਰ ਬਦਲੋ ਅਤੇ ਫੇਲ ਹੋਣ ਵਾਲਾ ਆਕਾਰ ਨੋਟ ਕਰੋ। ਵਾਪਸੀ ਰਾਹ ਵੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਨੈਸਟਡ ਰਾਊਟ ਰਿਕਰਸ਼ਨ ਪੈਕਟ-ਆਕਾਰ ਦੀ ਸਮੱਸਿਆ ਦੀ ਦੁਪਹਿਰ ਖਰਾਬ ਕਰਨ ਜਿੰਨੀ ਨੇੜੇ ਨਕਲ ਕਰ ਸਕਦਾ ਹੈ। ਫਿਲਟਰ ਕੀਤਾ ICMP ਜਵਾਬ ਅਸਲ ਸੀਮਾ ਲੁਕਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰੋਬ ਤਰਕ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਬਜਟ ਉੱਥੇ ਲਿਖੋ ਜਿੱਥੇ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਇਹ ਮਿਲੇਗਾ
ਹਰ ਪਰਤ ਲਈ ਇੱਕ ਕਤਾਰ ਵਾਲੀ ਸਾਰਣੀ ਅੰਗੂਠੇ ਦੇ ਨਿਯਮ ਤੋਂ ਵੱਧ ਚਿਰ ਰਹਿੰਦੀ ਹੈ। ਇਸਨੂੰ ਟਨਲ ਚਿੱਤਰ ਦੇ ਕੋਲ ਰੱਖੋ ਤਾਂ ਜੋ ਦਬਾਅ ਹੇਠ ਕੋਈ ਗਿਣਤੀ ਦੁਬਾਰਾ ਨਾ ਕਰੇ।
ਵੱਧ ਟਨਲਾਂ ਦਾ ਮਤਲਬ ਵੱਧ ਨਿਰਭਰਤਾਵਾਂ ਹਨ, ਇਸ ਲਈ ਰੋਲਬੈਕ ਯੋਜਨਾ ਬਜਟ ਦੇ ਕੋਲ ਆਪਣੀ ਥਾਂ ਕਮਾਉਂਦੀ ਹੈ। ਜੇ ਸੰਖਿਆਵਾਂ ਅਜੇ ਵੀ ਨਹੀਂ ਮਿਲਦੀਆਂ, ਤਾਂ ਦੁਬਾਰਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਰਾਹ ਨੂੰ ਮਾਪੋ। ਟੀਚਾ ਉਹ ਸੰਖਿਆ ਹੈ ਜਿਸਦਾ ਤੁਸੀਂ ਬਚਾਅ ਕਰ ਸਕਦੇ ਹੋ, ਯਾਦ ਰੱਖਣ ਵਾਲੀ ਨਹੀਂ।