ਦੋ ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਮੌਜੂਦਾ VPN ਰਾਹੀਂ IPv6 ਰੂਟਿੰਗ

ਸਿਰਫ਼ IPv4 ਵਾਲਾ WAN ਵੀ ਅੰਦਰੂਨੀ IPv6 ਲੈ ਜਾ ਸਕਦਾ ਹੈ। ਸਿਲੈਕਟਰ, ਕਰਨਲ ਰੂਟ, ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਜਵਾਬ ਚੁੱਪਚਾਪ ਸੁੱਟਣ ਵਾਲਾ ਵਾਪਸੀ ਪ੍ਰੀਫਿਕਸ ਵੇਖੋ।

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

ਦੋ ਹੈਡਰ, ਦੋ ਪਤਾ ਪਰਿਵਾਰ

IPsec ਟਨਲ ਮੋਡ ਵਿੱਚ ਅੰਦਰੂਨੀ IPv6 ਪੈਕਟ ESP ਹੈਡਰ ਪਿੱਛੇ ਦਾ ਪੇਲੋਡ ਬਣ ਜਾਂਦਾ ਹੈ। ਉਹ ESP ਪੈਕਟ ਲਿਜਾਣ ਵਾਲਾ ਬਾਹਰੀ ਹੈਡਰ IPv4 ਜਾਂ IPv6 ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ local_addrs ਤੇ remote_addrs ਦੀ ਪੈਰਵੀ ਕਰਦਾ ਹੈ। WireGuard ਉਹੀ ਕੰਮ ਘੱਟ ਰਸਮ ਨਾਲ ਕਰਦਾ ਹੈ: ਅੰਦਰੂਨੀ ਪੈਕਟ ਸਾਥੀ ਦੇ ਸਿਰੇ ਵੱਲ ਜਾਣ ਵਾਲੇ UDP ਡੇਟਾਗ੍ਰਾਮ ਦਾ ਪੇਲੋਡ ਹੈ। ਦੋਵੇਂ ਅੰਦਰੂਨੀ ਹੈਡਰ ਨੂੰ ਅਛੂਤਾ ਛੱਡਦੇ ਹਨ, ਇਸ ਲਈ ਦੂਰ ਦਾ ਪਾਸਾ ਡੀਕੈਪਸੂਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਰੂਟ ਕਰ ਸਕਦਾ ਹੈ।

ਸਾਈਟਾਂ ਵਿਚਕਾਰਲਾ ਰਾਹ ਸਿਰਫ਼ UDP 4500 ਵੇਖਦਾ ਹੈ ਜਦੋਂ IPsec NAT ਟ੍ਰੈਵਰਸਲ ਵਰਤਦਾ ਹੈ, ਜਾਂ ਡਿਫਾਲਟ WireGuard ਸਰੋਤੇ ਲਈ UDP 51820। ਰਾਹ ਉੱਤੇ ਕੋਈ ਵੀ ਰਾਊਟਰ ਸਿਰਫ਼ IPv4 ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ IPv6 ਟ੍ਰੈਫਿਕ ਫਿਰ ਵੀ ਪਾਰ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਉਸ ਰਾਹ ਉੱਤੇ ਕਦੇ IPv6 ਪੈਕਟ ਵਜੋਂ ਨਹੀਂ ਦਿਸਦਾ। ਇਹ ਸਾਫ਼ ਪਹਿਲੀ ਵੰਡ ਦਿੰਦਾ ਹੈ: tcpdump -ni eth0 udp port 51820 ਐਨਕ੍ਰਿਪਟਡ ਰਾਹ ਦਿਖਾਉਂਦਾ ਹੈ, tcpdump -ni wg0 ip6 ਅੰਦਰੂਨੀ ਟ੍ਰੈਫਿਕ ਦਿਖਾਉਂਦਾ ਹੈ। ਬਾਹਰੀ ਕੈਪਚਰ ਰੁੱਝਿਆ ਅਤੇ ਅੰਦਰੂਨੀ ਚੁੱਪ ਹੋਵੇ ਤਾਂ ਮਤਲਬ ਕਰਨਲ IPv6 ਟਨਲ ਵਿੱਚ ਨਹੀਂ ਪਾ ਰਿਹਾ; ਇਹ ਰੂਟਿੰਗ ਜਾਂ ਨੀਤੀ ਹੈ, ਲਿੰਕ ਦੀ ਹਾਲਤ ਨਹੀਂ।

