ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਰਾਹੀਂ IPv6 ਪ੍ਰੀਫਿਕਸ ਡੈਲੀਗੇਸ਼ਨ: ਚੈੱਕਲਿਸਟ
ਡੈਲੀਗੇਟ ਕੀਤੇ IPv6 ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਰਾਹੀਂ ਰੂਟ ਕਰਨ ਦੀਆਂ ਜਾਂਚਾਂ: ਪ੍ਰੀਫਿਕਸ ਨਕਸ਼ਾ, ਟ੍ਰੈਫਿਕ ਸਿਲੈਕਟਰ, ਫਾਰਵਰਡਿੰਗ, MTU, ਵਾਪਸੀ ਮਾਰਗ ਅਤੇ ਮੁੜ-ਨੰਬਰੀਕਰਨ।
ਟਨਲ ਚੁੱਕਣਾ ਸੌਖਾ ਅੱਧ ਹੈ। ਮੈਂ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਲਿੰਕ ਦਿਨਾਂ ਤੱਕ ਸਥਾਪਿਤ ਰਹਿੰਦਾ ਦੇਖਿਆ ਹੈ, ਜਦੋਂ ਕਿ ਦੂਰਲੇ LAN ਦੇ ਹਰ ਹੋਸਟ ਨੂੰ ਸਿਰਫ਼ ਚੁੱਪ ਵਾਪਸ ਮਿਲਦੀ ਸੀ, ਕਿਉਂਕਿ ਉਸ ਗੇਟਵੇ ਪਿੱਛੇ ਦਾ ਡੈਲੀਗੇਟ ਕੀਤਾ ਪ੍ਰੀਫਿਕਸ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਕਨਫਿਗਰ ਸੀ ਪਰ ਕਦੇ ਟਨਲ ਵਿੱਚ ਰੂਟ ਨਹੀਂ ਹੋਇਆ। ਟਨਲ ਦੇ ਪਤੇ ਉਸ ਸਮੇਂ ਪਿੰਗ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਰਹੇ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਕਿਸੇ ਨੇ ਪ੍ਰੀਫਿਕਸ ਵੱਲ ਨਹੀਂ ਦੇਖਿਆ। ਜਦੋਂ ਡੈਲੀਗੇਟ ਕੀਤੇ IPv6 ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਸਾਈਟ VPN ਪਾਰ ਕਰਨਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਮੈਂ ਇਹ ਕ੍ਰਮ ਜਾਂਚਦਾ ਹਾਂ: ਪ੍ਰੀਫਿਕਸ ਨਕਸ਼ਾ, ਟ੍ਰੈਫਿਕ ਸਿਲੈਕਟਰ, ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ, ਫਿਰ ਵਾਪਸੀ ਮਾਰਗ।
ਟਨਲ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੀਫਿਕਸ ਨਕਸ਼ਾ ਲਿਖੋ
ਪ੍ਰੀਫਿਕਸ ਡੈਲੀਗੇਸ਼ਨ ਮੰਗ ਕਰਨ ਵਾਲੇ ਰਾਊਟਰ ਨੂੰ ਇੱਕ ਬਲਾਕ ਦਿੰਦਾ ਹੈ। ਇਹ ਪੀਅਰ 'ਤੇ ਰੂਟ ਨਹੀਂ ਲਾਉਂਦਾ, ਉਹ ਬਲਾਕ on-link ਨਹੀਂ ਵਧਾਉਂਦਾ, ਅਤੇ ਦੂਰਲੇ ਗੇਟਵੇ ਨੂੰ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਮੰਗ ਕਰਨ ਵਾਲੇ ਰਾਊਟਰ ਪਿੱਛੇ ਕੀ ਹੈ। ਇਹ ਤਿੰਨ ਤੁਹਾਨੂੰ ਆਪ ਕਨਫਿਗਰ ਕਰਨੇ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਕਨਫਿਗ ਫਾਈਲ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਪਤਾ ਯੋਜਨਾ ਵਿੱਚ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਹਰ ਸਾਈਟ ਲਈ ਡੈਲੀਗੇਟ ਕੀਤਾ ਪ੍ਰੀਫਿਕਸ, LAN 'ਤੇ ਅਸਲ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ /64, ਟਨਲ ਦੇ ਪਤੇ ਅਤੇ ਹਰ ਰੂਟ ਦਾ ਮਾਲਕ ਦਰਜ ਕਰੋ। ਪ੍ਰਦਾਤਾ ਸਾਈਟ A ਨੂੰ 2001:db8:a1::/56 ਡੈਲੀਗੇਟ ਕਰਦਾ ਹੈ, ਜੋ ਆਪਣੇ LAN 'ਤੇ 2001:db8:a1:10::/64 ਦਿੰਦਾ ਹੈ; ਸਾਈਟ B 2001:db8:b2::/64 ਰੱਖਦਾ ਹੈ। ਜੇ ਸਾਈਟ A ਸਿਰਫ਼ ਉਹ ਇੱਕ /64 ਦਿੰਦਾ ਹੈ, ਦੋਵੇਂ ਸਿਰੇ ਪੂਰੇ /56 ਦੀ ਥਾਂ 2001:db8:a1:10::/64 ਦਾ ਜ਼ਿਕਰ ਕਰਨ।
ਲਗਭਗ ਹਰ ਵਾਰ ਦੋ ਗਲਤੀਆਂ ਦਿਖਦੀਆਂ ਹਨ। ਇੱਕ ਦੂਰਲੇ ਪ੍ਰੀਫਿਕਸ ਨੂੰ on-link ਮੰਨਣਾ, ਉਸਨੂੰ ਬ੍ਰਿਜ ਕਰਨਾ ਜਾਂ ਟਨਲ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਰੱਖਣਾ ਹੈ, ਜਿਸ ਨਾਲ ਗੇਟਵੇ ਉਨ੍ਹਾਂ ਹੋਸਟਾਂ ਲਈ ਗੁਆਂਢੀ ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਪਹੁੰਚ ਨਹੀਂ ਸਕਦਾ। ਦੂਜੀ ਇੱਕੋ /64 ਕਨਫਿਗਰ ਹੋਣ 'ਤੇ ਪੂਰਾ /56 ਐਲਾਨਣਾ ਹੈ: ਰੂਟ ਸਾਰਣੀ ਦਾਅਵਾ ਕਰਦੀ ਹੈ ਕਿ ਬਲਾਕ ਪਹੁੰਚਯੋਗ ਹੈ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਪਤੇ ਕਾਲੇ ਟੋਏ ਵਿੱਚ ਡਿੱਗਦੇ ਹਨ।
ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੇ ਟ੍ਰੈਫਿਕ ਸਿਲੈਕਟਰ ਰੂਟਾਂ ਨਾਲ ਮਿਲਾਓ
IKEv2 ਅਤੇ WireGuard ਦੋਵੇਂ ਨਾ-ਮਿਲਦੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੱਦ ਕਰਦੇ ਹਨ, ਟਨਲ ਅਜੇ ਵੀ ਸਿਹਤਮੰਦ ਦਿਖਣ ਜਿੰਨਾ ਚੁੱਪਚਾਪ।
strongSwan ਵਿੱਚ ਸਿਲੈਕਟਰ ਸਪੱਸ਼ਟ ਹੁੰਦੇ ਹਨ। ਸਾਈਟ A 'ਤੇ:
conn a-to-b
left=2001:db8:ff::1
leftsubnet=2001:db8:a1:10::/64
right=2001:db8:ff::2
rightsubnet=2001:db8:b2::/64
auto=startਸਾਈਟ B ਦਾ conn ਦੋਵੇਂ ਸਬਨੈੱਟ ਦਰਸਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਉਹ ਨਹੀਂ ਮਿਲਦੇ, ਜਵਾਬ ਦੇਣ ਵਾਲਾ CHILD_SA ਨੂੰ TS_UNACCEPTABLE ਨਾਲ ਰੱਦ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ IKE_SA ਚੜ੍ਹਨ 'ਤੇ ਵੀ child SA ਕਦੇ ਨਹੀਂ ਚੜ੍ਹਦਾ। ਦੋਵੇਂ ਪਾਸੇ ਕਨਫਿਗਰ ਕੀਤਾ ਸਬਨੈੱਟ ਉਸ ਨਾਲ ਬਰਾਬਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸਥਾਨਕ ਕਰਨਲ ਟਨਲ ਵੱਲ ਰੂਟ ਕਰਦਾ ਹੈ।
WireGuard ਉਹੀ ਜਾਣਕਾਰੀ AllowedIPs ਵਿੱਚ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ, ਇੱਕ ਮੋੜ ਨਾਲ: AllowedIPs ਪ੍ਰਾਪਤ ਕਰਦਿਆਂ ਸਰੋਤ ਫਿਲਟਰ ਅਤੇ ਭੇਜਦਿਆਂ ਰੂਟ ਹੈ। ਜੇ ਸਾਈਟ B ਦੀ ਸਾਈਟ A ਲਈ peer ਐਂਟਰੀ 2001:db8:a1:10::/64 ਛੱਡ ਦਿੰਦੀ ਹੈ, ਸਾਈਟ A ਤੋਂ ਆਉਣ ਵਾਲੇ ਪੈਕੇਟ ਵੈਧ handshake 'ਤੇ ਆਉਂਦੇ ਹਨ ਅਤੇ ਇਜਾਜ਼ਤ ਨਾ ਹੋਣ ਕਰਕੇ ਸੁੱਟੇ ਜਾਂਦੇ ਹਨ। ਇਸ ਨਾਲ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਨਮੂਨਾ ਬਣਦਾ ਹੈ: handshake ਲਗਾਤਾਰ ਨਵੀਨੀਕਰਨ ਹੁੰਦਾ ਰਹਿੰਦਾ ਹੈ ਪਰ ਜਵਾਬ ਕਦੇ ਬਾਹਰ ਨਹੀਂ ਜਾਂਦਾ। ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੀ wg show wg0 allowed-ips ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਡੈਲੀਗੇਸ਼ਨ ਬਦਲਣ 'ਤੇ ਹਰ ਵਾਰ ਉਹ ਸੂਚੀ ਮੁੜ ਜਾਂਚੋ; ਪੁਰਾਣਾ /64 ਸੈਸ਼ਨ ਨੂੰ ਜੀਵਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਨਵਾਂ ਪ੍ਰੀਫਿਕਸ ਨਾ-ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਪਹਿਲਾਂ ਫਾਰਵਰਡਿੰਗ, ਫਾਇਰਵਾਲ ਅਤੇ MTU ਨੂੰ ਬਾਹਰ ਰੱਖੋ
ਅਗਲੀ ਲੌਗ ਲਾਈਨ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਗੇਟਵੇ ਕੁਝ ਫਾਰਵਰਡ ਕਰਦੇ ਹਨ। sysctl net.ipv6.conf.all.forwarding ਦੋਵਾਂ 'ਤੇ 1 ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਟਨਲ ਅਤੇ LAN ਇੰਟਰਫ਼ੇਸਾਂ 'ਤੇ ਵੀ ਲਾਗੂ। ਇੱਕ ਜਾਲ ਵੀ ਹੈ: ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ ਹੋਣ 'ਤੇ accept_ra=1 ਵਾਲਾ ਇੰਟਰਫ਼ੇਸ ਪ੍ਰਦਾਤਾ ਤੋਂ ਰਾਊਟਰ ਇਸ਼ਤਿਹਾਰ ਲੈਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਮਸ਼ੀਨ ਟਨਲ ਅੰਦਰ ਸਹੀ ਰੂਟ ਕਰਦਿਆਂ ਵੀ ਉੱਪਰਲਾ ਡਿਫਾਲਟ ਮਾਰਗ ਗੁਆ ਸਕਦੀ ਹੈ। ਜਿੱਥੇ ਪ੍ਰਦਾਤਾ ਦਾ RA ਅਜੇ ਵੀ ਲੋੜੀਂਦਾ ਹੈ ਉੱਥੇ accept_ra=2 ਸੈੱਟ ਕਰੋ।
ਫਿਰ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਨੂੰ ਪ੍ਰੀਫਿਕਸ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਮਨਜ਼ੂਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ICMPv6 ਨੂੰ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ: ਗੁਆਂਢੀ ਖੋਜ, packet-too-big ਅਤੇ destination-unreachable ਚੋਣਵੇਂ ਨਹੀਂ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਛੱਡੋ ਤਾਂ ਮਾਰਗ MTU ਖੋਜ ਟੁੱਟਦੀ ਹੈ, ਅਤੇ ਖੁੱਲ੍ਹ ਕੇ ਪਹਿਲੇ ਵੱਡੇ ਜਵਾਬ 'ਤੇ ਰੁਕਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਮਿਲਦੇ ਹਨ। ਘੱਟੋ-ਘੱਟ ਨਿਯਮ ਜੋੜੀ ਇੰਝ ਦਿਖਦੀ ਹੈ:
nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } acceptMTU ਇਸਦੇ ਪਿੱਛੇ ਹੈ। ਟਨਲ ਵਰਤੋਂਯੋਗ MTU ਨੂੰ 1500 ਤੋਂ ਹੇਠਾਂ ਘਟਾਉਂਦਾ ਹੈ, ਅਤੇ IPv6 ਮੰਗ ਕਰਦਾ ਹੈ ਕਿ ਹਰ ਲਿੰਕ ਘੱਟੋ-ਘੱਟ 1280 ਲੈ ਕੇ ਚੱਲੇ। ਛੋਟੇ ਪਿੰਗ ਲੰਘਦੇ ਹਨ, SSH ਸੈਸ਼ਨ ਵੱਡੇ ਝਟਕੇ 'ਤੇ ਜੰਮ ਜਾਂਦਾ ਹੈ, ਅਤੇ /proc/net/snmp6 ਵਿੱਚ ਕਦੇ ਨਾ ਵਾਪਸ ਆਉਣ ਵਾਲੇ packet-too-big ਸੁਨੇਹੇ ਦਿਖਦੇ ਹਨ। ਟਨਲ ਦਾ MTU ਸਪੱਸ਼ਟ ਸੈੱਟ ਕਰੋ, ਜਾਂ mangle ਸਾਰਣੀ ਵਿੱਚ TCP MSS ਸੀਮਤ ਕਰੋ, ਅਤੇ ਛੋਟਾ MTU ਦੱਸਣ ਵਾਲੇ ICMPv6 ਨੂੰ ਵਾਪਸ ਆਉਣ ਦਿਓ।
ਟਨਲ ਦਾ ਪਤਾ ਨਹੀਂ, ਵਾਪਸੀ ਮਾਰਗ ਜਾਂਚੋ
ਸਭ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਣ ਵਾਲੀ ਖਰਾਬੀ ਇੱਕ-ਦਿਸ਼ਾ ਰੂਟਿੰਗ ਹੈ। ਹਰ ਗੇਟਵੇ ਦੂਰਲੇ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਟਨਲ ਵਿੱਚ ਰੂਟ ਕਰਦਾ ਹੈ, ਪਰ ਹੋਸਟ ਆਪਣੇ ਡਿਫਾਲਟ ਗੇਟਵੇ ਰਾਹੀਂ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਦਾ /64 ਉੱਥੇ ਹੀ ਹੈ। ਪੈਕੇਟ ਨੂੰ ਮੰਜ਼ਿਲ ਤੱਕ ਪਹੁੰਚਾਉਣਾ ਅੱਧਾ ਮਾਰਗ ਹੈ।
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
ਦੋ ਕਮਾਂਡਾਂ ਬਹੁਤਾ ਹੱਲ ਕਰਦੀਆਂ ਹਨ। ਸਾਈਟ A 'ਤੇ ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਸ ਸਰੋਤ ਤੋਂ ਆਉਣ ਵਾਲਾ ਜਵਾਬ ਕਿਹੜਾ ਇੰਟਰਫ਼ੇਸ ਵਰਤੇਗਾ; ਸਾਈਟ B 'ਤੇ ਸ਼ੀਸ਼ੇ ਵਾਲੀ ਜਾਂਚ ਕਰੋ। ਫਿਰ ਗੇਟਵੇ ਦੀ ਥਾਂ ਹੋਸਟ ਤੋਂ ਟ੍ਰੈਫਿਕ ਬਣਾਓ ਅਤੇ ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੇ ਗਿਣਕੇ ਤੁਲਨਾ ਕਰੋ।
ਜੇ ਦੂਰਲੇ ਪ੍ਰੀਫਿਕਸ ਲਈ ਗੁਆਂਢੀ ਬੇਨਤੀ ਟਨਲ 'ਤੇ ਦਿਖਦੀ ਹੈ, ਉਹ ਪ੍ਰੀਫਿਕਸ ਕਿਤੇ on-link ਹੈ ਜਿੱਥੇ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ; ਰੂਟ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਠੀਕ ਕਰੋ। Proxy NDP ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਬ੍ਰਿਜਿੰਗ ਸੱਚਮੁੱਚ ਲੋੜੀਂਦੀ ਹੈ, ਰੂਟ ਦਾ ਬਦਲ ਨਹੀਂ।
ਪ੍ਰੀਫਿਕਸ ਤੁਹਾਡੇ ਹੇਠ ਬਦਲਣ ਦੀ ਯੋਜਨਾ ਬਣਾਓ
ਪ੍ਰੀਫਿਕਸ ਡੈਲੀਗੇਸ਼ਨ ਡੈਲੀਗੇਟ ਕਰਨ ਵਾਲੇ ਅਤੇ ਮੰਗ ਕਰਨ ਵਾਲੇ ਰਾਊਟਰ ਵਿਚਕਾਰ ਪਟੇ 'ਤੇ ਲੈਣ-ਦੇਣ ਹੈ, ਅਤੇ ਨਵੀਨੀਕਰਨ ਵੱਖਰਾ ਬਲਾਕ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ: ਪ੍ਰਦਾਤਾ ਤਬਾਦਲੇ ਤੋਂ ਬਾਅਦ ਵੱਖਰਾ /56, ਜਾਂ ਟਨਲ ਚੱਲਣ ਦੀ ਮਿਆਦ ਤੋਂ ਛੋਟਾ ਪਟਾ। ਪੁਰਾਣੇ ਪ੍ਰੀਫਿਕਸ ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲੀ ਹਰ ਥਾਂ ਇਕੱਠੇ ਪੁਰਾਣੀ ਹੋ ਜਾਂਦੀ ਹੈ: ਰੂਟ, ਸਿਲੈਕਟਰ, AllowedIPs, ਫਾਇਰਵਾਲ ਨਿਯਮ, DNS ਰਿਕਾਰਡ ਅਤੇ ਸ਼ਾਬਦਿਕ ਪਤੇ ਹਾਰਡਕੋਡ ਕਰਨ ਵਾਲੀ ਕੋਈ ਵੀ ਨਿਗਰਾਨੀ। ਸੁਨੇਹਾ ਪ੍ਰਵਾਹ RFC 8415 ਵਿੱਚ ਹੈ।
ਜਿੱਥੇ ਪ੍ਰੀਫਿਕਸ ਦੇ ਹਿਲਣ ਦੀ ਉਮੀਦ ਹੈ, ਉੱਥੇ ਇਸ 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰਨ ਵਾਲੀ ਅੰਦਰੂਨੀ ਪਤਾ ਯੋਜਨਾ ਰੱਖੋ ਅਤੇ ਸੀਮਾ 'ਤੇ ਅਨੁਵਾਦ ਕਰੋ। NPTv6 ਬਿਨਾਂ ਸਥਿਤੀ ਵਾਲਾ ਵਿਕਲਪ ਹੈ ਅਤੇ ਅੰਦਰੂਨੀ ਨੀਤੀ ਪੜ੍ਹਨਯੋਗ ਰੱਖਦਾ ਹੈ, ਪਰ ਇਹ ਪ੍ਰੀਫਿਕਸ ਅਨੁਵਾਦ ਹੈ, ਜਾਦੂਈ ਪਰਤ ਨਹੀਂ: /64 ਸੀਮਾਵਾਂ ਮਿਲਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਚੈੱਕਸਮ ਸਮਾਇਓਜਿਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸ਼ਾਬਦਿਕ ਪਤੇ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਫਿਰ ਵੀ ਟੁੱਟਦੀਆਂ ਹਨ। ਜੇ ਪ੍ਰਦਾਤਾ ਦੇ ਪਤੇ ਸਿਰੇ ਤੋਂ ਸਿਰੇ ਤੱਕ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਪਟੇ ਦਾ ਵਿਵਹਾਰ ਅਤੇ ਤਬਦੀਲੀ ਪ੍ਰਕਿਰਿਆ ਪਤਾ ਯੋਜਨਾ ਵਿੱਚ ਦਰਜ ਕਰੋ।
ਸਮੇਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨ ਵਾਲੀ ਜਾਂਚ ਨਾਲ ਖ਼ਤਮ ਕਰੋ: ਹਰ LAN ਦਾ ਮਨਜ਼ੂਰ ਹੋਸਟ ਦੂਜੇ LAN ਦੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਜਵਾਬ ਟਨਲ ਰਾਹੀਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਜੋੜੀ ਟਨਲ ਮੁੜ-ਚਾਲੂ ਅਤੇ ਡੈਲੀਗੇਸ਼ਨ ਨਵੀਨੀਕਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ। ਜੇ ਆਖਰੀ ਹਿੱਸਾ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਡਿਜ਼ਾਈਨ ਹਫ਼ਤਾ ਨਾ ਟਿਕਣ ਵਾਲੀ ਸਥਿਤੀ 'ਤੇ ਨਿਰਭਰ ਹੈ।