ಡ್ಯುಯಲ್-ಸ್ಟ್ಯಾಕ್ VPN: ಎಡ್ರೆಸ್ ಫ್ಯಾಮಿಲಿಯನ್ನು ಕ್ಲೈಂಟ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ನೀವಲ್ಲ
ಒಂದು ಹೆಸರು, ಎರಡು ಫ್ಯಾಮಿಲಿ, ಎರಡು ವಿಭಿನ್ನ ಮಾರ್ಗಗಳು. ಟನೆಲ್ ಆರೋಗ್ಯಕರವಾಗಿದ್ದರೂ ವಿನಂತಿ ವಿಫಲವಾಗಬಹುದು, ಏಕೆಂದರೆ ನೀವು ಎಂದಿಗೂ ರೂಟ್ ಮಾಡದ ಅಭ್ಯರ್ಥಿಯನ್ನು ಕ್ಲೈಂಟ್ ಆಯ್ಕೆ ಮಾಡಿದೆ.
ಟನೆಲ್ ಚಾಲನೆಯಲ್ಲಿದೆ, IPv4 ಸೈಟ್ಗಳು ಲೋಡ್ ಆಗುತ್ತಿವೆ, ಮತ್ತು ಒಂದು ಹೋಸ್ಟ್ನಾಮ್ ಸಮಯ ಮೀರುತ್ತದೆ. ತಕ್ಷಣದ ತೀರ್ಮಾನ ಎಂದರೆ VPN ಕೆಟ್ಟಿರಬಹುದು ಅಥವಾ ರುಜುವಾತುಗಳು ತಪ್ಪಾಗಿರಬಹುದು, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಎರಡೂ ನಿಜವಲ್ಲ. ಹೆಸರು IPv4 ಮತ್ತು IPv6 ಎರಡೂ ವಿಳಾಸಗಳನ್ನು ಹಿಂತಿರುಗಿಸಿತು, ಅಪ್ಲಿಕೇಶನ್ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಿತು, ಮತ್ತು ಆ ಅಭ್ಯರ್ಥಿಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗವಿತ್ತು. ಆಯ್ಕೆಯ ನಿರ್ಧಾರವನ್ನು ಕ್ಲೈಂಟ್ ತೆಗೆದುಕೊಂಡಿತು; ಟನೆಲ್ ಅದು ಆಯ್ಕೆ ಮಾಡಿದ್ದನ್ನು ಕವರ್ ಮಾಡಲಿಲ್ಲ ಅಷ್ಟೇ.
ಆಯ್ಕೆ ಎಂಬುದು ಕವರೇಜ್ನ ಭರವಸೆ ಅಲ್ಲ
RFC 6724 ನಲ್ಲಿ ವಿವರಿಸಲಾದ ಡೀಫಾಲ್ಟ್ ವಿಳಾಸ ಆಯ್ಕೆ, ಹಲವು ಲಭ್ಯವಿದ್ದಾಗ ಹೋಸ್ಟ್ ಯಾವ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಜೋಡಿಗೆ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. Happy Eyeballs ಅದರ ಮೇಲೆ ಸಂಪರ್ಕ ತಂತ್ರವನ್ನು ಸೇರಿಸುತ್ತದೆ: ಎರಡೂ ಫ್ಯಾಮಿಲಿಗಳಲ್ಲಿ ಪ್ರಯತ್ನಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿ ಮೊದಲು ಉತ್ತರಿಸಿದ್ದನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಇದರಿಂದ ಬಳಕೆದಾರರು ಕೆಟ್ಟ ಫ್ಯಾಮಿಲಿಯ ಸಮಯ ಮೀರುವವರೆಗೆ ಕಾಯಬೇಕಾಗಿಲ್ಲ.
ಎರಡೂ ಕಾರ್ಯವಿಧಾನಗಳಲ್ಲಿ ಯಾವುದೂ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಟನೆಲ್ ಕೇವಲ IPv4 ಸಾಗಿಸಿದರೆ, AAAA ಅಭ್ಯರ್ಥಿ ಇನ್ನೂ ಕ್ಲೈಂಟ್ ಪ್ರಯತ್ನಿಸಬಹುದಾದ ಕಾನೂನುಬದ್ಧ ಗಮ್ಯಸ್ಥಾನ, ಮತ್ತು ವೈಫಲ್ಯವು ದೋಷವಾಗಿ ಅಲ್ಲ, ನಿಧಾನ ಲೋಡಿಂಗ್ ಆಗಿ ಕಾಣುತ್ತದೆ, ಏಕೆಂದರೆ ಬ್ರೌಸರ್ ಹಿಂಭಾಗಕ್ಕೆ ಸರಿಯಿತು. ಬಳಕೆದಾರರು ಕೆಟ್ಟ ಸೈಟ್ ಅಲ್ಲ, ನಿಧಾನ ಸೈಟ್ ಎಂದು ವರದಿ ಮಾಡುತ್ತಾರೆ, ಮತ್ತು ಬೆಂಬಲ ಟಿಕೆಟ್ ಆ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ. ಸ್ಥಿರ ಫ್ಯಾಮಿಲಿಯೊಂದಿಗೆ ಅದನ್ನು ಮರುಸೃಷ್ಟಿಸಿ, ವರದಿ ನಿರ್ದಿಷ್ಟವಾಗುತ್ತದೆ.
ಆ ಹಿಂಭಾಗದ ಕಾರಣದಿಂದಲೇ ಅಪ್ಲಿಕೇಶನ್ಗಳ ನಡುವೆ ಲಕ್ಷಣ ಅಸಂಗತವಾಗಿದೆ. ಬ್ರೌಸರ್ ವಿಳಂಬವನ್ನು ಮರೆಮಾಡುತ್ತದೆ; ಸ್ಥಿರ ಫ್ಯಾಮಿಲಿಯ ಕಮಾಂಡ್-ಲೈನ್ ಕ್ಲೈಂಟ್ ನಿಜವಾದ ವೈಫಲ್ಯವನ್ನು ತಕ್ಷಣ ತೋರಿಸುತ್ತದೆ.
ವಿನಂತಿ ನಿಜವಾಗಿ ಬಳಸಿದ ಫ್ಯಾಮಿಲಿಯನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ
ಟನೆಲ್ನಿಂದ ಅಲ್ಲ, ಹೆಸರಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಎರಡೂ ರೆಕಾರ್ಡ್ ಪ್ರಕಾರಗಳನ್ನು ಕೇಳಿ ಮತ್ತು ಏನು ಹಿಂತಿರುಗಿತು ಎಂದು ಬರೆಯಿರಿ:
dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.comv4 ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗಿ v6 ವಿನಂತಿ ವಿಫಲವಾದರೆ, ನೀವು ಡೀಬಗ್ ಮಾಡಬಹುದಾದ ರೂಪದಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಮರುಸೃಷ್ಟಿಸಿದ್ದೀರಿ. ಶೆಲ್ನಿಂದ ಎರಡೂ ಯಶಸ್ವಿಯಾಗಿ ಬ್ರೌಸರ್ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಟನೆಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ರಿಸಾಲ್ವರ್ ಅಥವಾ ಕ್ಯಾಶ್ ಮಾಡಿದ ಉತ್ತರವನ್ನು ನೋಡಿ.
ಫ್ಯಾಮಿಲಿ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವನ್ನು ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಇರಿಸಿ. VPN ಮೂಲಕ ಸೈಟ್ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ ಎಂದು ಹೇಳುವ ಟಿಕೆಟ್ ಅನ್ನು ಯಾರೂ ಪರಿಶೀಲಿಸಲಾರರು, ಆದರೆ AAAA ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು A ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಹೇಳುವ ಟಿಕೆಟ್ ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ಆ ಫ್ಯಾಮಿಲಿಗೆ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ
ವಿಫಲವಾಗುತ್ತಿರುವ ಫ್ಯಾಮಿಲಿಗೆ, ಕರ್ನೆಲ್ ಯಾವ ಮಾರ್ಗ ಬಳಸುತ್ತದೆ ಎಂದು ಕೇಳಿ ಮತ್ತು ಅದನ್ನು ಟನೆಲ್ನ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ವಿಳಾಸಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. Linux ನಲ್ಲಿ, ip -6 route get ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಆಯ್ಕೆಯಾಗುವ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮೂಲವನ್ನು ತೋರಿಸುತ್ತದೆ.
ನಂತರ ಟನೆಲ್ ಅನ್ನು ಸ್ವತಃ ಪರಿಶೀಲಿಸಿ. WireGuard ಪೀರ್ಗಳು ಅನುಮತಿಸಿದ IP ಪಟ್ಟಿಯನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತವೆ, ಮತ್ತು 0.0.0.0/0 ಗಾಗಿ ನಮೂದು IPv6 ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಪೀರ್ನ ಪಟ್ಟಿಯಲ್ಲಿ IPv6 ಪೂರ್ವಪ್ರತ್ಯಯವಿಲ್ಲದಿದ್ದರೆ, AAAA ಸಂಚಾರವನ್ನು ಟನೆಲ್ಗೆ ಕಳುಹಿಸಲು ಕ್ಲೈಂಟ್ಗೆ ಯಾವುದೇ ಕಾರಣವಿಲ್ಲ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಹೋಸ್ಟ್ ಇಲ್ಲದಿದ್ದರೆ ಮಾಡುತ್ತಿದ್ದ ಮಾರ್ಗದಲ್ಲಿ ಹೊರಹೋಗುತ್ತದೆ.
ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ಮತ್ತು NAT ನೀತಿ ಪ್ರತಿ ಫ್ಯಾಮಿಲಿಗೂ ಅದೇ ಪರಿಶೀಲನೆಗೆ ಅರ್ಹವಾಗಿವೆ. IPv4 ಗಾಗಿ ಬರೆದ ನಿಯಮ ಯಾವುದೇ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನಲ್ಲಿ IPv6 ಅನ್ನು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ಒಂದು ಫ್ಯಾಮಿಲಿ ಕೆಲಸ ಮಾಡಿ ಇನ್ನೊಂದು ಮಾಡದಿರಲು ಇದೇ ಸಾಮಾನ್ಯ ಕಾರಣ.
ಸ್ಕ್ರೀನ್ಶಾಟ್ ಸರಳಗೊಳಿಸಲು IPv6 ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ
ಸಿಸ್ಟಮ್-ವ್ಯಾಪಿ IPv6 ಆಫ್ ಮಾಡಿದರೆ ಲಕ್ಷಣ ಮಾಯವಾಗುತ್ತದೆ ಮತ್ತು ನೀವು ನಿರ್ಣಯವಿಲ್ಲದೆ ಉಳಿಯುತ್ತೀರಿ. ಇದು IPv6-ಮಾತ್ರ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಸಹ ಮುರಿಯುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಅಪ್ಲಿಕೇಶನ್ಗಾಗಿ ಅದೇ ದೋಷವನ್ನು ಮರೆಮಾಡುತ್ತದೆ. ಒಂದು ಯಂತ್ರ ನಿಜವಾಗಿಯೂ IPv6 ಬಳಸಬಾರದಿದ್ದರೆ, ಅದು ಮಾಲೀಕರು ಮತ್ತು ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಉದ್ದೇಶಪೂರ್ವಕ ನೀತಿ. ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಆಫ್ ಮಾಡುವುದು ಎರಡೂ ಅಲ್ಲ.
ಫ್ಯಾಮಿಲಿಯೊಂದಿಗೆ ಕ್ಲೈಂಟ್ ಏನು ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ ಮತ್ತು ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿ: ಅದನ್ನು ಟನೆಲ್ ಮೂಲಕ ಸಾಗಿಸಿ, ಅಥವಾ ಬೆಂಬಲಿತ ರೀತಿಯಲ್ಲಿ ನಿರ್ಬಂಧಿಸಿ, ಆಯ್ಕೆ ಎಂದಿಗೂ ತಲುಪಲಾಗದ ಅಭ್ಯರ್ಥಿಯನ್ನು ನೀಡದಂತೆ. ಎರಡೂ ಕಾನೂನುಬದ್ಧ ವಿನ್ಯಾಸಗಳು. ಜಾಗತಿಕ ನಿಷ್ಕ್ರಿಯತೆ ಎರಡೂ ಅಲ್ಲ, ಏಕೆಂದರೆ ಅದು ವಿನ್ಯಾಸವೇ ಅಲ್ಲ.
ಟಿಕೆಟ್ನಲ್ಲಿ ಏನು ಬರೆಯಬೇಕು
ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ದಾಖಲಿಸಿ: ಹೋಸ್ಟ್ನಾಮ್, ವಿಫಲವಾದ ಫ್ಯಾಮಿಲಿ, ಕರ್ನೆಲ್ ಆಯ್ಕೆ ಮಾಡಿದ ಮಾರ್ಗ, ಮತ್ತು ಫ್ಯಾಮಿಲಿ-ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಯ ಫಲಿತಾಂಶ. ಈ ಗುಂಪು ಬೇರೆಯವರಿಗೆ ವೈಫಲ್ಯವನ್ನು ಮರುಸೃಷ್ಟಿಸಲು ಸಾಕು, ನೀವು ಯಾವ ಎರಡು ಮಾರ್ಗಗಳನ್ನು ಉದ್ದೇಶಿಸಿದ್ದೀರಿ ಎಂದು ಊಹಿಸದೆ.
RFC 6724 ವಿಳಾಸ ಆಯ್ಕೆ ನಿಯಮಗಳು ಕ್ಲೈಂಟ್ ಏಕೆ ಆ ಅಭ್ಯರ್ಥಿಗೆ ಆದ್ಯತೆ ನೀಡಿತು ಎಂದು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು RFC 8305 ವಿಳಂಬವನ್ನು ಮರೆಮಾಡಿದ ಸ್ಪರ್ಧಾತ್ಮಕ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ನಿಮಗಾಗಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ರೂಟ್ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಟನೆಲ್ ಮಾಡಬೇಕಾದದ್ದು ಅದೇ ಭಾಗ.