ಪಿಯರ್‌ನ AllowedIPs ನಲ್ಲಿ 0.0.0.0/0, ::/0 ಹಾಕುವುದು ಎಲ್ಲರೂ ನೆನಪಿಡುವ ಹಂತ, ಮತ್ತು ಅದು ಪಿಯರ್ ಯಾವ ಟ್ರಾಫಿಕ್ ಸಾಗಿಸಬಹುದು ಎಂಬುದನ್ನು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ. ಈ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಯಾವುದೇ ಮಾರ್ಗವನ್ನು ರಚಿಸುವುದಿಲ್ಲ, ಆಚೆ ಬದಿಯಲ್ಲಿ ಏನನ್ನೂ ಮುಂದೂಡುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಇದ್ದಲ್ಲೇ ಬಿಡುತ್ತವೆ. ಪೂರ್ಣ ಸುರಂಗ ನಿಜವಾಗಿ ಪೂರ್ಣವಾಗಲು ನಾಲ್ಕು ಪ್ರತ್ಯೇಕ ಅಂಶಗಳು ಏಕಕಾಲದಲ್ಲಿ ನಿಜವಾಗಿರಬೇಕು, ಮತ್ತು ಅವನ್ನು ಕೆಳಗಿನ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸುವುದು ಉತ್ತಮ, ಏಕೆಂದರೆ ನಂತರದ ಪರಿಶೀಲನೆ ಹಿಂದಿನದನ್ನು ಪಾರು ಮಾಡಲಾರದು. ಕೆಳಗಿನ ಪ್ರತಿ ಪರಿಶೀಲನೆಯೂ ಯಂತ್ರದಿಂದ ಓದಬಹುದಾದ ಸತ್ಯ, ಅನ್ವಯವಾಗಿದೆ ಎಂದು ನೀವು ನಿರೀಕ್ಷಿಸುವ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ.

ಪಿಯರ್ ಪ್ರಿಫಿಕ್ಸ್ ಏನನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಏನನ್ನು ಮಾಡುವುದಿಲ್ಲ

AllowedIPs ಒಟ್ಟಿಗೆ ಆಯ್ಕೆಗಾರ ಮತ್ತು ಅನುಮತಿದಾಯಕ. ಅದು ಸ್ಥಳೀಯ ಬದಿಗೆ ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಈ ಪಿಯರ್‌ಗೆ ಕಳುಹಿಸಬಹುದು ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಬದಿಗೆ ಈ ಪಿಯರ್ ಯಾವ ಮೂಲ ವಿಳಾಸಗಳನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಬಹುದು ಎಂದು ಹೇಳುತ್ತದೆ. ಅದೇ ಸಂಪೂರ್ಣ ಕೆಲಸ. ಆ ವಿವರಣೆಯಲ್ಲಿ ಯಾವುದೂ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಮಾರ್ಗವನ್ನು ರಚಿಸುವುದಿಲ್ಲ, ದೂರದ ಬದಿಯಲ್ಲಿ ಮುಂದೂಡಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ, ಅಥವಾ ಹೆಸರು ವಿಭಜನೆಯನ್ನು ಮುಟ್ಟುವುದಿಲ್ಲ.

ಅದಕ್ಕೇ ಸಂರಚನೆ ಪೂರ್ಣವಾಗಿ ಕಾಣಬಹುದು ಮತ್ತು ವಿಭಜಿತ ಸುರಂಗದಂತೆ ವರ್ತಿಸಬಹುದು. ಪ್ರಿಫಿಕ್ಸ್ ಪಿಯರ್ ಎಲ್ಲವನ್ನೂ ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ; ಹೋಸ್ಟ್‌ನ ಮಾರ್ಗ ಕೋಷ್ಟಕವು ಅಲ್ಲಿಗೆ ನಿಜವಾಗಿ ಏನು ತಲುಪುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಗೇಟ್‌ವೇ ಏನಾದರೂ ಹೊರಹೋಗುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಆ ಮೂರು ನಿರ್ಧಾರಗಳಲ್ಲಿ ಯಾವುದೂ ಪಿಯರ್ ವಿಭಾಗದಲ್ಲಿ ಇರುವುದಿಲ್ಲ.

ಕ್ಲೈಂಟ್ ಅನ್ನು ಮಾರ್ಗೀಕರಿಸುವುದು, ಪಿಯರ್ ಪಟ್ಟಿ ಮಾತ್ರವಲ್ಲ

ಉದಾಹರಣೆಗೆ wg-quick ನಂತಹ ನಿರ್ವಾಹಕರು ಹೋಸ್ಟ್‌ನ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ನಿಮ್ಮ ಪರವಾಗಿ ಪ್ರೋಗ್ರಾಮ್ ಮಾಡುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಎರಡು ಒಂದೇ ರೀತಿಯ ಸಂರಚನಾ ಫೈಲ್‌ಗಳು ಇಂಟರ್‌ಫೇಸ್ ಹೇಗೆ ಮೇಲೆ ಬಂತು ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ. ಕನಿಷ್ಠ ಪ್ರೊಫೈಲ್ ಒಂದೇ ಬಾರಿಗೆ ಓದಲು ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿದೆ:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

