Linux ನಲ್ಲಿ ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್ ಮಾಡಿದ ನಂತರ IPv6 ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಮಾಯವಾಯಿತು

IPv6 ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್ ಮಾಡಿದಾಗ kernel ಅಪ್ಲಿಂಕ್‌ನಲ್ಲಿ router announcements ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ, ಕಲಿತ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಅವಧಿ ಮುಗಿಯುತ್ತದೆ. accept_ra ಬಳಸಿ ಸರಿಪಡಿಸಿ.

VPN ಕ್ಲೈಂಟ್‌ಗಳ ಸಂಚಾರವನ್ನು ಮುಂದೆ ಕಳುಹಿಸಲು ನಾನು Debian ಗೇಟ್‌ವೇಯಲ್ಲಿ net.ipv6.conf.all.forwarding=1 ಹೊಂದಿಸಿದೆ, ಮತ್ತು ಸುಮಾರು ಅರ್ಧ ಗಂಟೆಯ ನಂತರ ಯಂತ್ರದಲ್ಲಿ ಯಾವುದೇ IPv6 ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಉಳಿದಿರಲಿಲ್ಲ. ಮೇಲಿನ ರೂಟರ್ ಚಾಲನೆಯಲ್ಲಿತ್ತು, link-local ನೆರೆಹೊರೆಯವರು ಇನ್ನೂ ಉತ್ತರಿಸುತ್ತಿದ್ದರು, ಮತ್ತು ಅಪ್ಲಿಂಕ್ ತನ್ನ ಜಾಗತಿಕ ವಿಳಾಸವನ್ನು ಇನ್ನೂ ಹೊಂದಿತ್ತು. ನಿಂತದ್ದು ಆ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ರೂಟರ್ ಪ್ರಕಟಣೆಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುವ ಕರ್ನಲ್‌ನ ಸಿದ್ಧತೆ. sysctl ಬರೆದ ಕ್ಷಣದಲ್ಲಿ ಮಾರ್ಗ ಮಾಯವಾಗಲಿಲ್ಲ; RA ಯಿಂದ ಕಲಿತ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದ ಆಯುಸ್ಸು ಮುಗಿದಾಗ ಮಾಯವಾಯಿತು ಮತ್ತು ಯಾವುದೂ ಅದನ್ನು ನವೀಕರಿಸಲಿಲ್ಲ.

ಮೊದಲ ನೋಟದಲ್ಲಿ ಏನೂ ಮುರಿದಂತೆ ಕಾಣಲಿಲ್ಲ. ಫಾರ್ವರ್ಡಿಂಗ್ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು, ಹಳೆಯ ಮಾರ್ಗ ಕ್ಯಾಶ್‌ನಲ್ಲಿರುವವರೆಗೆ ಕ್ಲೈಂಟ್‌ಗಳು ಹಾದು ಹೋಗುತ್ತಿದ್ದವು, ಮತ್ತು ವೈಫಲ್ಯ ಅದನ್ನು ಉಂಟುಮಾಡಿದ ಬದಲಾವಣೆಗಿಂತ ನಂತರ ಬಂತು. ಆ ವಿಳಂಬವೇ ಸಮಸ್ಯೆಯನ್ನು ಮೇಲಿನ ಭಾಗ ಅಥವಾ ಎಂದೂ ಒಳಗೊಂಡಿರದ ಫೈರ್‌ವಾಲ್ ನಿಯಮದ ಮೇಲೆ ಹಾಕುವುದಕ್ಕೆ ಕಾರಣ.

ಯಾವುದೇ sysctl ಮುಟ್ಟುವ ಮೊದಲು ಮಾರ್ಗಗಳ ಕೋಷ್ಟಕ ಓದಿ

ip -6 route show default ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಗೇಟ್‌ವೇ ಮಾತ್ರವಲ್ಲ, ಗುಣಲಕ್ಷಣಗಳನ್ನು ಓದಿ. RA ಯಿಂದ ಕಲಿತ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ proto ra ನಿಂದ ಗುರುತಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ಯತೆ ಹೊಂದಿದೆ ಮತ್ತು expires ನ ಹಿನ್ನೆಣಿಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಕೈಯಿಂದ ಸೇರಿಸಿದ ಮಾರ್ಗದಲ್ಲಿ ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಇಲ್ಲ, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸವೇ ಮಾರ್ಗದ ಒಡೆಯ ಯಾವ ವ್ಯವಸ್ಥೆ ಎಂದು ಹೇಳುತ್ತದೆ.

