WireGuard ಕ್ಲೈಂಟ್ OpenVPN ಕ್ಲೈಂಟ್ ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲವೇ?

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

ಲಕ್ಷಣದಲ್ಲಿ ಒಂದೊಮ್ಮೆ ಒಂದೇ ಭಾಗ ಕಾಣೆಯಾಗಿದೆ

ಈ ವಿನ್ಯಾಸವು wg1 ನಲ್ಲಿ 10.71.0.0/24 ನ WireGuard ಪೂಲ್ ಮತ್ತು tun1 ನಲ್ಲಿ 10.72.0.0/24 ನ OpenVPN ಪೂಲ್ ಬಳಸುತ್ತದೆ, ಎರಡೂ ಒಂದೇ ಗೇಟ್‍ವೇಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ಪರೀಕ್ಷೆಯಲ್ಲಿರುವ ವಿನಂತಿ 10.71.0.5 ನಿಂದ 10.72.0.30 ನ HTTPS ಗೆ ಹೋಗುತ್ತದೆ. ಕೆಳಗಿನ ಪ್ರತಿ ಹಂತವೂ ಆ ಒಂದೇ ಹರಿವಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಪ್ರತಿ ಪರಿಶೀಲನೆಗೂ ಬೇರೆ ವೈಫಲ್ಯದ ಗುರುತು ಇರುತ್ತದೆ, ಆದರೂ ಬಳಕೆದಾರರು ಅವನ್ನು ಒಂದೇ ರೀತಿ ಅನುಭವಿಸುತ್ತಾರೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಸಲಕ್ಕೆ ಮೂರರಲ್ಲಿ ಒಂದೇ ಕಾಣೆಯಾಗಿರುತ್ತದೆ.

ಎರಡೂ ಪೂಲ್‍ಗಳು ನಿಜವಾಗಿಯೂ ಈ ಗೇಟ್‍ವೇಯಲ್ಲಿವೆ ಮತ್ತು ಸುರಂಗಗಳು ಇರುವ namespace ನಲ್ಲಿ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿದೆ ಎಂದು ದೃಢೀಕರಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ. ಎರಡೂ ಪ್ರೋಟೋಕಾಲ್‍ಗಳನ್ನು ಬೇರೆ ಬೇರೆ namespace ಗಳಲ್ಲಿ ಕೊನೆಗೊಳಿಸುವ ಗೇಟ್‍ವೇ ಅವುಗಳ ನಡುವೆ ಏನನ್ನೂ ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ peer ಸಂರಚನೆಯನ್ನು ಓದುವ ಮೊದಲು ಅದನ್ನು ಹೊರಗಿಡುವುದು ಒಳ್ಳೆಯದು.

ಸ್ಪೋಕ್‍ನ ಗಮ್ಯ ವ್ಯಾಪ್ತಿಯನ್ನು ವಿಸ್ತರಿಸಿ

WireGuard ಕ್ಲೈಂಟ್‍ನಲ್ಲಿ, ಇರುವ peer ನಮೂದು OpenVPN ಗಮ್ಯಕ್ಕಾಗಿ ಗೇಟ್‍ವೇ ಆಯ್ಕೆ ಮಾಡಬೇಕು, ಅಂದರೆ ಗಮ್ಯ ಪೂರ್ವಪ್ರತ್ಯಯ ಆ peer ನ ಅನುಮತಿಸಿದ ಪಟ್ಟಿಯಲ್ಲಿ ಬರಬೇಕು. ಅದನ್ನು ಸೇರಿಸುವುದರಿಂದ ಎರಡನೇ ಸುರಂಗ ಉಂಟಾಗುವುದಿಲ್ಲ; ಆ ವಿಳಾಸವನ್ನು ಹುಡುಕುವಾಗ ಕ್ಲೈಂಟ್ ಯಾವ peer ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು wg-quick ಜೊತೆಗೆ ಮಾರ್ಗ ಸಾಮಾನ್ಯವಾಗಿ ಪಟ್ಟಿಯನ್ನು ತಾನಾಗಿಯೇ ಅನುಸರಿಸುತ್ತದೆ.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

