WireGuard ಮೂಲಕ ಒಂದು ಅಪ್ಲಿಕೇಶನ್: ಬೈಂಡಿಂಗ್ ರೂಟಿಂಗ್ ಅಲ್ಲ

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

ಈ ಕಾರ್ಯವಿಧಾನಕ್ಕೆ ಎರಡು ಭಾಗಗಳಿವೆ: ಟನೆಲ್‌ನ ಸಂಚಾರ ಮಾತ್ರ ಬಳಸಬೇಕಾದ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ, ಮತ್ತು ಹೊಂದಿಕೆಯಾಗುವ ಮೂಲವನ್ನು ಅಲ್ಲಿಗೆ ಕಳುಹಿಸುವ ನಿಯಮ.

ಬೈಂಡಿಂಗ್ ಮೂಲ ವಿಳಾಸವನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ, ಅಷ್ಟೇ

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

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

ಟನೆಲ್‌ಗೆ ಅದರದೇ ಕೋಷ್ಟಕ ನೀಡಿ

wg-quick ಪ್ರೊಫೈಲ್ ಹೇಳಿದ ಕಡೆಯಲ್ಲೆಲ್ಲಾ ಮಾರ್ಗಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. [Interface] ಅಡಿಯಲ್ಲಿ Table = 40 ಸೇರಿಸಿದರೆ ಅವು ಮುಖ್ಯ ಕೋಷ್ಟಕದ ಬದಲು ಕೋಷ್ಟಕ 40 ಗೆ ಹೋಗುತ್ತವೆ. ಇಂಟರ್ಫೇಸ್ ಮೇಲೆ ಎತ್ತಿ ಅವು ತಲುಪಿದ್ದನ್ನು ಖಚಿತಪಡಿಸಿ: ip -4 route ls table 40 ಟನೆಲ್‌ನ ಮಾರ್ಗಗಳನ್ನು ತೋರಿಸಬೇಕು, ಮತ್ತು ip -4 route get 10.66.127.142 ಕರ್ನಲ್ ಈಗ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಮಾರ್ಗಗಳು ತಮ್ಮದೇ ಕೋಷ್ಟಕದಲ್ಲಿದ್ದಾಗ ಮುಖ್ಯ ಕೋಷ್ಟಕ ಉಳಿದ ಎಲ್ಲದಕ್ಕೂ ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ.

ಅಗಲವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಹೊಂದಿಸುವ ಬದಲು IPv6 ಗೂ ಅದೇ ಮಾಡಿ. ip -6 rule add from fd00::2/128 lookup 40 ಒಂದು ವಿಳಾಸವನ್ನು ಪಿನ್ ಮಾಡುತ್ತದೆ; fc00::/8 ಹೋಸ್ಟ್‌ನ ಇತರ ಇಂಟರ್ಫೇಸ್‌ಗಳೊಂದಿಗೆ ಘರ್ಷಿಸಿ ಉದ್ದೇಶಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೊಂದಿಕೆಯಾಗುವ ನಿಯಮವನ್ನು ಉಂಟುಮಾಡಬಹುದು.

ಮೂಲ ನಿಯಮ ಸೇರಿಸಿ ಮತ್ತು ಕೌಂಟರ್‌ಗಳನ್ನು ನೋಡಿ

ನಂತರ ಎರಡು ಭಾಗಗಳನ್ನು ಜೋಡಿಸಿ: ip -4 rule add from 10.66.127.142/32 lookup 40, ಅದೇ ವಿಳಾಸವನ್ನು WireGuard ಇಂಟರ್ಫೇಸ್‌ಗೆ ಜೋಡಿಸಿ. ಎರಡೂ ನಿಯಮಗಳನ್ನು PostUp ಗೆ ಹಾಕಿ, ಮರುಸಂಪರ್ಕ ಅವನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ. ಸೆಟ್ಟಿಂಗ್‌ನಿಂದಲ್ಲ, ನಿಜವಾದ ವಿನಂತಿಯಿಂದ ಪರಿಶೀಲಿಸಿ: ip route get 1.1.1.1 from 10.66.127.142 ಟನೆಲ್ ಸಾಧನವನ್ನು ಹೆಸರಿಸಬೇಕು, ಮತ್ತು curl --interface wg0 ifconfig.me ಮನೆಯ ವಿಳಾಸದ ಬದಲು ಟನೆಲ್‌ನ ವಿಳಾಸವನ್ನು ವರದಿ ಮಾಡಬೇಕು.