$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref medium

ನಂತರ ವಿಳಾಸ ನೋಡಿ: ip -6 addr show dev eth0. ಗಂಟೆಗಳಲ್ಲಿ ಅಳೆಯಲಾದ ಆದ್ಯತೆಯ ಮತ್ತು ಮಾನ್ಯ ಆಯುಸ್ಸಿನ ಜಾಗತಿಕ ವಿಳಾಸವು, ರೂಟರ್ ಆಯುಸ್ಸು ನಿಮಿಷಗಳಲ್ಲಿ ಅಳೆಯುವ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುತ್ತದೆ. ವಿಳಾಸ ಇದೆ ಆದರೆ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಇಲ್ಲ, ಅದು ಪ್ರಕಟಣೆ ಸಮಸ್ಯೆಯ ಗುರುತು. ವಿಳಾಸವೂ ಇಲ್ಲದಿದ್ದರೆ ಮೊದಲು ಲಿಂಕ್, ಪ್ರಿಫಿಕ್ಸ್ ಮಾಹಿತಿ ಅಥವಾ ನಕಲಿ ವಿಳಾಸ ಪತ್ತೆಯ ಹಿಂದೆ ಬೀಳಬೇಕು.

ಫಾರ್ವರ್ಡಿಂಗ್ RA ಸಂಸ್ಕರಣೆಯನ್ನು ಏಕೆ ನಿಲ್ಲಿಸುತ್ತದೆ

RA ಎಂಬುದು 134 ಬಗೆಯ ICMPv6 ಪ್ಯಾಕೆಟ್, ಇದನ್ನು link-local ಮೂಲದಿಂದ 255 ಹಾಪ್ ಮಿತಿಯೊಂದಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಕರ್ನಲ್ ಅದನ್ನು ಬಳಸುವ ಮೊದಲು ಇಂಟರ್ಫೇಸ್‌ನ accept_ra ಪರಿಶೀಲಿಸುತ್ತದೆ. ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯ 1, ಮತ್ತು 1 ಎಂದರೆ ಹೌದು ಅಲ್ಲ. ಅದರ ಅರ್ಥ: ಈ ಹೋಸ್ಟ್ ಫಾರ್ವರ್ಡ್ ಮಾಡದಿರುವವರೆಗೆ ಮಾತ್ರ ಸ್ವೀಕರಿಸು. forwarding=1 ಹೊಂದಿಸಿ, ಆ ಷರತ್ತು ವಿಫಲವಾಗುತ್ತದೆ, ಹೀಗಾಗಿ ಅದರೊಳಗಿನ ಯಾವುದೇ ಪ್ರಿಫಿಕ್ಸ್ ಅಥವಾ ಡೀಫಾಲ್ಟ್ ರೂಟರ್ ಪರಿಗಣನೆಗೆ ಬರುವ ಮೊದಲೇ ಪ್ರಕಟಣೆ ತಿರಸ್ಕೃತವಾಗುತ್ತದೆ.

ಮೂರು ಮೌಲ್ಯಗಳಿವೆ, ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್‌ನಿಂದ ಮೂರನೆಯದು ಮಾತ್ರ ಉಳಿಯುತ್ತದೆ:

accept_raforwarding=0forwarding=1
0ignoredignored
1 (default)acceptedignored
2acceptedaccepted

ಇನ್ನೆರಡು ಫ್ಲ್ಯಾಗ್‌ಗಳು ನಿಜವಾಗಿ ಏನು ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. accept_ra_defrtr ಪ್ರಕಟಣೆಯಲ್ಲಿನ ಡೀಫಾಲ್ಟ್ ರೂಟರ್ ಮಾರ್ಗವಾಗುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ, ಮತ್ತು accept_ra_pinfo ಪ್ರಿಫಿಕ್ಸ್ ಮಾಹಿತಿ ವಿಳಾಸ ಸಂರಚನೆಗೆ ಬಳಕೆಯಾಗುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. accept_ra_defrtr ಆಫ್ ಮಾಡುವುದು ಫಾರ್ವರ್ಡಿಂಗ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಕಲಿಯದೆ SLAAC ವಿಳಾಸಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳುವ ಸಾಮಾನ್ಯ ದಾರಿ. ಇದು accept_ra ಗಿಂತ ಬೇರೆ ಲಿವರ್, ಮತ್ತು ವಿಳಾಸ ಬೇಕು ಆದರೆ ಮಾರ್ಗ ಬೇಡವಾದಾಗ ಇದನ್ನೇ ಬಳಸುತ್ತಾರೆ. ಕರ್ನಲ್‌ನ IP sysctl ಉಲ್ಲೇಖ ಮೂರನ್ನೂ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.

