ನಿಮ್ಮ /64 ಅನ್ನು ವಿಭಜಿಸುವುದು IPv6 ಅನ್ನು VPN ಕ್ಲೈಂಟ್ಗಳಿಗೆ ರೂಟ್ ಮಾಡುವುದಿಲ್ಲ

ಕ್ಲೈಂಟ್ ಜಾಗತಿಕ IPv6 ವಿಳಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ, ಹ್ಯಾಂಡ್ಶೇಕ್ ಪೂರ್ಣಗೊಂಡಿದೆ, ಮತ್ತು ಇಂಟರ್ನೆಟ್ನಿಂದ ಏನೂ ಹಿಂತಿರುಗಿ ಬರುವುದಿಲ್ಲ. ಪೂಲ್ ಸೆಟ್ಟಿಂಗ್ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ ಏಕೆಂದರೆ ಅದು ನಿಜವಾಗಿಯೂ ಸರಿಯಾಗಿದೆ; ವಿಳಾಸ ಮಾನ್ಯವಾಗಿದೆ ಮತ್ತು ಸುರಂಗವು ಅದನ್ನು ಸಾಗಿಸುತ್ತದೆ. ವಿಫಲವಾಗುವುದು ಡೆಲಿವರಿ, ಮತ್ತು ಡೆಲಿವರಿ VPN ಸರ್ವರ್ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳಲಾದ ನಿರ್ಧಾರವನ್ನು ಅವಲಂಬಿಸಿದೆ, ಅದರ ಮೇಲೆ ಯಾವುದೇ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ರಭಾವ ಬೀರಲಾರದು.

ಪುರಾಣ: ನಿಮ್ಮ /64 ನ ಒಂದು ಭಾಗ ಈಗಾಗಲೇ ತಲುಪಲು ಸಾಧ್ಯವಿದೆ

ಕಥೆ ಆಕರ್ಷಕವಾಗಿದೆ: ಸರ್ವರ್ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ /64 ಇದೆ, ಅದನ್ನು ಅರ್ಧಕ್ಕೆ ಕತ್ತರಿಸಿ, ಇನ್ನೊಂದು ಅರ್ಧವನ್ನು VPN ಪೂಲ್ಗೆ ನೀಡಿ, ಆ ಕ್ಲೈಂಟ್ಗಳು ಈಗ ಇಂಟರ್ನೆಟ್ನಲ್ಲಿದ್ದಾರೆ. ಪ್ರೀಫಿಕ್ಸ್ ಅನ್ನು ವಿಭಜಿಸುವುದು ಘರ್ಷಣೆಗಳಿಲ್ಲದೆ ವಿಳಾಸಗಳನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ. ಆದರೆ ಆ ವಿಳಾಸಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕು ಎಂಬುದನ್ನು upstream ನೆಟ್ವರ್ಕ್ ಹೇಗೆ ನಿರ್ಧರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅದು ಬದಲಿಸುವುದಿಲ್ಲ.

IPv6 ಗೆ ಅವಲಂಬಿಸಬಹುದಾದ ಡೀಫಾಲ್ಟ್ ಅನುವಾದ ಪದರವಿಲ್ಲ, ಆದ್ದರಿಂದ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವು ರೂಟಿಂಗ್ ಆಗಿ ಅಥವಾ ಲಿಂಕ್-ಹಂತದ ಡೆಲಿವರಿಯಾಗಿ ಇರಬೇಕು. ಕ್ಲೈಂಟ್ನ ಸುರಂಗ ವಿಳಾಸಕ್ಕೆ ಉದ್ದೇಶಿಸಲಾದ ಪ್ಯಾಕೆಟ್ upstream ರೂಟರ್ನ್ನು ತಲುಪುತ್ತದೆ, ಮತ್ತು ಆ ರೂಟರ್ ತನ್ನ ಸ್ವಂತ ಕೋಷ್ಟಕದಿಂದ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಕೋಷ್ಟಕವು ಭೌತಿಕ ಲಿಂಕ್ ಅನ್ನು ಸೂಚಿಸಿದರೆ, ನಿಮ್ಮ VPN ಸರ್ವರ್ ಏನು ಭಾವಿಸಿದರೂ ಪ್ಯಾಕೆಟ್ ಅಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ.