ಕೆಲಸವನ್ನು ಎರಡು ವಿವರಗಳು ಹೊರುತ್ತವೆ. Address ಕ್ಷೇತ್ರವು ಕ್ಲೈಂಟ್ ತನ್ನದು ಎಂದು ನಂಬುವ ಸಬ್‌ನೆಟ್ ಅಲ್ಲ, ಒಂದೇ ಹೋಸ್ಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಆಗಿದೆ, ಮತ್ತು ಡೀಫಾಲ್ಟ್ AllowedIPs ಅನ್ನು ನಿಜವಾದ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವಾಗಿ ಪರಿವರ್ತಿಸುವುದು ನಿರ್ವಾಹಕನೇ. ಅದೇ ಫೈಲ್ ಅನ್ನು ip link ಮತ್ತು wg setconf ಮೂಲಕ ಮೇಲೆ ತನ್ನಿ, ಮತ್ತು ಯಾವುದೇ ಮಾರ್ಗ ಕಾಣಿಸುವುದಿಲ್ಲ, ಅದು ಮುರಿದ ಸುರಂಗದಂತೆ ಕಾಣುತ್ತದೆ ಆದರೆ ವಾಸ್ತವವಾಗಿ ಮಾರ್ಗೀಕರಣ ಹಂತವನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟ ಆರೋಗ್ಯಕರ ಸುರಂಗ. wg-quick ಕೈಪಿಡಿಯು ಮಾರ್ಗೀಕರಣ ಮತ್ತು Table ವರ್ತನೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಅದನ್ನು ಆ ನಿರ್ವಾಹಕರು ಸೇರಿಸುತ್ತಾರೆ.

ಫೈಲ್ ಬದಲು ಫಲಿತಾಂಶವನ್ನು ಓದಿ: ip route get 1.1.1.1 ಸುರಂಗದ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಹೆಸರಿಸಬೇಕು, ಮತ್ತು wg show ಚಲಿಸುವ ವರ್ಗಾವಣೆ ಕೌಂಟರ್‌ನೊಂದಿಗೆ ಇತ್ತೀಚಿನ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ವರದಿ ಮಾಡಬೇಕು. ಮಾರ್ಗವಿಲ್ಲದ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಎಂದರೆ ನಿರ್ವಾಹಕ ಎಂದೂ ಓಡಿಲ್ಲ, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಮತ್ತೆ ಸಂಪಾದಿಸುವುದರಿಂದ ಅದು ಸರಿಯಾಗುವುದಿಲ್ಲ. ಬಳಕೆದಾರರು ಪ್ರಾರಂಭಿಸುವ ರೀತಿಯಲ್ಲೇ ಇಂಟರ್‌ಫೇಸ್ ಪ್ರಾರಂಭಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಪರೀಕ್ಷೆ ನಿಯೋಜನೆಯ ಬದಲು ನಿಮ್ಮ ಶೆಲ್ ಅನ್ನು ಅಳೆಯುತ್ತದೆ.

ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಸುರಂಗದ ಹೊರಗೆ ಇಡುವುದು

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

ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹಲವು ವಿಳಾಸಗಳಿಗೆ ಅಥವಾ ನೀವು ಸಾಗಿಸದ ಕುಟುಂಬಕ್ಕೆ ವಿಭಜನೆಯಾಗುವ ಹೋಸ್ಟ್ ಹೆಸರಾದರೆ, ವಿನಾಯಿತಿ ಕೆಟ್ಟದಾಗಿ ವಯಸ್ಸಾಗುತ್ತದೆ ಮತ್ತು ನಿಯಮಿತವೆಂದು ಕಂಡ ಮರುಸಂಪರ್ಕದ ನಂತರ ಸುರಂಗ ವಿಫಲವಾಗಬಹುದು. ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ನೀವು ನಿಯಂತ್ರಿಸುವ ವಿಳಾಸಕ್ಕೆ ಪಿನ್ ಮಾಡಿ, ಅಥವಾ ನಿರ್ವಾಹಕ ಅದನ್ನು ಮರುಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತಾನೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಮತ್ತು ಪ್ರತಿ ನೆಟ್‌ವರ್ಕ್ ಬದಲಾವಣೆಯ ನಂತರ ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನು ಮತ್ತೆ ಓದಿ.

ಅದೇ ಕಾರ್ಯವಿಧಾನವು ಪೂರ್ಣ ಸುರಂಗ ಮತ್ತು ಕ್ಯಾಪ್ಟಿವ್ ಪೋರ್ಟಲ್ ಏಕೆ ಹೋರಾಡುತ್ತವೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ. ಪೋರ್ಟಲ್ ಈಗ ನಿಮ್ಮ ಸುರಂಗ ಹಿಡಿಯುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತಿಬಂಧಿಸಲು ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೋಟೆಲ್ ಮತ್ತು ವಿಮಾನ ನಿಲ್ದಾಣದ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ನೀವು ಪೋರ್ಟಲ್ ಲಾಗಿನ್ ನಂತರ ಸುರಂಗವನ್ನು ಮೇಲೆ ತರುತ್ತೀರಿ, ಎಂದಿಗೂ ಮೊದಲು ಅಲ್ಲ.