ಮೂರು ಆದೇಶಗಳಿಂದ ದೃಢೀಕರಿಸಿ

ಮೊದಲು ಲೋಡ್ ಆಗಿದೆ ಎಂದು ನೀವು ಭಾವಿಸುವ ಫೈಲ್ ಬದಲು ಚಾಲ್ತಿಯಲ್ಲಿರುವ ಮೌಲ್ಯಗಳನ್ನು ಓದಿ:

sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
       net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtr

ಎರಡನೆಯದಾಗಿ, ಪ್ರಕಟಣೆಗಳು ಇನ್ನೂ ಬರುತ್ತಿವೆ ಎಂದು ಸಾಬೀತು ಮಾಡಿ. ICMPv6 ಬಗೆಯ ಬೈಟ್‌ನಲ್ಲಿ ಫಿಲ್ಟರ್ ಮಾಡುವುದು ಸಾಕು, ಮತ್ತು ಅದು ನೆರೆಹೊರೆ ಪತ್ತೆಯ ಸಂಚಾರದ ಗೋಡೆ ಓದುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ:

tcpdump -ni eth0 'icmp6 and ip6[40] == 134'

ಕೆಲವು ನಿಮಿಷಗಳಲ್ಲಿ ಏನೂ ಕಾಣದಿದ್ದರೆ accept_ra ನಿಮ್ಮ ಸಮಸ್ಯೆ ಅಲ್ಲ. ಮೇಲಿನ ಭಾಗ ಪ್ರಕಟಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿತು, ದಾರಿಯಲ್ಲಿ ಏನೋ ICMPv6 ಫಿಲ್ಟರ್ ಮಾಡುತ್ತಿದೆ, ಅಥವಾ ಆ ಇಂಟರ್ಫೇಸ್ ನೀವು ಭಾವಿಸುವ ವಿಭಾಗದಲ್ಲಿಯೇ ಇಲ್ಲ. ಮೂರನೆಯದಾಗಿ, ನೀವೇ ಒಂದು ಪ್ರಕಟಣೆ ಕೇಳಿ ಮತ್ತು ಅದರ ಕ್ಷೇತ್ರಗಳನ್ನು ಓದಿ:

rdisc6 eth0

rdisc6 Debian ಮತ್ತು Ubuntu ನಲ್ಲಿ ndisc6 ಪ್ಯಾಕೇಜ್‌ನಲ್ಲಿ ಬರುತ್ತದೆ. ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಬೇರೆ ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ರೂಟರ್ ಆಯುಸ್ಸು ಮತ್ತು ಆದ್ಯತೆ ನೋಡಿ. ರೂಟರ್ ಆಯುಸ್ಸು 0 ಇರುವ ಪ್ರಕಟಣೆ ಡೀಫಾಲ್ಟ್ ರೂಟರ್ ತೆಗೆದುಹಾಕುವ ಆದೇಶ, ಮತ್ತು accept_ra ನ ಯಾವುದೇ ಮೌಲ್ಯ ಅದನ್ನು ಬಳಸಬಹುದಾದ ಮಾರ್ಗವಾಗಿಸುವುದಿಲ್ಲ. ಹೀಗೆಯೇ ಸೇತುವೆ ಕ್ರಮದಲ್ಲಿರುವ ಮೇಲಿನ CPE ಕೂಡ ಸಿಗುತ್ತದೆ, ಅದು ಪ್ರಿಫಿಕ್ಸ್ ಹಂಚುತ್ತದೆ ಆದರೆ ತನ್ನನ್ನು ಎಂದೂ ರೂಟರ್ ಆಗಿ ನೀಡುವುದಿಲ್ಲ.

ಅಪ್ಲಿಂಕ್ ಅನ್ನೇ ಏಕೈಕ ಅನುಮತಿಸುವ ಇಂಟರ್ಫೇಸ್ ಮಾಡಿ