ಇದು ಸಂಪೂರ್ಣ ವೈಫಲ್ಯ: ಮುಂದಿನ ದಿಕ್ಕು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ನಿಮ್ಮ ಸರ್ವರ್ ಅದನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಹಿಂತಿರುಗುವ ದಿಕ್ಕು ಒಂದು ಹಾಪ್ ದೂರದಲ್ಲಿ ಸಾಯುತ್ತದೆ ಏಕೆಂದರೆ upstream ಕ್ಲೈಂಟ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ಎಂದಿಗೂ ತಿಳಿದಿರಲಿಲ್ಲ.

ಲಿಂಕ್ನಲ್ಲಿ ಡೆಲಿವರಿ ನಿಜವಾಗಿ ಏನು ಬೇಡುತ್ತದೆ

upstream ಸಂಪೂರ್ಣ /64 ಅನ್ನು ಭೌತಿಕ ಲಿಂಕ್ನಲ್ಲಿದೆ ಎಂದು ಪರಿಗಣಿಸಿದಾಗ, ಅದು ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸವನ್ನು ನೆರೆಹೊರೆಯವರ ಶೋಧದಿಂದ ಪರಿಹರಿಸುತ್ತದೆ. ಅದು ಆ ಲಿಂಕ್ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ವಿಳಾಸದ ಮಾಲೀಕರು ಉತ್ತರಿಸುತ್ತಾರೆ ಎಂದು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. ಸುರಂಗದ ಹಿಂದೆ ಇರುವ VPN ಕ್ಲೈಂಟ್ ಆ ಲಿಂಕ್ನಲ್ಲಿಲ್ಲ ಮತ್ತು ಉತ್ತರಿಸಲಾರದು, ಆದ್ದರಿಂದ ವಿನಂತಿ ಉತ್ತರವಿಲ್ಲದೆ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ.

/65 ಅನ್ನು ಕತ್ತರಿಸಿ ತೆಗೆಯುವುದು ಆ ನಿರೀಕ್ಷೆಯನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. upstream ಇನ್ನೂ ಶ್ರೇಣಿಯನ್ನು ಲಿಂಕ್ನಲ್ಲಿದೆ ಎಂದೇ ಪರಿಗಣಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅದರ ಮನಸ್ಸನ್ನು ಬದಲಿಸುವ ಏಕೈಕ ವಿಷಯ ಎಂದರೆ ಕ್ಲೈಂಟ್ನ ಪರವಾಗಿ ಉತ್ತರಿಸುವ ರೂಟ್ ಅಥವಾ ಪ್ರಾಕ್ಸಿ. ನೀವು VPN ಕಾನ್ಫಿಗರೇಶನ್ ಸಂಪಾದಿಸಿದ್ದರಿಂದ ಎರಡೂ ಕಾಣಿಸುವುದಿಲ್ಲ. ಆ ಅಂತರವೇ ಪೂಲ್ ತನ್ನದೇ ಕ್ಲೈಂಟ್ಗಳ ನಡುವೆ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡಿ, ಆದರೂ ಬೇರೆ ಎಲ್ಲಿಂದಲೂ ತಲುಪಲಾಗದಿರಲು ಕಾರಣ.

ಪ್ರಾಕ್ಸಿ ನೆರೆಹೊರೆಯವರ ಶೋಧವು ಎರಡು ಜಗತ್ತುಗಳನ್ನು ಸೇತುವೆ ಮಾಡಬಲ್ಲ ವ್ಯವಸ್ಥೆ. ಗೇಟ್ವೇ ತನ್ನ ಮಾಲೀಕತ್ವದ ನಿರ್ದಿಷ್ಟ ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳಿಗೆ ವಿನಂತಿಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಸಂಚಾರವನ್ನು ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಪೂಲ್ ಅನ್ನು ಅನುಸರಿಸುವ ಜೀವನಚಕ್ರದೊಂದಿಗೆ ನಿಖರವಾಗಿ ಆ ವಿಳಾಸಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಬೇಕು, ಏಕೆಂದರೆ ನೀವು ಇನ್ನು ಸೇವೆ ನೀಡದ ವಿಳಾಸದ ಪರವಾಗಿ ಉತ್ತರಿಸುವುದು ಬೇರೊಬ್ಬರ ಸಂಚಾರವನ್ನು ಕಪ್ಪು ಕುಳಿಯಾಗಿ ಮಾಡುತ್ತದೆ. ಕೆಲವು upstream ಗಳು ನಿರೀಕ್ಷಿಸದ ಪ್ರಾಕ್ಸಿ ಉತ್ತರಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಈ ವಿನ್ಯಾಸಕ್ಕೆ ಪೂರೈಕೆದಾರರ ಒಪ್ಪಿಗೆಯೂ ಬೇಕು.

