ನೆಟ್‌ವರ್ಕ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ WireGuard: ಸಾಕೆಟ್ ಏಕೆ ಹಿಂದೆ ಉಳಿಯಿತು

ನೀವು ಬಯಸಿದ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಪಟ್ಟಿಯಲ್ಲಿದೆ, ಅಪ್ಲಿಕೇಶನ್ ಅದಕ್ಕೆ ಬದ್ಧವಾಗಿದೆ, ಆದರೂ ಯಾವುದೇ ಟನೆಲ್ ಟ್ರಾಫಿಕ್ ಕಾಣಿಸುವುದಿಲ್ಲ. ಇದು ಒಂದು ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ರಚಿಸಿ ಇನ್ನೊಂದಕ್ಕೆ ಸರಿಸಿದ Linux ಕರ್ನಲ್‌ನ WireGuard ಸಾಧನದ ಲಕ್ಷಣ: ಇಂಟರ್ಫೇಸ್ ಸರಿಯಿತು, ಅದರ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ UDP ಸಾಕೆಟ್ ಸರಿಯಲಿಲ್ಲ. ಒಳಗಿನ ಟ್ರಾಫಿಕ್ ಮುಖ್ಯವಾಗುವ ಮೊದಲು ಎರಡೂ ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿರಬೇಕು. ಒಂದಲ್ಲ ಎರಡು ಸಂದರ್ಭಗಳನ್ನು ನೋಡಬೇಕೆಂದು ತಿಳಿದರೆ ಪರಿಶೀಲನೆ ಬೇಗ ಮುಗಿಯುತ್ತದೆ.

ರೋಗಲಕ್ಷಣ: ಸರಿಯಾದ ನೇಮ್‌ಸ್ಪೇಸ್, ಆದರೆ ಪ್ಯಾಕೆಟ್‌ಗಳಿಲ್ಲ

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

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

ಇದು ಸರಿಸುವಿಕೆಯಲ್ಲಿನ ದೋಷವಾಗಲ್ಲ ಮತ್ತು ಪೀರ್ನ ತಪ್ಪು ಸಂರಚನೆಯಲ್ಲ. ಕರ್ನಲ್ ಅನುಷ್ಠಾನ ಹೀಗೆಯೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು WireGuardನ ನೇಮ್‌ಸ್ಪೇಸ್ ದಾಖಲೆಗಳು ರಚನೆಯ ನಿಯಮವನ್ನು ನೇರವಾಗಿ ವಿವರಿಸುತ್ತವೆ.

ಸಾಕೆಟ್‌ಗೆ ಹುಟ್ಟಿದ ಸ್ಥಳ ಏಕೆ ಇದೆ

WireGuard ಸಾಧನವು ತನ್ನ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಸಾಗಣೆಗಾಗಿ ಒಂದು UDP ಸಾಕೆಟ್ ಹೊಂದಿರುತ್ತದೆ, ಮತ್ತು ಆ ಸಾಕೆಟ್ ಸಾಧನ ರಚಿಸುವ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲೇ ತೆರೆಯುತ್ತದೆ. ಲಿಂಕ್ ಆದೇಶದಿಂದ ಇಂಟರ್ಫೇಸ್ ಸರಿಸಿದರೆ ಕಾಣುವ ಸಾಧನ ಸರಿಯುತ್ತದೆ ಆದರೆ ಸಾಗಣೆ ಪ್ರಾರಂಭವಾದಲ್ಲೇ ಉಳಿಯುತ್ತದೆ. ಆಗ ಎರಡು ವಸ್ತುಗಳ ಮಾಲಿಕರು ಬೇರೆಯಾಗುತ್ತಾರೆ.

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

ಸಾಕೆಟ್ ಬೇಕಾದಲ್ಲೇ ಅದನ್ನು ರಚಿಸಿ

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

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

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

ಮಾರ್ಗದ ಎರಡೂ ಬದಿಗಳನ್ನು ಓದಿ

ಸಾಧನ ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿದ್ದಾಗ, ಎರಡು ನಿರ್ಣಯಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ನ ಸಂದರ್ಭದಿಂದ ಒಳಗಿನ ಹುಡುಕಾಟದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಸಾಕೆಟ್‌ನ ಮಾಲೀಕತ್ವದ ಸಂದರ್ಭದಿಂದ ಹೊರಗಿನ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

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

ಇನ್ನೊಂದು ಪರಿಶೀಲನೆ ದಾಖಲೆಯಲ್ಲಿ ಇರಬೇಕು: ಮರುಪ್ರಾರಂಭದ ನಂತರ ಸಾಧನ ಹೇಗೆ ರಚನೆಯಾಗುತ್ತದೆ. ಬೇರೆ ರಚನಾ ಸಂದರ್ಭದೊಂದಿಗೆ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಮತ್ತೆ ರಚಿಸುವ ನಿರ್ವಾಹಕ ಸಾಕೆಟ್‌ನ ಹುಟ್ಟಿದ ಸ್ಥಳವನ್ನು ಬದಲಿಸುತ್ತಾನೆ. ಒಂಮೆ ಕೆಲಸ ಮಾಡಿದ ಕೈಯಿಂದ ಸರಿಸುವಿಕೆ ನಿರ್ವಹಿಸಲಾಗುವ ಮಾರ್ಗದ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯವಲ್ಲ.