ਗੇਟਵੇ ਫਾਰਵਰਡ ਕਰਦਿਆਂ ਅੰਦਰੂਨੀ Hop Limit ਵੀ ਘਟਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਸਿਰੇ IPv6 ਰਾਹ ਉੱਤੇ ਰਾਊਟਰ ਗਿਣੇ ਜਾਂਦੇ ਹਨ। ਬਾਹਰੀ ਹਾਪ ਗਿਣਤੀ ਅਤੇ ਅੰਦਰੂਨੀ Hop Limit ਵੱਖਰੇ ਚੱਲਦੇ ਹਨ, ਅਤੇ ਦੂਰ ਦੇ ਗੇਟਵੇ ਉੱਤੇ ਮਰਨ ਵਾਲਾ ਪੈਕਟ ਫਾਰਵਰਡਿੰਗ ਵਿੱਚ ਮਰਿਆ, ਐਨਕ੍ਰਿਪਸ਼ਨ ਵਿੱਚ ਨਹੀਂ।

ਸਿਲੈਕਟਰ ਅਤੇ AllowedIPs ਇਜਾਜ਼ਤ ਸੂਚੀ ਹਨ

IKEv2 ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ child SA ਕਿਹੜੇ ਅੰਦਰੂਨੀ ਪ੍ਰੀਫਿਕਸ ਲੈ ਜਾ ਸਕਦਾ ਹੈ। strongSwan 5.9 ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ swanctl.conf ਵਿੱਚ ਲਿਖਣਾ ਇੰਝ ਦਿਸਦਾ ਹੈ:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

ਜੇ local_ts ਅਤੇ remote_ts ਛੱਡ ਦਿਓ ਤਾਂ strongSwan ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਚੁਣੇ ਹੋਏ ਇੰਟਰਫੇਸ ਦੇ ਸਬਨੈੱਟ ਤੋਂ ਕੱਢਦਾ ਹੈ। ਦੋਹਰੇ ਸਟੈਕ ਵਾਲੇ ਹੋਸਟ ਉੱਤੇ ਉਹ ਸ਼ਾਰਟਕਟ ਅਕਸਰ ਸਿਰਫ਼ IPv4 ਦੀ ਜੋੜੀ ਦਿੰਦਾ ਹੈ: SA ਉੱਪਰ ਉੱਠਦਾ ਹੈ ਅਤੇ IPv6 ESP ਕੋਡ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਰੱਦ ਹੋ ਜਾਂਦਾ ਹੈ। ਦੋਵੇਂ ਪ੍ਰੀਫਿਕਸ ਲਿਖਣਾ SA ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਲਿਜਾਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ start_action = trap ਇਸਨੂੰ ਪਹਿਲੇ ਮਿਲਦੇ ਪੈਕਟ ਉੱਤੇ ਉੱਪਰ ਚੁੱਕਦਾ ਹੈ।

WireGuard ਕੋਲ ਇੱਕ ਹੀ ਸੂਚੀ ਹੈ ਜੋ ਦੋ ਕੰਮ ਕਰਦੀ ਹੈ। ਸਾਥੀ ਬਲਾਕ ਵਿੱਚ AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 ਭੇਜਦਿਆਂ ਲਾਇਆ ਰਾਹ ਵੀ ਹੈ ਅਤੇ ਲੈਂਦਿਆਂ ਲਾਇਆ ਫਿਲਟਰ ਵੀ: ਜਿਸ ਡੀਕ੍ਰਿਪਟ ਹੋਏ ਪੈਕਟ ਦਾ ਅੰਦਰੂਨੀ ਸਰੋਤ ਉਸ ਸਾਥੀ ਦੀ ਸੂਚੀ ਤੋਂ ਬਾਹਰ ਪੈਂਦਾ ਹੈ ਉਹ ਚੁੱਪਚਾਪ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। wg-quick ਹਰ ਐਂਟਰੀ ਲਈ ਰਾਹ ਜੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਹੇਠਲੇ ਸਾਥੀ ਬਲਾਕ ਨੂੰ ਵੱਖਰੀ ip -6 route ਕਮਾਂਡ ਦੀ ਲੋੜ ਨਹੀਂ।

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