ನಿಜವಾದ ಕೀಲಿ ಮತ್ತು endpoint ಸಾಲುಗಳನ್ನು ಮುಟ್ಟದೆ ಬಿಡಿ, ಮತ್ತು Table = off ಬಳಸುವ ನಿರ್ವಾಹಕ ಈ ಪಟ್ಟಿಯಿಂದ ಯಾವ ಮಾರ್ಗವನ್ನೂ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ನೆನಪಿಡಿ. ಅಂತಹ ಸಂದರ್ಭದಲ್ಲಿ ಅದೇ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಸಿಸ್ಟಮ್‍ನ ಮಾರ್ಗ ಕೋಷ್ಟಕದಲ್ಲಿ ಅದನ್ನು ಹೊಂದಿರುವವರೇ ಸ್ಥಾಪಿಸಬೇಕು, ಮತ್ತು ಅಲ್ಲಿ ಕಾಣೆಯಾದ ಮಾರ್ಗ ಕಾಣೆಯಾದ ಅನುಮತಿಸಿದ ಪೂರ್ವಪ್ರತ್ಯಯದಂತೆಯೇ ಕಾಣುತ್ತದೆ.

ಗೇಟ್‍ವೇಯಲ್ಲಿ ಮೂಲ ಮಾಲೀಕತ್ವವನ್ನು ಉಳಿಸಿ

ಈ ಕ್ಲೈಂಟ್‍ನ peer ನಮೂದು ಗೇಟ್‍ವೇಯಲ್ಲಿ ನಿಖರವಾಗಿ ಆ ಕ್ಲೈಂಟ್‍ನ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೊಂದಿರಬೇಕು. ಅನುಮತಿಸಿದ ವಿಳಾಸಗಳನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ: ಅವು ಹೊರಹೋಗುವ ಸಂಚಾರಕ್ಕೆ peer ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ ಮತ್ತು ಒಳಬರುವ ಪ್ಯಾಕೆಟ್‍ನ ಮೂಲ ಅದನ್ನು ಕಳುಹಿಸಿದ peer ಗೆ ಸೇರಿದೆ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತವೆ. ಸ್ಪೋಕ್ ಆ ಪೂಲ್ ತಲುಪಲು ಬಯಸುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ OpenVPN ಪೂಲ್ ಅನ್ನು ಸ್ಪೋಕ್‍ನ ನಮೂದಿಗೆ ಹಾಕುವುದು ಸಂಚಾರವನ್ನು ತಪ್ಪು ಭಾಗಿಯೆಡೆಗೆ ತಳ್ಳುವ ತಪ್ಪು.

AllowedIPs = 10.71.0.5/32

ಆ ನಮೂದನ್ನು ಮಾರ್ಗನಿರ್ದೇಶನದ ಅನುಕೂಲವಲ್ಲ, ಮಾಲೀಕತ್ವದ ಘೋಷಣೆ ಎಂದು ಓದಿ. ಕ್ಲೈಂಟ್ ತಲುಪಬೇಕಾದ ಉಳಿದ ಎಲ್ಲವೂ ಕ್ಲೈಂಟ್‍ನ ಗಮ್ಯ ಪಟ್ಟಿಗೆ ಸೇರುತ್ತದೆ, ಈ peer ಏನನ್ನು ಕಳುಹಿಸಬಹುದು ಎಂಬ ಗೇಟ್‍ವೇಯ ಕಲ್ಪನೆಗೆ ಅಲ್ಲ.

OpenVPN ಬದಿಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ನೀಡಿ