ಗೇಟ್‌ವೇಯಲ್ಲಿ ಮುಂದೂಡಿಕೆ ಮತ್ತು ಮರಳು ಮಾರ್ಗ

ಗೇಟ್‌ವೇಯಲ್ಲಿ, ನೀವು ಸಾಗಿಸುವ ಕುಟುಂಬಕ್ಕೆ ಮುಂದೂಡಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ, ಅನುವಾದಿಸುವಾಗ forward ಸರಪಳಿಗೆ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಅನುಮತಿ ನೀಡಿ, ಮತ್ತು ಮೂಲ-ನಿರ್ದಿಷ್ಟ ಹುಡುಕಾಟದೊಂದಿಗೆ ಮರಳು ಮಾರ್ಗವನ್ನು ದೃಢೀಕರಿಸಿ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಯಶಸ್ವಿ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ನಿಂದ ಬರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಎರಡು ಪಿಯರ್‌ಗಳು UDP ವಿನಿಮಯ ಮಾಡಬಹುದು ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಡಿಕ್ಯಾಪ್ಸುಲೇಟ್ ಆದ ಪ್ಯಾಕೆಟ್‌ಗೆ ನಂತರ ಏನಾಗುತ್ತದೆ ಎಂದು ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

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

DNS ಮತ್ತು ವಿಫಲತೆ ಸ್ಥಿತಿ, ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಲಾಗಿದೆ

ಪ್ರೋಟೋಕಾಲ್ ಸ್ವತಃ ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಸಂರಚಿಸುವುದಿಲ್ಲ. wg-quick ವಿತರಣೆಯ ರಿಜಾಲ್ವರ್ ಸಂಯೋಜನೆಯ ಮೂಲಕ DNS ಸಾಲನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ತಮ್ಮದೇ ಸ್ಟ್ಯಾಕ್‌ಗಳಿರುವ ಕಂಟೇನರ್‌ಗಳು ಮತ್ತು ಬ್ರೌಸರ್‌ಗಳು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು, ಆದ್ದರಿಂದ ಸುರಂಗ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಪರಿಪೂರ್ಣವಾಗಿ ಸಾಗಿಸುತ್ತಿದ್ದರೂ ಹೆಸರು ವಿಫಲವಾಗಬಹುದು. ವಿಳಾಸದ ಬದಲು ಹೋಸ್ಟ್ ಹೆಸರಿನಿಂದ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಪ್ರೊಫೈಲ್‌ನ ಸರ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂದು ಊಹಿಸುವ ಬದಲು ಯಾವ ಸರ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂದು ಗಮನಿಸಿ.

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

ಕೊನೆಯದಾಗಿ, ಸುರಂಗ ನಿಲ್ಲುವಾಗ ನೀವು ಬಯಸುವ ಸ್ಥಿತಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ. ಪೂರ್ಣ ಸುರಂಗವು ತಾನು ಹೇಳಿಕೊಳ್ಳುವ ಟ್ರಾಫಿಕ್‌ಗೆ ಮುಚ್ಚಿದಂತೆ ವಿಫಲವಾಗಬೇಕು: ಇಂಟರ್‌ಫೇಸ್ ಕೆಳಗಿಳಿದರೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಭೌತಿಕ ಕೊಂಡಿಯ ಮೂಲಕ ಸದ್ದಿಲ್ಲದೆ ಮುಂದುವರಿದರೆ, ವಿನ್ಯಾಸವು ಹೆಚ್ಚುವರಿ ಹಂತಗಳಿರುವ ವಿಭಜಿತ ಸುರಂಗ. ಉದ್ದೇಶಿತ ವಿಫಲತೆ ವರ್ತನೆಯನ್ನು ಬರೆಯಿರಿ, ಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ನಾಲ್ಕು ಉತ್ತರಗಳನ್ನು ದಾಖಲಿಸಿ ಮುಗಿಸಿ — ಯಾವ ನಿರ್ವಾಹಕ ಇಂಟರ್‌ಫೇಸ್ ಮೇಲೆ ತರುತ್ತದೆ, ಯಾವ ಮಾರ್ಗ ಡೀಫಾಲ್ಟ್ ಸಾಗಿಸುತ್ತದೆ, ಗೇಟ್‌ವೇಯಲ್ಲಿ ಯಾರು ಮುಂದೂಡಿ ಅನುವಾದಿಸುತ್ತಾರೆ, ಮತ್ತು ಯಾವ ರಿಜಾಲ್ವರ್ ಉತ್ತರಿಸುತ್ತದೆ.

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