ਦੋਵੇਂ ਸੂਚੀਆਂ ਸ਼ੀਸ਼ੇ ਵਰਗੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਸਾਈਟ B ਸਾਈਟ A ਦਾ ਪ੍ਰੀਫਿਕਸ ਦੂਰ ਦਾ ਸਿਲੈਕਟਰ ਮੰਨ ਕੇ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਵਾਪਸ ਰੂਟ ਕਰਦੀ ਹੈ, ਅਤੇ ਟਨਲ ਤਦ ਹੀ ਚੱਲਦਾ ਹੈ ਜਦੋਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਸਹਿਮਤ ਹੋਣ। ਅਸਮਿਤ ਸੂਚੀ ਉਹ ਲੱਛਣ ਦਿੰਦੀ ਹੈ ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਂਦਾ ਹੈ — ਸਿਹਤਮੰਦ ਹੈਂਡਸ਼ੇਕ, ਇੱਕ ਪਾਸੇ ਚੱਲਦੇ ਕਾਊਂਟਰ, ਅਤੇ A ਤੋਂ B ਤੱਕ ਕਾਮਯਾਬ ping ਜਦੋਂ ਕਿ B ਤੋਂ ਕੁਝ ਵੀ A ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ।

ਫਾਰਵਰਡਿੰਗ, ਰੂਟ ਅਤੇ ਵਾਪਸੀ ਪ੍ਰੀਫਿਕਸ

Linux ਤੁਸੀਂ ਕਹੋ ਤੱਕ IPv6 ਫਾਰਵਰਡ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਸੈਟਿੰਗ ਇੰਟਰਫੇਸ ਦੀ ਥਾਂ namespace ਮੁਤਾਬਕ ਹੈ:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

ਦੂਜੀ ਲਾਈਨ ਉਹੀ ਹੈ ਜੋ ਰੂਟ ਅਧਾਰਿਤ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚ ਲੋਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ। ਨੀਤੀ ਅਧਾਰਿਤ IPsec ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਮਿਲਦੀ XFRM ਨੀਤੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਪਰ vti6 ਜਾਂ WireGuard ਵਾਲੀ ਰੂਟ ਅਧਾਰਿਤ ਸੈਟਅਪ ਨੂੰ ਉਸ ਡਿਵਾਈਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਅਸਲੀ IPv6 ਰਾਹ ਚਾਹੀਦਾ ਹੈ। sysctl ਨੂੰ /etc/sysctl.d/ ਹੇਠ ਟਿਕਾਊ ਰੱਖੋ; ਨਹੀਂ ਤਾਂ ਮੁੜ ਬੂਟ ਫਾਰਵਰਡਿੰਗ ਚੁੱਪਚਾਪ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।