ರೂಟ್ ಮಾಡಿದ ಡೆಲಿವರಿ ಏನು ಬೇಡುತ್ತದೆ

ಸ್ವಚ್ಛವಾದ ವಿನ್ಯಾಸ ಎಂದರೆ upstream ನಿಜವಾಗಿ ನಿಮ್ಮ ಗೇಟ್ವೇಗೆ ರೂಟ್ ಮಾಡುವ ಹಂಚಿಕೆ. ಅದು ಪ್ರತಿನಿಧಿಸಲಾದ ಪ್ರೀಫಿಕ್ಸ್ ಅಥವಾ ಚಿಕ್ಕ ಬ್ಲಾಕ್ಗೆ ಸ್ಥಿರ ರೂಟ್ ಆಗಿರಬಹುದು, ಮತ್ತು ಅವಶ್ಯಕತೆ ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಒಂದೇ: upstream ನ ಕೋಷ್ಟಕವು ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿಗೆ ನಿಮ್ಮ ಸರ್ವರ್ ಅನ್ನು ಸೂಚಿಸಬೇಕು. ನಂತರ ಹಿಂತಿರುಗುವ ಸಂಚಾರ ಗೇಟ್ವೇಗೆ ಬರುತ್ತದೆ ಮತ್ತು ಗೇಟ್ವೇ ಅದನ್ನು ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ.

ರೂಟ್ ಮಾಡಿದ ಡೆಲಿವರಿ ನೆರೆಹೊರೆಯವರ ಶೋಧದ ಪ್ರಶ್ನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಬುದ್ಧಿವಂತ ವಸ್ತುವನ್ನು ನಿರ್ಮಿಸುವ ಮೊದಲು ಪೂರೈಕೆದಾರರನ್ನು ಅದನ್ನು ಕೇಳುವುದು ಯೋಗ್ಯ. ರೂಟ್ ಅನ್ನು ಲಿಖಿತವಾಗಿ ಕೇಳಿ, ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ upstream ನಿಜವಾಗಿ ತಲುಪಬಲ್ಲ ವಿಳಾಸವೇ ಎಂದು ದೃಢೀಕರಿಸಿ.

ಎರಡೂ ವಿನ್ಯಾಸಗಳಿಗೆ ಇನ್ನೂ ಗೇಟ್ವೇನಲ್ಲಿ IPv6 ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿರುವುದು ಮತ್ತು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಫಾರ್ವರ್ಡ್ ಆದ ಹರಿವನ್ನು ಅನುಮತಿಸುವ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ಬೇಕು. ಡೆಲಿವರಿ ಉಳಿದ ಮಾರ್ಗಕ್ಕೆ ಪೂರ್ವಾಪೇಕ್ಷೆಯೇ ಹೊರತು ಪರ್ಯಾಯವಲ್ಲ. ಫಾರ್ವರ್ಡಿಂಗ್ ಆಫ್ ಇರುವ ಕೆಲಸ ಮಾಡುವ ರೂಟ್ ಕಾಣೆಯಾದ ರೂಟ್ನಂತೆಯೇ ಅದೇ ಮೌನವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಏನನ್ನಾದರೂ ಮರು ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ.

ಸರಿಪಡಿಸಬೇಕಾದ ಎರಡು ಸ್ವತಂತ್ರ ರೂಟ್ಗಳು

ಪೂಲ್ ಪ್ರೀಫಿಕ್ಸ್ ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್ಗಳು, ಮತ್ತು ಅವುಗಳನ್ನು ಗೊಂದಲಗೊಳಿಸುವುದು ಮುರಿದ ಸುರಂಗದಂತೆ ಕಾಣುವ ಭಾಗಶಃ ಸಂಪರ್ಕವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಪೂಲ್ ಸರ್ವರ್ಗೆ ಯಾವ ವಿಳಾಸಗಳನ್ನು ನೀಡಬೇಕೆಂದು ಹೇಳುತ್ತದೆ. ಕ್ಲೈಂಟ್ನ ರೂಟ್ಗಳು ಕ್ಲೈಂಟ್ ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಸಂಚಾರವನ್ನು ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