ಗಮ್ಯಕ್ಕೆ ಈಗ WireGuard ಮೂಲಕ್ಕೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಪೂಲ್ ಕ್ಲೈಂಟ್‍ಗಳಿಗೆ ಅದು ಸಾಮಾನ್ಯವಾಗಿ OpenVPN ಸರ್ವರ್‍ನಿಂದ ತಳ್ಳಲಾದ ಮಾರ್ಗವಾಗಿ ಬರುತ್ತದೆ. ಅದನ್ನು ಹೊಂದಿರಬೇಕಾದ ಕ್ಲೈಂಟ್‍ಗಳಿಗೆ ಮಾತ್ರ ತಳ್ಳಿ, ಮತ್ತು ನಿರ್ದೇಶವು ಅನ್ವಯವಾಯಿತು ಎಂದು ಊಹಿಸುವ ಬದಲು ಕ್ಲೈಂಟ್‍ನಲ್ಲಿ ಅದು ಸ್ವೀಕೃತವಾಯಿತು ಎಂದು ದೃಢೀಕರಿಸಿ.

push "route 10.71.0.0 255.255.255.0"

ಮಾರ್ಗ ವಿತರಣೆ ಅಧಿಕಾರವಲ್ಲ. ಗಮ್ಯವು ಪೂಲ್‍ನಲ್ಲಿ ಇರುವ ಬದಲು ಇನ್ನೊಂದು OpenVPN ಕ್ಲೈಂಟ್‍ನ ಹಿಂದೆ ಇದ್ದಾಗ, ಆ ಕ್ಲೈಂಟ್‍ನ ಸ್ವಂತ LAN ಮಾಲೀಕತ್ವ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಅಗತ್ಯಗಳು ವಿನ್ಯಾಸಕ್ಕೆ ಸೇರುತ್ತವೆ, ಮತ್ತು ತಳ್ಳಲಾದ ಮಾರ್ಗ ಮೊದಲ ಅರ್ಧ ಮಾತ್ರ. ನಿರ್ದೇಶಗಳನ್ನು ಸೇರಿಸುವ ಮೊದಲು ಅಗತ್ಯವನ್ನು ಗ್ರಾಫ್ ಆಗಿ ಮರುರೂಪಿಸಿ: ಯಾವ ನೋಡ್ ಯಾವ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಯಾವ ನೋಡ್ ಅದರ ಕಡೆಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ.

ನೀವು ಅನುಮತಿಸಲು ಉದ್ದೇಶಿಸಿದ್ದ ಅದೇ ಒಂದು ಸೇವೆಗೆ ಮಾತ್ರ ಅನುಮತಿ ಕೊಡಿ

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

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

ಪರಸ್ಪರ ಮಾರ್ಗಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಮೂಲ ಅನುವಾದದ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಅರ್ಥ, ಇದು ಗಮ್ಯದಲ್ಲಿ WireGuard ವಿಳಾಸವನ್ನು ಉಳಿಸುತ್ತದೆ ಮತ್ತು ಲಾಗ್‍ಗಳನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ಎರಡು ಪ್ರೋಟೋಕಾಲ್‍ಗಳು ಒಳಗೊಂಡಿವೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಸರ್ವಗ್ರಾಹಿ masquerading ಸೇರಿಸಬೇಡಿ, ಮತ್ತು ಇರುವ ಅನುವಾದ ನಿಯಮವನ್ನು ಅದರ ಮೇಲೆ ಏನು ಅವಲಂಬಿತವಾಗಿದೆ ಎಂದು ತಿಳಿಯದೆ ತೆಗೆದುಹಾಕಬೇಡಿ. ನಂತರ ಆ ಒಂದೇ ಹರಿವನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಒಂದು ನಿಷೇಧಿತ ಮೂಲ ಅಥವಾ ಪೋರ್ಟ್ ಅನ್ನೂ ಪರೀಕ್ಷಿಸಿ: ಎರಡೂ ಬದಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಕೈಹಿಡಿತ ಅಡ್ಡ ಮಾರ್ಗವನ್ನೂ ಅಲ್ಲ, ಪ್ರತ್ಯೇಕತೆಯನ್ನೂ ಅಲ್ಲ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.