ਫਾਰਵਰਡਿੰਗ ਦਾ ਇੱਕ ਮਾੜਾ ਪ੍ਰਭਾਵ ਹੈ ਜੋ ਜਾਣਨ ਯੋਗ ਹੈ: ਕਰਨਲ ਤਦ ਰਾਊਟਰ ਐਲਾਨ ਅਣਗੌਲੇ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ net.ipv6.conf.<wan>.accept_ra 2 ਨਾ ਹੋਵੇ, ਇਸ ਲਈ ਜਿਸ ਗੇਟਵੇ ਦਾ WAN ਪਤਾ SLAAC ਰਾਹੀਂ ਆਉਂਦਾ ਹੈ ਉਹ ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ ਕਰਦਿਆਂ ਹੀ ਆਪਣਾ ਡਿਫਾਲਟ ਰਾਹ ਗੁਆ ਸਕਦਾ ਹੈ। ਉਸੇ ਫਾਈਲ ਵਿੱਚ ਉਸ ਇੰਟਰਫੇਸ ਉੱਤੇ accept_ra = 2 ਸੈਟ ਕਰੋ ਅਤੇ ਰਾਹ ਬਚਿਆ ਰਹਿੰਦਾ ਹੈ। ਸਾਈਟ B ਦੇ ਕੋਰ ਨੂੰ ਵੀ ਟਨਲ ਗੇਟਵੇ ਤੋਂ 2001:db8:aa::/48 ਸਿੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਥਿਰ ਰਾਹ ਜਾਂ ਟਨਲ ਉੱਤੇ ਰੂਟਿੰਗ ਪ੍ਰੋਟੋਕੋਲ ਰਾਹੀਂ, ਨਹੀਂ ਤਾਂ ਜਵਾਬ B ਦੇ ਆਪਣੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਮਰ ਜਾਂਦਾ ਹੈ।

ਟੁੱਟਣ ਦੀ ਥਾਂ ਲੱਭਣ ਵਾਲੀ ਚਾਰ ਪੜਾਵਾਂ ਦੀ ਜਾਂਚ

ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਕੰਮ ਕਰੋ ਅਤੇ ਪਹਿਲੇ ਅਸਫਲ ਪੜਾਅ ਉੱਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਹਰ ਅਗਲਾ ਪੜਾਅ ਪਿਛਲਿਆਂ ਉੱਤੇ ਨਿਰਭਰ ਹੈ।

  1. ਸਿਲੈਕਟਰ: swanctl --list-sas ਨੂੰ child SA ਉੱਤੇ IPv6 ਪ੍ਰੀਫਿਕਸ ਦੀ ਜੋੜੀ ਦਿਖਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਜਾਂ wg show wg0 allowed-ips ਨੂੰ ਦੂਰ ਦਾ ਪ੍ਰੀਫਿਕਸ ਤਾਜ਼ਾ latest-handshakes ਨਾਲ।
  2. ਕਰਨਲ ਰੂਟ: ip -6 route get 2001:db8:bb::10 ਨੂੰ ਟਨਲ ਡਿਵਾਈਸ ਨਾਲ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, WAN ਇੰਟਰਫੇਸ ਨਾਲ ਨਹੀਂ।
  3. ਅੰਦਰੂਨੀ ਕੈਪਚਰ: tcpdump -ni wg0 ip6 ਅਸਲੀ LAN ਹੋਸਟਾਂ ਵਿਚਕਾਰ ping ਕਰਦਿਆਂ। ਜੋ ਪੈਕਟ ਬਾਹਰ ਜਾਂਦੇ ਹਨ ਪਰ ਕੋਈ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ ਉਹ B ਦੇ ਰਾਹ ਜਾਂ ਫਾਇਰਵਾਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ; ਬਿਲਕੁਲ ਪੈਕਟ ਨਾ ਹੋਣਾ ਪੜਾਅ 1 ਜਾਂ 2 ਵੱਲ ਵਾਪਸ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
  4. ਮੰਜ਼ਿਲ: B ਹੋਸਟ ਉੱਤੇ ss -6 -ltn ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਸੇਵਾ IPv6 ਉੱਤੇ ਸੁਣ ਰਹੀ ਹੈ, ਅਤੇ ਸਥਾਨਕ ਫਾਇਰਵਾਲ ਕਾਊਂਟਰ ਦੱਸਦੇ ਹਨ ਕਿ ਪੈਕਟ ਸਵੀਕਾਰ ਹੋਇਆ ਜਾਂ ਸੁੱਟਿਆ ਗਿਆ।

