WireGuard ਦੇ ਅੰਦਰ IPIP: ਉਹ ਵਾਧੂ 20 ਬਾਈਟ ਜੋ ਕਿਸੇ ਨੇ ਬਜਟ ਵਿੱਚ ਨਹੀਂ ਰੱਖੇ
IPIP WireGuard ਦੇ ਅੰਦਰ 20 ਵਾਧੂ ਬਾਈਟ ਖਰਚਦਾ ਹੈ। ਜੀਵੰਤ ਟਨਲ 'ਤੇ ਰੁਕੇ ਸਥਾਨਾਂਤਰਨ ਲਈ ਫਰੈਗਮੈਂਟੇਸ਼ਨ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਸਹੀ ਪਰਤ 'ਤੇ ਬਜਟ ਬਣਾਓ।
ਛੋਟੇ ping ਦਿਨ ਭਰ ਟਨਲ ਪਾਰ ਕਰਦੇ ਹਨ, SSH ਬੈਨਰ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਫਾਈਲ ਟ੍ਰਾਂਸਫਰ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹੀ ਸੈਸ਼ਨ ਜੰਮ ਜਾਂਦਾ ਹੈ। ਇਹ ਪੈਟਰਨ ਗਲਤ ਪਰਤ 'ਤੇ ਗਿਣੇ ਗਏ ਬਾਈਟ-ਬਜਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਬਾਹਰੀ ਟਨਲ ਆਪਣੇ ਖੁਦ ਦੇ ਓਵਰਹੈੱਡ ਲਈ ਮਾਪਿਆ ਗਿਆ ਅਤੇ ਕਿਸੇ ਨੇ ਅੰਦਰਲਾ ਨਹੀਂ ਘਟਾਇਆ। WireGuard ਲਈ ਨੈਸਟਡ IPIP ਪੈਕੇਟ ਬੱਸ ਇੱਕ ਹੋਰ IP ਪੈਕੇਟ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਇਹ ਉਹ ਬਾਈਟ ਵਰਤਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਰਾਖਵੇਂ ਨਹੀਂ ਰੱਖੇ। ਸੁਧਾਰ ਗਣਿਤ ਹੈ, ਅਤੇ ਇਹ ਤਿੰਨ ਕਮਾਂਡਾਂ ਅਤੇ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ।
ਜੋ ਲੱਛਣ ਇਸਨੂੰ ਫੜਦਾ ਹੈ
ਫਰੈਗਮੈਂਟੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਆਪਣੀ ਘੋਸ਼ਣਾ ਆਕਾਰ ਨਾਲ ਕਰਦੀ ਹੈ, ਕਦੇ ਪਤਿਆਂ ਨਾਲ ਨਹੀਂ। ਤੁਹਾਡਾ ਪੀਅਰ ਇੱਕ ਘੰਟੇ ਲਈ 56 ਬਾਈਟ ਦੇ ping ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਫਿਰ 1400 ਬਾਈਟ 'ਤੇ ਚੁੱਪ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਟਨਲ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਕੋਈ ਰੂਟ ਨਹੀਂ ਬਦਲਿਆ। ਹੈਂਡਸ਼ੇਕ ਬੈਠਦਾ ਹੈ, ਪਹਿਲੀ ਪੂਰੀ TCP ਵਿੰਡੋ ਨਹੀਂ, ਅਤੇ ਟ੍ਰਾਂਸਫਰ ਸਿਹਤਮੰਦ ਦਿਖਣ ਤੋਂ ਕੁਝ ਸਕਿੰਟ ਬਾਅਦ ਰੁਕ ਜਾਂਦਾ ਹੈ।
ਕੁਝ ਵੀ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਛੱਤ ਮਾਪੋ, ਕਿਉਂਕਿ ਨਾ-ਮਾਪੀ ਛੱਤ ਉਹੀ ਹੈ ਜਿਸਦਾ ਤੁਸੀਂ ਦੋ ਵਾਰ ਪਿੱਛਾ ਕਰੋਗੇ। ਸ਼ੱਕੀ ਆਕਾਰ ਤੋਂ ਹੇਠਾਂ do-not-fragment ਬਿੱਟ ਸੈੱਟ ਕਰਕੇ ਇੱਕ ਪ੍ਰੋਬ ਭੇਜੋ, ping -M do -s 1000 10.9.0.2, ਅਤੇ ਫਿਰ ਉਸ ਆਕਾਰ 'ਤੇ ਦੁਹਰਾਓ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹੋ ਬਹੁਤ ਵੱਡਾ ਹੈ। ਜਦੋਂ ਉਲਟਾ ਪੇਲੋਡ ਦੇ ਆਕਾਰ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਮੰਜ਼ਿਲ ਬਦਲਦੀ ਨਹੀਂ, ਤਾਂ ਰੂਟਿੰਗ ਆਪਣਾ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਅਤੇ ਬਜਟ ਵਿੱਚੋਂ ਇੱਕ ਹੈਡਰ ਗੁੰਮ ਹੈ।
ਹਰ ਹੈਡਰ ਨੂੰ ਇੱਕ ਵਾਰ ਗਿਣੋ, ਸਹੀ ਪਰਤ 'ਤੇ
ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਤੋਂ ਨਹੀਂ, ਸਗੋਂ ਰਸਤੇ ਦੇ ਸਭ ਤੋਂ ਛੋਟੇ MTU ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਕਿਉਂਕਿ ਕੰਧ ਦੋਵਾਂ ਸਿਰਿਆਂ ਤੋਂ ਉੱਪਰ ਹੈ। WireGuard IPv4 ਬਾਹਰੀ ਟਰਾਂਸਪੋਰਟ 'ਤੇ 60 ਬਾਈਟ ਖਰਚਦਾ ਹੈ: 20 IP ਲਈ, 8 UDP ਲਈ ਅਤੇ 32 ਆਪਣੇ ਹੈਡਰ ਲਈ, ਅਤੇ ਜਦੋਂ ਉਹ ਟਰਾਂਸਪੋਰਟ IPv6 ਹੋਵੇ ਤਾਂ 80 ਬਾਈਟ। 1420 ਬਾਈਟ ਦਾ wg0 1500 ਬਾਈਟ ਦੇ ਰਸਤੇ ਦੁਆਰਾ ਸੱਚਮੁੱਚ ਪਹੁੰਚਾਏ ਜਾ ਸਕਣ ਵਾਲੇ 1440 ਤੋਂ ਹੇਠਾਂ 20 ਬਾਈਟ ਦੀ ਛੋਟ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਵਿਕੀ ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਅੰਕੜਾ ਇੱਥੇ ਵੀ ਫਿੱਟ ਬੈਠਦਾ ਹੈ। ਪੂਰਾ ਸਟੈਕ ਡਾਇਗ੍ਰਾਮ 'ਤੇ ਲਿਖੋ, ਕਿਉਂਕਿ ਅਗਲੀ ਵਾਰ MTU ਬਦਲਣ ਵਾਲਾ ਨਹੀਂ ਤਾਂ ਨਵਾਂ ਗੋਲ ਅੰਕੜਾ ਚੁਣੇਗਾ ਅਤੇ ਤੁਹਾਡਾ ਬੱਗ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਏਗਾ।
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
ਪੰਜਵੀਂ ਕਤਾਰ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਬਜਟ ਵਿਗੜਦੇ ਹਨ, ਕਿਉਂਕਿ ਨੈਸਟਡ ਇੰਟਰਫ਼ੇਸ ਜੋ 1400 ਬਾਈਟ ਢੋਂਦਾ ਹੈ, ਉਹਨਾਂ ਵਿੱਚ ਮੂਲ ਪੈਕੇਟ ਦੇ ਆਪਣੇ 40 ਬਾਈਟ ਹੈਡਰ ਪਹਿਲਾਂ ਹੀ ਸ਼ਾਮਲ ਹਨ। ਉਹਨਾਂ ਬਾਈਟਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ 1360 ਹੀ ਫਾਈਲ ਪੜ੍ਹਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ। 1400 ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਪੇਲੋਡ ਮੰਨੋ, ਜਿਵੇਂ ਉਸ ਕਾਲਮ ਤੋਂ ਬਿਨਾਂ ਕੋਈ ਵੀ ਡਾਇਗ੍ਰਾਮ ਤੁਹਾਨੂੰ ਸੱਦਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਅੰਦਰਲਾ ਯੰਤਰ ਨਾ ਹਿੱਲੀ ਕੰਧ ਅੱਗੇ 40 ਬਾਈਟ ਵਧੇਰੇ ਦਿਆਲੂ ਹੋ ਕੇ ਰਹਿ ਜਾਂਦਾ ਹੈ।
ਦੋਵੇਂ MTU ਵੱਖਰੇ-ਵੱਖਰੇ ਸੈੱਟ ਕਰੋ
ਵਾਹਕ ਅਤੇ ਨੈਸਟਡ ਯੰਤਰ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਹਨ, ਇਸ ਲਈ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣਾ ਮੁੱਲ ਚਾਹੀਦਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਲਾਗੂ ਕਰੋ, ਕਿਉਂਕਿ ਨੈਸਟਡ ਯੰਤਰ ਵਾਹਕ ਤੋਂ ਕੁਝ ਵੀ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਲੈਂਦਾ:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400ਯਾਦ ਰੱਖਣ ਯੋਗ ਨਿਯਮ: ਅੰਦਰਲਾ MTU = ਬਾਹਰੀ MTU - 20 ਜਦੋਂ IPIP ਟਨਲ ਜੋ ਪੈਕੇਟ ਢੋਂਦਾ ਹੈ ਉਹ IPv4 ਹੈ, ਅਤੇ - 40 ਜਦੋਂ ਅੰਦਰਲੇ ਪੈਕੇਟ ਦਾ ਕੋਈ ਵੀ ਪਾਸਾ IPv6 ਹੋ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਨੈਸਟਡ ਹੈਡਰ 20 ਬਾਈਟ ਤੋਂ 40 ਤੱਕ ਵਧਦਾ ਹੈ। ਉਸ ਘਟਾਓ ਵਿੱਚ ਹੋਰ ਕੁਝ ਨਹੀਂ ਆਉਂਦਾ। ਤੁਸੀਂ 1420 ਚੁਣਿਆ ਤਾਂ WireGuard ਦਾ ਓਵਰਹੈੱਡ ਪਹਿਲਾਂ ਹੀ ਖਰਚ ਹੋ ਚੁੱਕਾ ਸੀ, ਅਤੇ ਇਸਨੂੰ ਦੋ ਵਾਰ ਲੈਣ ਨਾਲ ਇੱਕ ਟਨਲ ਬਣਦਾ ਹੈ ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਜਿੰਨਾ ਚਿਰ ਕੋਈ ਮਾਪਦਾ ਨਹੀਂ ਉੱਨਾ ਚਿਰ ਹੌਲੀ ਰਹਿੰਦਾ ਹੈ। ਜਿਸ ਤੈਨਾਤੀ ਵਿੱਚ ਦੋਵੇਂ ਯੰਤਰ ਗੋਲ 1400 ਢੋਂਦੇ ਹਨ, ਉਹ ਠੀਕ ਉਸੇ ਗਲਤੀ ਦੀ ਉਂਗਲ ਦੀ ਛਾਪ ਹੈ।
ਨੈਸਟਡ ਪੈਕੇਟ ਦੇ ਕਿਸੇ ਵੀ ਪਾਸੇ IPv6 ਹੋਣ ਨਾਲ ਉੱਪਰ ਦਿੱਤੇ ਹਰ ਅੰਕੜੇ ਅਵੈਧ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਮਿਲਦੇ-ਜੁਲਦੇ ਸਾਈਟ ਤੋਂ ਅੰਕੜਾ ਕਾਪੀ ਕਰਨ ਦੀ ਬਜਾਏ ਦੁਬਾਰਾ ਗਣਨਾ ਕਰੋ। ਜਿਵੇਂ ਹੀ IPv6 ਬਾਹਰੀ ਰਸਤੇ ਵਿੱਚ ਜਾਂ ਮੂਲ ਡੇਟਾਗ੍ਰਾਮ ਵਿੱਚ ਦਿਖਦਾ ਹੈ, ਘਟਾਏ ਗਏ ਹੈਡਰ ਹਰ ਇੱਕ 40 ਬਾਈਟ ਦੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਪੇਲੋਡ ਦਾ ਅੰਕੜਾ ਠੀਕ ਉੱਨਾ ਹੀ ਘਟਦਾ ਹੈ।
ਉਹ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜੋ ਸ਼ਾਇਦ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦਾ ਨਹੀਂ
ਦੋ WireGuard ਪੀਅਰਾਂ ਵਿਚਕਾਰ ਤਾਰ 'ਤੇ ਇੱਕੋ ਚੀਜ਼ UDP ਹੈ, ਇਸ ਲਈ ਪ੍ਰੋਟੋਕੋਲ 4 ਲਈ ਆਉਣ ਵਾਲਾ ਨਿਯਮ, ਜੋ ਨੰਬਰ RFC 2003 IPv4-ਅੰਦਰ-IPv4 ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਨੂੰ ਦਿੰਦਾ ਹੈ, ਨਾ ਨੈਸਟਡ ਰਸਤਾ ਬਣਾਉਂਦਾ ਹੈ ਨਾ ਉਸਨੂੰ ਜੀਵਤ ਰੱਖਦਾ ਹੈ। IPIP ਹੈਡਰ ਐਨਕ੍ਰਿਪਟਿਡ ਪੇਲੋਡ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ, ਜਿੱਥੇ ਕੋਈ ਕਿਨਾਰਾ ਫਾਇਰਵਾਲ ਉਸਨੂੰ ਨਹੀਂ ਦੇਖਦਾ। ਪ੍ਰੋਟੋਕੋਲ 4 ਖੋਲ੍ਹਣ ਨਾਲ ਹੋਸਟ ਵੱਲ ਇੱਕ ਹੋਰ ਮਨਜ਼ੂਰ ਰਸਤੇ ਤੋਂ ਬਿਨਾਂ ਕੁਝ ਨਹੀਂ ਮਿਲਦਾ।
ਮੂਲ ਪੈਕੇਟ ਦੇ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲਾਂ ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਡੀਕੈਪਸੂਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ, ਟਨਲ ਇੰਟਰਫ਼ੇਸਾਂ 'ਤੇ ਅਤੇ ਰੂਟਿੰਗ ਸਾਰਣੀ ਵਿੱਚ ਆਉਂਦੀ ਹੈ। ਇਸਨੂੰ ਉੱਥੇ ਰੱਖੋ ਅਤੇ ਕਿਨਾਰਾ ਨਿਯਮ ਬੰਦ ਰਹਿ ਸਕਦਾ ਹੈ।
WireGuard ਅਸਲ ਵਿੱਚ ਕੀ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ
AllowedIPs WireGuard ਜੋ ਪੈਕੇਟ ਢੋਂਦਾ ਹੈ ਉਸਦੇ ਸਰੋਤ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਜੋ ਢੋਂਦਾ ਹੈ ਉਹ IPIP-ਇਨਕੈਪਸੂਲੇਟਿਡ ਪੈਕੇਟ ਹੈ। ਮਨਜ਼ੂਰ IPIP ਸਰੋਤ ਤਦ ਵੀ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਅੰਦਰਲਾ ਹੈਡਰ ਉਸ ਹੋਸਟ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਰੂਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੋਗੇ। ਇਸ ਲਈ ਮੂਲ ਸਰੋਤ ਉਹ ਨਹੀਂ ਜੋ ਪੀਅਰ ਨੇ ਤੁਹਾਡੇ ਲਈ ਜਾਂਚਿਆ, ਅਤੇ ਉਸ ਅੰਦਰਲੀ ਪਤੇ ਦੀ ਜੋੜੀ ਨੂੰ ਡੀਕੈਪਸੂਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਆਪਣੀ ਲਾਗੂਆਈ ਚਾਹੀਦੀ ਹੈ।
ਲਪੇਟ ਰੂਟਿੰਗ ਢਾਂਚਾ ਦਿੰਦਾ ਹੈ, ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦੀ ਦੂਜੀ ਪਰਤ ਨਹੀਂ। WireGuard ਦੇ ਅੰਦਰ IPIP ਨੂੰ ਵਾਧੂ ਸੁਰੱਖਿਆ ਕਹਿਣਾ ਵੱਖਰੇ ਡਿਜ਼ਾਈਨ ਦਾ ਵਰਣਨ ਹੈ।
ਇੱਕ ping ਨਹੀਂ, ਪੌੜੀ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰੋ
ਤੁਹਾਡੇ ਗਿਣੇ ਹੱਦ ਦੇ ਦੋਵੇਂ ਪਾਸੇ ਪੈਣ ਵਾਲੇ ਆਕਾਰਾਂ ਦੀ ਪਰਖ ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਰਨਲ ਦੋਵੇਂ ਯੰਤਰਾਂ ਬਾਰੇ ਕੀ ਮੰਨਦਾ ਹੈ। 1360 ਬਾਈਟ ਪੇਲੋਡ ਅਤੇ 40 ਬਾਈਟ ਹੈਡਰ ਮਿਲ ਕੇ 1400 ਬਣਦੇ ਹਨ, ਹੇਠਾਂ ਦਿੱਤੀ ਪਹਿਲੀ ਗੂੰਜ ਫਿੱਟ ਬੈਠਦੀ ਹੈ ਅਤੇ ਦੂਜੀ ਛੱਤ ਤੋਂ ਇੱਕ ਬਾਈਟ ਅੱਗੇ ਬੈਠਦੀ ਹੈ:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0ਛੱਤ ਹੇਠਾਂ ਸਾਫ਼ ਲੰਘਣਾ ਅਤੇ ਉਸ ਤੋਂ ਉੱਪਰਲੇ ਪਹਿਲੇ ਆਕਾਰ 'ਤੇ ਫੇਲ ਹੋਣਾ ਭਾਵ ਗਣਿਤ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਟਿਕਦਾ ਹੈ। ਫਿਰ ਉਹ ਟ੍ਰਾਂਸਫਰ ਦੁਬਾਰਾ ਚਲਾਓ ਜੋ ਮੂਲ ਰੂਪ ਵਿੱਚ ਰੁਕਿਆ ਸੀ, ਕਿਉਂਕਿ ਨਕਲੀ ਪ੍ਰੋਬ ਬਜਟ ਸਾਬਤ ਕਰਦਾ ਹੈ ਅਤੇ ਭੇਜਣ ਵਾਲੇ ਦੇ ਆਪਣੇ ਲਿਖਣ-ਆਕਾਰਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਜੇ ਨੈਸਟਡ ਰਸਤਾ ਉਸ ਆਕਾਰ 'ਤੇ ਵੀ ਟੁੱਟਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸਾਬਤ ਕੀਤਾ ਕਿ ਫਿੱਟ ਬੈਠਦਾ ਹੈ, ਤਾਂ MTU ਵਿੱਚੋਂ ਹੋਰ ਦਸ ਬਾਈਟ ਕੱਟਣ ਤੋਂ ਪਹਿਲਾਂ ਦੂਰਲੇ ਸਿਰੇ ਦਾ ਡੀਕੈਪਸੂਲੇਸ਼ਨ ਅਤੇ ਰੂਟ ਜਾਂਚੋ।