ಆಗಲೂ ವಿಫಲವಾದರೆ ip -s rule ಓದಿ. ಇರುವ ಆದರೆ ಎಂದೂ ಹೊಂದಿಕೆಯಾಗದ ನಿಯಮ ಶೂನ್ಯ ಕೌಂಟರ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ತಪ್ಪು ನಿಯಮವನ್ನು ನಿಯಮವೇ ಇಲ್ಲದಿರುವುದರಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಆ ಒಂದು ಆಜ್ಞೆಯೇ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಇಂಟರ್ಫೇಸ್ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಿತೇ ಎಂಬ ಊಹೆಯನ್ನು ಬಹಳಷ್ಟು ಉಳಿಸುತ್ತದೆ.

ವಿರುದ್ಧ ಸಂದರ್ಭ: SSH ಅನ್ನು ಟನೆಲ್‌ನ ಹೊರಗೆ ಇರಿಸಿ

ವಿರುದ್ಧ ಸಮಸ್ಯೆಯೂ ಅಷ್ಟೇ ಸಾಮಾನ್ಯ: wg-quick ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದ ಮಾಲೀಕ ಮತ್ತು ಸರ್ವರ್‌ಗೆ SSH ಸೆಶನ್ ಮಧ್ಯದಲ್ಲೇ ಸಾಯುತ್ತದೆ. ಅದರ ನಿಯಮಗಳು ಕಡಿಮೆ ಆದ್ಯತೆಯ ಸಂಖ್ಯೆಯಲ್ಲಿವೆ, ಆದ್ದರಿಂದ ಅಪವಾದವನ್ನು ಅವುಗಳಿಗಿಂತ ಮೊದಲು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು. ip rule add dport 22 ipproto tcp table main priority 123 ಇತ್ತೀಚಿನ iproute2 ನಲ್ಲಿ ಅದನ್ನು ಮಾಡುತ್ತದೆ; ಸೆಲೆಕ್ಟರ್ ಲಭ್ಯವಿಲ್ಲದಲ್ಲಿ nftables ನಲ್ಲಿ ಹರಿವನ್ನು ಗುರುತಿಸಿ ಬದಲಿಗೆ ಗುರುತಿಗೆ ಹೊಂದಿಸಿ.

ಪ್ರತ್ಯುತ್ತರದ ಮಾರ್ಗವನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಸ್ಥಾಪಿತವಾದ ನಂತರ ಮೌನವಾಗುವ SSH ಸೆಶನ್‌ಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಅಸಮಮಿತ ರೂಟಿಂಗ್ ಇರುತ್ತದೆ: ಒಂದು ದಿಕ್ಕು ಟನೆಲ್ ಮೂಲಕ ಮತ್ತು ಇನ್ನೊಂದು ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ. ಸರ್ವರ್ ವಿಳಾಸಕ್ಕೆ ip route get ಪ್ರತ್ಯುತ್ತರ ಯಾವ ಕಡೆಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ.

ಕೋಷ್ಟಕ ಸಂಖ್ಯೆ, ಮೂಲ ನಿಯಮ ಮತ್ತು ಅಪವಾದವನ್ನು ಪ್ರೊಫೈಲ್‌ನಲ್ಲೇ ದಾಖಲಿಸಿ. ಮೂರೂ ಒಂದೇ ವಿನ್ಯಾಸಕ್ಕೆ ಸೇರಿವೆ ಮತ್ತು ಜೊತೆಯಾಗಿ ಸಂಪಾದಿಸಲಾಗುತ್ತದೆ.