ಮೇಲಿನ ಭಾಗವೇ ಡೀಫಾಲ್ಟ್ ರೂಟರ್ ಆಗಬೇಕಿದ್ದರೆ, ಫಾರ್ವರ್ಡಿಂಗ್ ಇದ್ದರೂ ಅಲ್ಲೇ ಪ್ರಕಟಣೆಗಳನ್ನು ಸ್ವೀಕರಿಸಿ, ಬೇರೆ ಎಲ್ಲೂ ಅಲ್ಲ:

# /etc/sysctl.d/60-ipv6-router.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_defrtr = 1

ಮಿತಿ ನಿಗದಿ ಮುಖ್ಯ ಏಕೆಂದರೆ Linux ನಲ್ಲಿ IPv6 ಫಾರ್ವರ್ಡಿಂಗ್ ಒಂದೇ ಜಾಗತಿಕ ಸ್ವಿಚ್, ಪ್ರತಿ ಲಿಂಕ್‌ಗೆ ಒಂದಲ್ಲ. net.ipv6.conf.wg0.forwarding ಗೆ 1 ಬರೆಯಿರಿ ಮತ್ತು ನಂತರ net.ipv6.conf.all.forwarding ಓದಿ: ಜಾಗತಿಕ ಮೌಲ್ಯ ತಿರುಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ನೀವು ಸುರಂಗದಲ್ಲಿ ರೂಟರ್ ಮತ್ತು LAN ನಲ್ಲಿ ಸಾಮಾನ್ಯ ಹೋಸ್ಟ್ ಆಗಿರಲು ಸಾಧ್ಯವಿಲ್ಲ. ನೀವು ಮಿತಿಗೊಳಿಸಬಹುದಾದದ್ದು ಸ್ವೀಕೃತಿ. accept_ra=2 ಅನ್ನು ಅಪ್ಲಿಂಕ್‌ನಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಸುರಂಗ ಹಾಗೂ LAN ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು 1 ಅಥವಾ 0 ನಲ್ಲಿ ಬಿಡಿ, ಇದರಿಂದ ಸುರಂಗದ ಮೂಲಕ ಬಂದ ದಾರಿತಪ್ಪಿದ ಪ್ರಕಟಣೆ ಅದರೊಳಗೆ ತೋರುವ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸಲಾಗದು.

ತಾತ್ಕಾಲಿಕ sysctl -w ಮುಂದಿನ ಬೂಟ್‌ವರೆಗೆ ಉಳಿಯುವುದಿಲ್ಲ, ಮತ್ತು systemd-networkd ಹಾಗೂ NetworkManager ಎರಡೂ ಈ ಮೌಲ್ಯಗಳನ್ನು ತಮ್ಮದೇ ಸಂರಚನೆಯಿಂದ ಬರೆಯುತ್ತವೆ. networkd ನಲ್ಲಿ ಅಪ್ಲಿಂಕ್‌ನ .network ಫೈಲ್‌ನಲ್ಲಿ IPv6Forwarding=yes ಮತ್ತು IPv6AcceptRA=yes ಹೊಂದಿಸಿ; networkd ಕರ್ನಲ್‌ನ ಅದೇ ಕಾರಣಕ್ಕೆ IPv6Forwarding ಅನ್ನು ಜಾಗತಿಕ ಎಂದು ದಾಖಲಿಸುತ್ತದೆ. NetworkManager ನಲ್ಲಿ ಅಪ್ಲಿಂಕ್‌ನ ipv6.method=auto ಎಂಬುದೇ accept_ra ಮೌಲ್ಯವನ್ನು ನಡೆಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೊದಲ ಪರಿಶೀಲನೆಯನ್ನು ನಂಬುವ ಬದಲು nmcli connection up ನಂತರ sysctl ಮತ್ತೆ ಓದಿ.

