OpenVPN ಮರುಪ್ರಾರಂಭದ ನಂತರ IPv6 ನಿರ್ಗಮನ ಸಾಯುತ್ತದೆ: ಪ್ರಿಫಿಕ್ಸ್ ಮಾಲೀಕತ್ವವನ್ನು ಪರಿಶೀಲಿಸಿ
ಸುರಂಗ ಮತ್ತೆ ರಚಿಸಲಾದ ನಂತರ IPv6 ಸಾಯುತ್ತದೆ. ಯಾವುದನ್ನೂ ಮರುಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ನಿಯೋಜಿತ ಪ್ರಿಫಿಕ್ಸ್, ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳು ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಯಾರಿಗೆ ಸೇರಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿ.
IPv6 ಸಂಚಾರವನ್ನು ಹಾದುಹೋಗಲು ಬಿಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ OpenVPN ಮರುಪ್ರಾರಂಭವಾಗುವ ಕ್ಷಣದಲ್ಲಿ, ಮತ್ತು IPv4 ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ. ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್ ಮತ್ತೆ ರಚಿಸಲ್ಪಟ್ಟಿತು, ಮತ್ತು ಅದರ IPv6 ಸ್ಥಿತಿಯನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದ ಬೇರೆ ಯಾವುದೋ ವಿಳಾಸವನ್ನು ಕಳೆದುಕೊಂಡಿತು ಅಥವಾ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ತಲುಪಬಹುದಾದಂತೆ ಮಾಡುವ ಮಾರ್ಗವನ್ನು ಕಳೆದುಕೊಂಡಿತು. ಮೂರು ಪ್ರತ್ಯೇಕ ಸ್ಥಿತಿ ಭಾಗಗಳು ಒಳಗೊಂಡಿವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಮಾಲೀಕರಿದ್ದಾರೆ: ಪೂರೈಕೆದಾರರ ನಿಯೋಜಿತ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಅದರ ಜೀವಿತಾವಧಿ, VPN ಕ್ಲೈಂಟ್ಗಳಿಗೆ ನೀಡಿದ ವಿಳಾಸಗಳು, ಮತ್ತು ಆ ಕ್ಲೈಂಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಸರ್ವರ್ಗೆ ಹಿಂತಿರುಗಿಸುವ ಮೇಲ್ಮುಖ ಮಾರ್ಗ. ಯಾವುದೇ ಡೀಮನ್ ಅನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಪ್ರತಿಯೊಂದರ ಮಾಲೀಕರನ್ನು ಗುರುತಿಸಿ, ಏಕೆಂದರೆ ತಪ್ಪಾದದನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು ಸಮಸ್ಯೆಯನ್ನು ಒಂದು ದಿನ ಮರೆಮಾಡಿ ಮುಂದಿನ ಸಂಪರ್ಕದಲ್ಲಿ ಮರಳಿ ತರುತ್ತದೆ.
IPv6 ಸ್ಥಿತಿಯ ಮೂರು ಭಾಗಗಳು, ಮೂರು ಮಾಲೀಕರು
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
ಸುರಂಗದ ಒಳಗಿನ ಜಾಗತಿಕ ವ್ಯಾಪ್ತಿಯ ವಿಳಾಸವೊಂದೇ ಸಾಕಾಗುವುದಿಲ್ಲ. ಮೇಲ್ಮುಖ ಮಾರ್ಗನಿರ್ದೇಶಕಗಳು ಆ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು VPN ಸರ್ವರ್ಗೆ ಹಿಂತಿರುಗಿ ಕಳುಹಿಸಬೇಕು, ಮತ್ತು ಸರ್ವರ್ನಲ್ಲಿ ಅದರಿಂದ ಒಂದು ವಿಳಾಸ ಇದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಅವರು ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ.
ಅದಕ್ಕೇ ಸಾರ್ವಜನಿಕ /64 ಅನ್ನು ಸುರಂಗದ ಕೊಳಕ್ಕೆ ನಕಲಿಸುವುದು ಅಪಾಯಕಾರಿ. ಸರ್ವರ್ಗೆ ಮಾರ್ಗನಿರ್ದೇಶಿಸಿದ ಪ್ರಿಫಿಕ್ಸ್ ಎಂಬುದು ಮೇಲ್ಮುಖ ಭಾಗ on-link ಎಂದು ಪರಿಗಣಿಸುವ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಸಮನಲ್ಲ, ಮತ್ತು ನೆರೆಹೊರೆಯ ಅನ್ವೇಷಣೆ ಈ ಅಂತರವನ್ನು ತುಂಬುವುದಿಲ್ಲ.
ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಸರ್ವರ್ನ ಸ್ಥಿತಿಯನ್ನು ಓದಿ
ಸ್ಥಿತಿಯನ್ನು ಎರಡು ಬಾರಿ ಸೆರೆಹಿಡಿಯಿರಿ, ಒಮ್ಮೆ IPv6 ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ ಮತ್ತು ಒಮ್ಮೆ ಮರುಪ್ರಾರಂಭದ ನಂತರ, ನಂತರ ಹೋಲಿಸಿ. ಓದಲು ಮಾತ್ರವಾದ ನೋಟಗಳು ಸಾಕು, ಮತ್ತು ನಿರ್ವಹಣಾ ಅವಧಿಯಲ್ಲಿ ಅವು ಏನೂ ವೆಚ್ಚ ಮಾಡುವುದಿಲ್ಲ:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingಮೂರು ನಿರ್ದಿಷ್ಟ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹುಡುಕಿ: ಕಣ್ಮರೆಯಾದ ಮಾರ್ಗ, ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಅಥವಾ ಅಮಾನ್ಯ ಜೀವಿತಾವಧಿಗೆ ಹೋದ ವಿಳಾಸ, ಮತ್ತು ಮರುನಿಯೋಜನೆಯ ನಂತರ ಬದಲಾದ ಪ್ರಿಫಿಕ್ಸ್, ಆದರೆ VPN ಸಂರಚನೆ ಇನ್ನೂ ಹಳೆಯದನ್ನು ಘೋಷಿಸುತ್ತಿದೆ.
ವಿಳಾಸ ಕಣ್ಮರೆಯಾದರೂ ಪ್ರಿಫಿಕ್ಸ್ ಬದಲಾಗದಿದ್ದರೆ, ಅದನ್ನು ನಿಗದಿಪಡಿಸುವ ಡೀಮನ್ ಇಂಟರ್ಫೇಸ್ ನಿರ್ವಹಣೆಯನ್ನು ನಿಲ್ಲಿಸಿತು. ಪ್ರಿಫಿಕ್ಸ್ ಬದಲಾದರೂ ವಿಳಾಸಗಳು ಬದಲಾಗದಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಸಂರಚನೆ ಹಳೆಯದಾಗಿದೆ. ಎರಡೂ ವೈಫಲ್ಯಗಳು ಬ್ರೌಸರ್ನಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಏನೂ ಸಾಮಾನ್ಯವಿಲ್ಲ.
dhcpcd ಸುರಂಗವನ್ನು ನಿರ್ವಹಿಸಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ
dhcpcd ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಪತ್ತೆ ಮಾಡಬಹುದು ಮತ್ತು DHCPv6 ಪ್ರಿಫಿಕ್ಸ್ನ ಭಾಗಗಳನ್ನು ಕೆಳಮುಖ ಇಂಟರ್ಫೇಸ್ಗಳಿಗೆ ನಿಯೋಜಿಸಬಹುದು, ಮತ್ತು ಅದರ ಸಂರಚನೆ ನಿಯೋಜನೆ ಗುರಿಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೆಸರಿಸಬಹುದು. ಸ್ಪಷ್ಟ ಗುರಿ ಇಲ್ಲದಿದ್ದರೆ, ಅದರ ದಾಖಲಿತ ವರ್ತನೆ ಇತರ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಒಳಗೊಳ್ಳಬಹುದು, ಮತ್ತು ಹೀಗೆ ಸುರಂಗಕ್ಕೆ ಯಾರೂ ಯೋಜಿಸದ ವಿಳಾಸ ಬರುತ್ತದೆ.
ಎರಡು ಷರತ್ತುಗಳು ನಿಮ್ಮನ್ನು ಸುರಂಗದ ಸ್ಥಿರ ವಿಳಾಸೀಕರಣವನ್ನು OpenVPNಗೆ ಬಿಡುವಂತೆ ತಳ್ಳಬೇಕು: ಸರ್ವರ್ ತನ್ನ ಸಂರಚನೆಯಲ್ಲಿ ಸ್ಥಿರ ವಿಳಾಸಗಳನ್ನು ತಳ್ಳುತ್ತದೆ, ಮತ್ತು ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಸುರಂಗದ ಹೆಸರು ಬದಲಾಗುತ್ತದೆ. ಎರಡೂ ನಿಜವಾದರೆ, ಸುರಂಗವನ್ನು ನಿಯೋಜನೆ ಡೀಮನ್ನಿಂದ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹೊರಗಿಡಿ, ಕಾರಣವನ್ನು ತಿಳಿಸುವ ಟಿಪ್ಪಣಿಯೊಂದಿಗೆ.
ಬದಲಿಗೆ ಸುರಂಗಕ್ಕೆ ನಿಯೋಜನೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿದ್ದರೆ, ಪ್ರಿಫಿಕ್ಸ್ ಬದಲಾವಣೆಯ ನಿರ್ವಹಣೆಯನ್ನು ಜಾರಿಗೆ ತನ್ನಿ. ಎಂದರೆ ನಿಯೋಜಿತ ಪ್ರಿಫಿಕ್ಸ್ ಅಥವಾ ಅದರ ಜೀವಿತಾವಧಿ ಬದಲಾದಾಗ ಪ್ರತಿಕ್ರಿಯಿಸುವುದು, ಸರ್ವರ್ ಘೋಷಿಸುವ ಕ್ಲೈಂಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ನವೀಕರಿಸುವುದು, ಮತ್ತು ಮಾರ್ಗವನ್ನು ಮತ್ತೆ ಸೇರಿಸುವುದು. ಆ ವಿನ್ಯಾಸದಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೊರಗಿಡುವುದು ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್ ಬಗ್ಗೆ ತಿಳಿದಿರುವ ಏಕೈಕ ಘಟಕವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
dhcpcd ಮರುಪ್ರಾರಂಭಿಸುವುದು ಸ್ಥಿತಿಯನ್ನು ಮತ್ತೆ ರಚಿಸುವುದರಿಂದ ಸಮಸ್ಯೆ ಸರಿಪಡಿಸಿದಂತೆ ಕಾಣಬಹುದು, ಆದರೆ ಅದು ನೀವು ಯೋಚಿಸದ ಇಂಟರ್ಫೇಸ್ಗಳ ಸಂರಚನೆಯನ್ನೂ ನವೀಕರಿಸುತ್ತದೆ ಅಥವಾ ಹಿಂಪಡೆಯುತ್ತದೆ. ಆ ಚೇತರಿಕೆ ಅದನ್ನು ಪ್ರತಿ VPN ಮರುಪ್ರಾರಂಭದ ನಂತರ ಕಡ್ಡಾಯವಾಗಿಸುವುದಿಲ್ಲ. ಅದು ಸಾಕ್ಷ್ಯವಾಗಿ ಬಳಸಿದ ಕೌಂಟರ್ಗಳನ್ನೂ ಮರುಹೊಂದಿಸುತ್ತದೆ. ನೀವು ನಿಜವಾಗಿ ಬದಲಿಸಿದ ಇಂಟರ್ಫೇಸ್ನ ಗುರಿಯುತ ಮರುಲೋಡ್ ಅನ್ನು ಆದ್ಯತೆ ನೀಡಿ.
IPv6 ಅನ್ನು IPv4 NAT ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಮೌಲ್ಯೀಕರಿಸಿ
ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿದೆ ಮತ್ತು ಮೇಲ್ಮುಖ ಮಾರ್ಗ ನಿಜವಾದ ಕ್ಲೈಂಟ್ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ತೋರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಹೊಸ ಅನುಮತಿಸಿದ IPv6 ಸಂಪರ್ಕವನ್ನು ಮಾಡಿ. ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ IPv6 ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ತೋರಿಸುವ ಕ್ಲೈಂಟ್ ಅದರ ವಿನಂತಿ ಸುರಂಗವನ್ನು ಬಳಸಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
IPv4 ಮುಖವಾಡವು ಬೇರೆ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ: ಖಾಸಗಿ ಮೂಲಗಳಿಗೆ ಹಿಂತಿರುಗುವ ದಾರಿ. ಹಿಂಪಡೆದ IPv6 ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಅದು ಏನೂ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಸೇರಿಸುವುದರಿಂದ IPv6 ಮರಳಿ ಬರುವುದಿಲ್ಲ.
ಮಾಲೀಕತ್ವದ ದಾಖಲೆಯೊಂದಿಗೆ ಮುಗಿಸಿ: ಯಾವ ಘಟಕ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ, ಯಾವುದು ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ, ಯಾವುದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಹಿಡಿದಿರುತ್ತದೆ, ಮತ್ತು ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಏನಾಗುತ್ತದೆ. ರನ್ಬುಕ್ನ ನಾಲ್ಕು ಸಾಲುಗಳು ಮುಂದಿನ ವ್ಯಕ್ತಿಯನ್ನು ಮೂರು ಡೀಮನ್ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದರಿಂದ ಉಳಿಸುತ್ತವೆ, ಮುಖ್ಯವಾದದ್ದನ್ನು ಹುಡುಕಲು.