MTU ਉਸੇ ਦੌਰ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। IPv6 ਰਾਊਟਰ ਖੰਡਨ ਨਹੀਂ ਕਰਦੇ, ਇਸ ਲਈ ਬਹੁਤ ਵੱਡਾ ਪੈਕਟ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ Packet Too Big ਭੇਜਣ ਵਾਲੇ ਕੋਲ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਜੇ ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਛੋਟੇ ping ਚੱਲਦੇ ਹਨ ਪਰ ਫਾਈਲ ਟ੍ਰਾਂਸਫਰ ਅਟਕਦਾ ਹੈ, ਤਾਂ ਪੇਲੋਡ ਘਟਾਓ ਜਦ ਤੱਕ ਉਹ ਪਾਰ ਨਾ ਹੋਵੇ: ping -6 -s 1400 -c 3 2001:db8:bb::10। WireGuard ਇੰਟਰਫੇਸ ਦਾ ਡਿਫਾਲਟ MTU 1420 ਬਾਈਟ ਹੈ ਅਤੇ IPv4 ਉੱਤੇ IPsec ਹੋਰ ਕੱਟਦਾ ਹੈ, ਇਸ ਲਈ ਅੰਦਰੂਨੀ MTU ਸੈਟ ਕਰਨਾ ICMPv6 ਸੁੱਟਣ ਵਾਲੇ ਫਾਇਰਵਾਲ ਰਾਹੀਂ ਰਾਹ ਦਾ MTU ਲੱਭਣ ਦੀ ਆਸ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।

ਫਾਇਰਵਾਲ ਦੀ ਸਮੱਸਿਆ ਵਰਗੇ ਦਿਸਦੇ ਅਸਫਲਤਾ ਦੇ ਢੰਗ

ਸਭ ਤੋਂ ਆਮ ਤਾਂ ਫਾਇਰਵਾਲ ਹੀ ਨਹੀਂ: ਸੇਵਾ :: ਦੀ ਥਾਂ 0.0.0.0 ਨਾਲ ਬੱਝਦੀ ਹੈ, AAAA ਰਿਕਾਰਡ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਗਾਹਕ ਨੂੰ IPv6 ਉੱਤੇ ਤੇਜ਼ ਇਨਕਾਰ ਮਿਲਦਾ ਹੈ ਜਿਸਨੂੰ ਦੋਹਰੇ ਸਟੈਕ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ IPv4 ਉੱਤੇ ਵਾਪਸ ਜਾ ਕੇ ਲੁਕਾਉਂਦਾ ਹੈ। ਜੇ ਸਿਰਫ਼ ਕੁਝ ਐਪਲੀਕੇਸ਼ਨ ਅਸਫਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਨਿਯਮ-ਸਮੂਹ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਸੁਣਨ ਵਾਲਾ ਪਰਿਵਾਰ ਵੇਖੋ।

ਦੂਜਾ ICMPv6 ਫਿਲਟਰਿੰਗ ਹੈ। Neighbor Discovery ਅਤੇ Packet Too Big ਆਮ ਸੰਚਾਲਨ ਦਾ ਹਿੱਸਾ ਹਨ, ਨਿਦਾਨ ਦਾ ਨਹੀਂ, ਅਤੇ ਜੋ ਨੀਤੀ ਸਾਰਾ ICMPv6 ਸੁੱਟਦੀ ਹੈ ਉਹ ਅਜਿਹਾ ਟਨਲ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਜੁੜਦਾ ਹੈ, ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਛੋਟੇ ਪੈਕਟ ਨਾਲੋਂ ਵੱਡੀ ਹਰ ਚੀਜ਼ ਉੱਤੇ ਅਟਕ ਜਾਂਦਾ ਹੈ। ਜਿਨ੍ਹਾਂ ਕਿਸਮਾਂ ਉੱਤੇ ਰਾਹ ਨਿਰਭਰ ਹੈ ਉਹਨਾਂ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿਓ ਅਤੇ ਕਾਊਂਟਰ ਚਾਲੂ ਰਹਿਣ ਦਿਓ ਤਾਂ ਜੋ ਸੁੱਟਿਆ ਜਾਣਾ ਦਿਸੇ।

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

ਸੰਬੰਧਿਤ ਲੇਖ