ಮೇಲಿನ ಪ್ರೀಫಿಕ್ಸ್ ದಸ್ತಾವೇಜು ಸ್ಥಳವಾಗಿದೆ, ಮತ್ತು ಮರುನಿರ್ದೇಶನವು IPv6 ಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ, ಇದು IPv6 ಡೆಲಿವರಿ ಇನ್ನೂ ಸರಿಪಡಿಸಲ್ಪಡುತ್ತಿರುವಾಗ ದ್ವಿ-ಸ್ಟಾಕ್ ನಿಯೋಜನೆ ಸಾಮಾನ್ಯವಾಗಿ ಬಯಸುವುದೇ ಆಗಿದೆ. IPv4 ಮರುನಿರ್ದೇಶನವು IPv6 ಕವರೇಜ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ ಸೆಟ್ಟಿಂಗ್ ಇನ್ನೊಂದನ್ನು ಸೂಚಿಸುವುದಿಲ್ಲ.

ನೀವು ಅನ್ವಯಿಸುವ ಯಾವುದೇ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ IPv6 ಅವಲಂಬಿಸಿರುವ ನಿಯಂತ್ರಣ ಸಂಚಾರವನ್ನು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರಿಸಿ. Packet Too Big ಸಂದೇಶಗಳು TCP ಮತ್ತು UDP ಗೆ ಮಾತ್ರ ಅನುಮತಿಸುವ ಫೈರ್ವಾಲ್ನ ಸಾಂಪ್ರದಾಯಿಕ ಬಲಿಪಶು, ಮತ್ತು ಅವನ್ನು ಬಿಸಾಡುವುದು ಸ್ಥಾಪಿತವಾದ ನಂತರ ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳಲ್ಲಿ ನಿಲ್ಲುವ ಸಂಪರ್ಕಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ರೂಟರ್ ಜಾಹೀರಾತುಗಳು ಮೂರನೇ ಚಲಿಸುವ ಭಾಗ. ಗೇಟ್ವೇ ಮೇಲ್ಮುಖ ಲಿಂಕ್ನಲ್ಲಿ ಜಾಹೀರಾತು ನೀಡಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಕ್ಲೈಂಟ್ಗಳು ಮತ್ತು ನೆರೆಹೊರೆಯವರು ಲಿಂಕ್ನಲ್ಲಿನ ಪ್ರೀಫಿಕ್ಸ್ಗಳ ಬಗ್ಗೆ ನಂಬುವುದನ್ನು ಬದಲಿಸಬಹುದು, ಇದು ನೀವು ಈಗಷ್ಟೇ ದಸ್ತಾವೇಜಿಸಿದ ವಿನ್ಯಾಸವನ್ನು ಸದ್ದಿಲ್ಲದೆ ರದ್ದುಗೊಳಿಸಬಹುದು.

ಮರುನಿರ್ಮಾಣವು ಅದನ್ನು ಮರುಹುಟ್ಟಿಸುವಂತೆ ವಿನ್ಯಾಸವನ್ನು ದಾಖಲಿಸಿ

ಮೂರು ವಸ್ತುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬರೆಯಿರಿ: ಕ್ಲೈಂಟ್ ಹಂಚಿಕೆ, ಕ್ಲೈಂಟ್ನ ಗಮ್ಯಸ್ಥಾನ ರೂಟ್, ಮತ್ತು ಹಂಚಿಕೆಗಾಗಿ upstream ನ ಡೆಲಿವರಿ ವಿಧಾನ. ಮೂರನ್ನೂ ಹೊಂದಿರುವ ಓದುಗರು ನಿಯೋಜನೆಯನ್ನು ಮರುನಿರ್ಮಿಸಬಹುದು; ಪೂಲ್ ಸೆಟ್ಟಿಂಗ್ ಮಾತ್ರ ಹೊಂದಿರುವ ಓದುಗರು ಮೂಲ ದೋಷವನ್ನು ಮರುಹುಟ್ಟಿಸುತ್ತಾರೆ.

ನಂತರ ಹಿಂತಿರುಗುವ ದಿಕ್ಕನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ಹೊರಗಿನಿಂದ ಹಿಂತಿರುಗಬೇಕಾದ ಪ್ಯಾಕೆಟ್ನೊಂದಿಗೆ. openvpn(8) ಕೈಪಿಡಿ server-ipv6 ಮತ್ತು redirect ಆಯ್ಕೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಮತ್ತು ನಿಮ್ಮ ಪೂರೈಕೆದಾರರ ರೂಟಿಂಗ್ ದೃಢೀಕರಣವು ಕೈಪಿಡಿ ಮಾಡಲಾಗದ ಅರ್ಧವನ್ನು ಒಳಗೊಂಡಿದೆ.