ಎರಡು ಸೈಟ್ಗಳ ನಡುವೆ ಇರುವ VPN ಮೂಲಕ IPv6 ರೂಟಿಂಗ್

IPv4 ಮಾತ್ರ ಇರುವ WAN ಕೂಡ ಒಳಗಿನ IPv6 ಅನ್ನು ಸಾಗಿಸಬಲ್ಲದು. ಸೆಲೆಕ್ಟರ್ಗಳು, ಕರ್ನಲ್ ರೂಟ್ಗಳು, ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಉತ್ತರಗಳನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಸಾಡುವ ಹಿಂತಿರುಗುವ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಗಮನಿಸಿ.

ಎರಡು ಸೈಟ್ಗಳ ನಡುವಿನ ಸುರಂಗಕ್ಕೆ IPv6 ಪ್ರಿಫಿಕ್ಸ್ ಸೇರಿಸಿದಾಗ, ಚಿತ್ರ ಸೂಚಿಸಿದಂತೆ ಪ್ಯಾಕೆಟ್ ಚಲಿಸುವುದಿಲ್ಲ। ಸ್ಥಳೀಯ ಗೇಟ್ವೇ ಇಡೀ IPv6 ಪ್ಯಾಕೆಟ್ ತೆಗೆದುಕೊಂಡು, ಅದನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿ, ಮುಂದೆ ಬಾಹ್ಯ IP ಹೆಡರ್ ಇಡುತ್ತದೆ; ಅದರ ವಿಳಾಸ ಕುಟುಂಬ ಒಳಗಿನ ವಿಷಯದಿಂದ ಅಲ್ಲ, ತುದಿಗಳ ವಿಳಾಸಗಳಿಂದ ನಿರ್ಧಾರವಾಗುತ್ತದೆ। ದೂರದ ಗೇಟ್ವೇ ಆ ಬಾಹ್ಯ ಹೆಡರ್ ತೆಗೆದು ಮೂಲ ಪ್ಯಾಕೆಟ್ ತನ್ನ LANಗೆ ಕಳುಹಿಸುತ್ತದೆ; ಅಲ್ಲಿ ಅದು ಮತ್ತೆ ಸಾಮಾನ್ಯ IPv6 ಪ್ಯಾಕೆಟ್। ಬಾಹ್ಯ ಸುರಂಗ ಮತ್ತು ಒಳಗಿನ ಸಂಚಾರ ಒಂದು ಕೀ, ಒಂದು ತುದಿ ಜೋಡಿ ಮತ್ತು ಬೇರೇನನ್ನೂ ಹಂಚಿಕೊಳ್ಳದ ಎರಡು ಬೇರೆ ಸಂಭಾಷಣೆಗಳು।

ಎರಡು ಹೆಡರ್ಗಳು, ಎರಡು ವಿಳಾಸ ಕುಟುಂಬಗಳು

IPsec ಸುರಂಗ ಮೋಡ್ನಲ್ಲಿ ಒಳಗಿನ IPv6 ಪ್ಯಾಕೆಟ್ ESP ಹೆಡರ್ನ ಹಿಂದಿನ ಪೇಲೋಡ್ ಆಗುತ್ತದೆ। ಆ ESP ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸುವ ಬಾಹ್ಯ ಹೆಡರ್ IPv4 ಅಥವಾ IPv6 ಆಗಿರಬಹುದು; ಅದು local_addrs ಮತ್ತು remote_addrs ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ। WireGuard ಇದೇ ಕೆಲಸವನ್ನು ಕಡಿಮೆ ಆಚರಣೆಯಿಂದ ಮಾಡುತ್ತದೆ: ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಸಹಚರನ ತುದಿಯ ಕಡೆ ಹೋಗುವ UDP ಡೇಟಾಗ್ರಾಮ್ನ ಪೇಲೋಡ್। ಎರಡೂ ಒಳಗಿನ ಹೆಡರ್ ಅನ್ನು ಮುಟ್ಟದೆ ಬಿಡುತ್ತವೆ; ಹಾಗಾಗಿ ದೂರದ ಬದಿ ಡೀಕ್ಯಾಪ್ಸುಲೇಷನ್ ನಂತರ ಅದನ್ನು ರೂಟ್ ಮಾಡಬಲ್ಲದು।

ಸೈಟ್ಗಳ ನಡುವಿನ ಮಾರ್ಗ IPsec NAT ಟ್ರಾವರ್ಸಲ್ ಬಳಸಿದಾಗ UDP 4500 ಅನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ, ಅಥವಾ ಡಿಫಾಲ್ಟ್ 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 , ಅದು ಸುರಂಗ ಸಾಗಿಸುವ ಹೆಡರ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ।

ಸಂಬಂಧಿತ ಲೇಖನಗಳು