ಸ್ಥಿರ ಪರ್ಯಾಯ ip -6 route add default via fe80::1 dev eth0 ನಿಜವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಮೇಲಿನ ರೂಟರ್‌ಗೆ ಸ್ಥಿರ link-local ವಿಳಾಸ ಇದ್ದಾಗ ಅದು ಸೂಕ್ತ ಉತ್ತರ. ನೀವು ಏನನ್ನು ಬಿಟ್ಟುಕೊಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದು ಸ್ಪಷ್ಟವಿರಲಿ. ಸ್ಥಿರ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಎಂದೂ ನವೀಕರಣಗೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಎಂದೂ ಹಿಂಪಡೆಯಲ್ಪಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಮೇಲಿನ ಭಾಗ ಬದಲಾದ ನಂತರವೂ ಅದು ಸತ್ತ ನೆರೆಹೊರೆಯವರ ಕಡೆ ತೋರಿಸುತ್ತಲೇ ಇರುತ್ತದೆ. RA ಮಾರ್ಗ ಸುರಕ್ಷಿತವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ; ಸ್ಥಿರವಾದದ್ದು ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ.

ಫಾರ್ವರ್ಡ್ ಆದ ಪ್ಯಾಕೆಟ್ ಪರೀಕ್ಷಿಸಿ, ಗೇಟ್‌ವೇಯದ್ದಲ್ಲ

ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಪಿಂಗ್‌ಗಳು ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಬಳಸಲಾಗದ ಮಾರ್ಗದಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಬಹುದು, ಮತ್ತು ಗೇಟ್‌ವೇ ಮೂಲವಾದ್ದರಿಂದಲೂ ಯಶಸ್ವಿಯಾಗಬಹುದು. ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಆ ಕ್ಲೈಂಟ್‌ನ ವಿಳಾಸಕ್ಕೆ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಗೇಟ್‌ವೇಯನ್ನು ಕೇಳಿ:

# on the VPN client
ping -6 -c 3 2001:4860:4860::8888

# on the gateway, using a client address
ip -6 route get 2001:4860:4860::8888 from fd42:20::2

ನಂತರ ಒಂದು ರೂಟರ್ ಆಯುಸ್ಸು ಕಾಯಿರಿ ಮತ್ತೆ ನೋಡಿ. ನಿಮಗೆ ಬೇಕಾದ ಸ್ಥಿರ ಸ್ಥಿತಿ ಎಂದರೆ proto ra ನಿಂದ ಗುರುತಿಸಲಾದ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ, ಅದರ expires ಮೌಲ್ಯ ಪದೇ ಪದೇ ಮರುಹೊಂದಿಸುತ್ತದೆ, ಜೊತೆಗೆ all.forwarding=1. expires ಕೇವಲ ಹಿನ್ನೆಣಿಕೆ ಮಾಡುತ್ತಿದ್ದರೆ, ಪ್ರಕಟಣೆಗಳು ಇನ್ನೂ ಎಲ್ಲೋ ತಿರಸ್ಕೃತವಾಗುತ್ತಿವೆ, ಮತ್ತು ಸಾಮಾನ್ಯ ಅಪರಾಧಿ ಎಂದರೆ ಬೂಟ್ ಸಮಯದ sysctl ಈಗಾಗಲೇ ಓಡಿದ ನಂತರ accept_ra ಅನ್ನು ಮತ್ತೆ ಬರೆಯುವ ನೆಟ್‌ವರ್ಕ್ ವ್ಯವಸ್ಥಾಪಕ.

ಇದನ್ನು ಮುಚ್ಚುವ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ದೃಢೀಕರಿಸಿ: ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ proto ra ಮತ್ತು ನವೀಕರಣಗೊಳ್ಳುತ್ತಿದೆ, accept_ra=2 ಅಪ್ಲಿಂಕ್‌ಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ, ಮರುಬೂಟ್ ಮತ್ತು ವ್ಯವಸ್ಥಾಪಕ ಮರುಪ್ರಾರಂಭದ ನಂತರವೂ ಫಾರ್ವರ್ಡಿಂಗ್ 1 ಆಗಿದೆ, ಮತ್ತು IPv6 ಪಿಂಗ್ ಅನ್ನು ಕ್ಲೈಂಟ್ ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ, ಗೇಟ್‌ವೇ ಅಲ್ಲ. ಆರೋಗ್ಯಕರ ಮಾರ್ಗ ಇದ್ದರೂ ಕ್ಲೈಂಟ್ ವಿಫಲವಾದರೆ ಮುಂದಿನ ಸಂಶಯಾಸ್ಪದ ವಿಷಯ ಮರಳು ದಾರಿ ಅಥವಾ ಮೇಲಿನ ಫೈರ್‌ವಾಲ್, ಪ್ರಕಟಣೆ ಅಲ್ಲ.

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