WireGuard ಟನೆಲ್ನ ಹೊರಗೆ ಒಂದು Linux ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೇಗೆ ಚಲಾಯಿಸುವುದು

ರೂಟ್ಗಳನ್ನು ಸಂಪಾದಿಸುವ ಮೂಲಕ ನೀವು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಪೂರ್ಣ ಟನೆಲ್ವಾಲಿನ WireGuard ಹೋಸ್ಟ್ನಿಂದ ಹೊರಗಿಡಲಾಗದು. ರೂಟ್ಗಳು ಗಮ್ಯಸ್ಥಾನದ ಪ್ರಕಾರ ಮಾರ್ಗವನ್ನು ಆರಿಸುತ್ತವೆ, ಮತ್ತು ನೀವು ಹೊರಗಿಡಲು ಬಯಸುವುದು ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ, ಆದ್ದರಿಂದ ಕರ್ನೆಲ್ಗೆ ಹೋಲಿಸಲು ಏನೂ ಇಲ್ಲ. ಕಾರ್ಯಸಾಧ್ಯವಾದ ವಿಧಾನವೆಂದರೆ ಆ ಪ್ರಕ್ರಿಯೆಗೆ ಅದರದೇ ಆದ ನೆಟ್ವರ್ಕ್ ಸಂದರ್ಭವನ್ನು ನೀಡುವುದು: ತನ್ನದೇ ಆದ ಇಂಟರ್ಫೇಸ್, ವಿಳಾಸಗಳು ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಹೊಂದಿರುವ ನೇಮ್ಸ್ಪೇಸ್, ಇದು veth ಜೋಡಿಯ ಮೂಲಕ ಹೋಸ್ಟ್ಗೆ ಸಂಪರ್ಕಿಸಲ್ಪಟ್ಟಿದೆ. ನಾನು ಇದನ್ನು Ubuntu 24.04 ನಲ್ಲಿ wireguard-tools 1.0.20210914 ಜೊತೆಗೆ ಚಲಾಯಿಸಿದೆ, ಮತ್ತು ನೇಮ್ಸ್ಪೇಸ್ ಎಂದಿಗೂ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ — ಸಮಸ್ಯೆ ಹೋಸ್ಟ್ನ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ ಮತ್ತು ಟನೆಲ್ನ ಮಾರ್ಕಿಂಗ್ ನಿಯಮಗಳಾಗಿದ್ದವು.

ಮೊದಲು ನಿಮಗೆ ಬೇಕಾದ ಸಂದರ್ಭದ ಪ್ರಕಾರವನ್ನು ಆರಿಸಿ

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಎರಡು ರೂಪಗಳು ಕಾಣಿಸುತ್ತವೆ. ಹೋಸ್ಟ್ ಪೂರ್ಣ ಟನೆಲ್ ಚಲಾಯಿಸುತ್ತಿದ್ದರೆ ಮತ್ತು ಒಂದು ಪ್ರೋಗ್ರಾಂ ISP ಮಾರ್ಗದಿಂದ ಹೊರಬರಬೇಕಿದ್ದರೆ, ನೀವು ಎರಡನೇ ನೇಮ್ಸ್ಪೇಸ್ ಅನ್ನು ನಿರ್ಮಿಸಿ, ಅದನ್ನು ಹೋಸ್ಟ್ಗೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಹೋಸ್ಟ್ ಅದಕ್ಕಾಗಿ ಸಂಚಾರವನ್ನು ಫಾರ್ವರ್ಡ್ ಮತ್ತು ಅನುವಾದಿಸಲು ಬಿಡುತ್ತೀರಿ. ನೇಮ್ಸ್ಪೇಸ್ ಈಗಾಗಲೇ VPN ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿದ್ದರೆ ಮತ್ತು ನಿಮಗೆ ಅದರೊಳಗೆ ಪ್ರಾರಂಭಿಸುವ ಆದೇಶ ಮಾತ್ರ ಬೇಕಿದ್ದರೆ, ಅದು ಸಾಮಾನ್ಯ ip netns exec ಪ್ರಕರಣ ಮತ್ತು ರೂಟಿಂಗ್ ಕೆಲಸದ ಬಹುಪಾಲು ಈಗಾಗಲೇ ಮುಗಿದಿದೆ.

ಯಾವುದೇ ರೂಪವೂ ಒಂದೇ ಪ್ರಕ್ರಿಯೆ ಐಡಿಗೆ ಸೀಮಿತವಾದ ನಿಯಮವನ್ನು ನೀಡುವುದಿಲ್ಲ. Netfilter ವಿಳಾಸಗಳು, ಪೋರ್ಟ್ಗಳು, ಮಾರ್ಕ್ಗಳು ಮತ್ತು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ; ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೆ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಇಲ್ಲ. ಮಾರ್ಕಿಂಗ್ ಸಂಚಾರವನ್ನು ನಿರ್ದೇಶಿಸಬಲ್ಲದು, ಆದರೆ ನೀವು ಈಗಾಗಲೇ ಗುರುತಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಮಾರ್ಕ್ ಅನ್ನು ಹಾಕಬೇಕು, ಮತ್ತು ಅದು ಒಂದು ಪದರ ಕೆಳಗಿನ ಅದೇ ಸಮಸ್ಯೆ. ನೇಮ್ಸ್ಪೇಸ್ ಆ ಪ್ರಕ್ರಿಯೆ ಮರಕ್ಕೆ ಇಡೀ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದೇ ಸಾಮಾನ್ಯ ಉತ್ತರ.

ಅಗತ್ಯವು ನಿಜವಾಗಿಯೂ ಟನೆಲ್ನಿಂದ ಏನೂ ಹೊರಬರಬಾರದು ಎಂದಾದರೆ, ಬದಲಿಗೆ ಟನೆಲ್ ಅನ್ನು ನಿಲ್ಲಿಸಿ. ನೇಮ್ಸ್ಪೇಸ್ ಮಿಶ್ರ ಪ್ರಕರಣಕ್ಕಾಗಿ ಇದೆ: ಒಂದು ಪ್ರೋಗ್ರಾಂ ಹೊರಗೆ, ಉಳಿದದ್ದೆಲ್ಲ ಒಳಗೆ, ಅದೇ ಯಂತ್ರದಲ್ಲಿ, ಅದೇ ಸಮಯದಲ್ಲಿ.

ಎರಡನೇ ಸಂದರ್ಭವನ್ನು ನಿರ್ಮಿಸಿ ಮತ್ತು ಅದನ್ನು ಹೋಸ್ಟ್ಗೆ ಸಂಪರ್ಕಿಸಿ

ಒಂದು ನಿದರ್ಶನ ವಿನ್ಯಾಸ: ಹೋಸ್ಟ್ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಹೊತ್ತಿರುವ WireGuard ಇಂಟರ್ಫೇಸ್ ಇದೆ, ಮತ್ತುclearnet ಎಂಬ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಇದೆ, ಅದು veth ಜೋಡಿಯ ಮೂಲಕ ಹೋಸ್ಟ್ಗೆ ಸಂಪರ್ಕಿಸಲ್ಪಟ್ಟಿದೆ. ಕೆಳಗಿನ ವಿಳಾಸಗಳು ಉದಾಹರಣೆಗಳು.

ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1

ಈ ನೇಮ್ಸ್ಪೇಸ್ ಈಗ ಹೋಸ್ಟ್ ಅನ್ನು ತಲುಪಬಲ್ಲದು ಮತ್ತು ಬೇರೆ ಎಲ್ಲೂ ಅಲ್ಲ. ಹೋಸ್ಟ್ ಸಂಚಾರವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕು ಮತ್ತು ಮೂಲ ವಿಳಾಸವನ್ನು ಮರುಬರೆಯಬೇಕು, ಏಕೆಂದರೆ 192.168.100.0/24 ಖಾಸಗಿಯಾಗಿದೆ ಮತ್ತು ಮೇಲಿನ ರೂಟರ್ನಿಗೆ ಅದರೊಳಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿಲ್ಲ:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE

ಮುಂದುವರಿಯುವ ಮೊದಲು ನೇಮ್ಸ್ಪೇಸ್ ಬದಿಯನ್ನು ಖಚಿತಪಡಿಸಿ.ip netns exec clearnet ip route veth ಮಾರ್ಗ ಮತ್ತು 192.168.100.1 ಮೂಲಕ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ತೋರಿಸಬೇಕು, ಮತ್ತು ಆ ವಿಳಾಸಕ್ಕೆ ping ಉತ್ತರಿಸಬೇಕು. ಹೋಸ್ಟ್ ವಿಳಾಸಕ್ಕೆ ping ವಿಫಲವಾದರೆ, ವಿಳಾಸಗಳು ಅಥವಾ ಲಿಂಕ್ ಸ್ಥಿತಿ ತಪ್ಪಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ firewall ನಿಯಮ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.

ಹೆಸರುಗಳು ಪರಿಹರಿಸಾಗಿ ಆದರೆ ಏನೂ ಹಿಂತಿರುಗದಿದ್ದಾಗ, FORWARD ಓದಿ

ಸಾಂಪ್ರದಾಯಿಕ ವೈಫಲ್ಯವು ರೂಟಿಂಗ್ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ: ನೇಮ್ಸ್ಪೇಸ್ ಹೆಸರನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ ಹೊರಡುತ್ತದೆ, ಮತ್ತು ಉತ್ತರ ಎಂದಿಗೂ ಬರುವುದಿಲ್ಲ. FORWARD ನೀತಿ DROP ಇರುವ ಹೋಸ್ಟ್ಗಳಲ್ಲಿ — ಹಲವು ವಿತರಣೆಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ ಗಟ್ಟಿಗೊಳಿಸಿದ ಇಮೇಜ್ಗಳು ಹಾಗೆ ಮಾಡುತ್ತವೆ — ಪ್ಯಾಕೆಟ್ ದಾರಿಯಲ್ಲಿ ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮುದ್ರಿಸುವ ದೋಷ ಫಿಲ್ಟರಿಂಗ್ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ.

ಏನನ್ನಾದರೂ ಸೇರಿಸುವ ಮೊದಲು ಸರಪಳಿಯನ್ನು ಓದಿ:

iptables -S FORWARD
nft list chain inet filter forward

ನಂತರ ಸಂಚಾರವನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಅನುಮತಿಸಿ, ಕೌಂಟರ್ಗಳೊಂದಿಗೆ, ನಿಯಮ ಎಂದಾದರೂ ಹೊಂದಿಕೆಯಾಯಿತೇ ಎಂದು ತಿಳಿಯಲು:

iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'

ಶೂನ್ಯ ಪ್ಯಾಕೆಟ್ ಕೌಂಟರ್ ಇರುವ ನಿಯಮ ಮಾರ್ಗದಲ್ಲಿಲ್ಲ. ಒಂದೋ ಇಂಟರ್ಫೇಸ್ ಹೆಸರುಗಳು ನೀವು ಊಹಿಸಿದ್ದಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿವೆ, ಅಥವಾ ಸರಪಳಿಯ ಹಿಂದಿನ ನಿಯಮವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮೊದಲು ಸ್ವೀಕರಿಸಿ, ಬಿಸಾಡಿ ಅಥವಾ ಹಿಂತಿರುಗಿಸಿದೆ. ಕ್ರಮವನ್ನು ಸರಿಪಡಿಸಿ, ನಿಯಮದ ಪಠ್ಯವನ್ನಲ್ಲ.

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

ಟನೆಲ್ನ ಮಾರ್ಕಿಂಗ್ ನಿಯಮಗಳನ್ನು ಹೊಸ ಮಾರ್ಗದಿಂದ ದೂರವಿಡಿ

ಈ ಹಂತವು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ನೇಮ್ಸ್ಪೇಸ್ ಅನ್ನು ಸೋರುವ ನೇಮ್ಸ್ಪೇಸ್ ಆಗಿ ಬದಲಿಸುತ್ತದೆ. WireGuard ಸೆಟಪ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ firewall ಮಾರ್ಕ್ ನೀತಿಯನ್ನು ತಮ್ಮದೇ ರೂಟಿಂಗ್ ನಿಯಮಗಳು ಮತ್ತು ಮೀಸಲಾದ ಟೇಬಲ್ನೊಂದಿಗೆ ಸ್ಥಾಪಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಮಾರ್ಕ್ ಇಲ್ಲದ ಪ್ಯಾಕೆಟ್ಗಳು ಮುಖ್ಯ ಟೇಬಲ್ಗೆ ಹಿಂತಿರುಗುತ್ತವೆ ಮತ್ತು ಮಾರ್ಕ್ ಮಾಡಿದ ಪ್ಯಾಕೆಟ್ಗಳು ಟನೆಲ್ ಟೇಬಲ್ ಬಳಸುತ್ತವೆ. ನೇಮ್ಸ್ಪೇಸ್ನಿಂದ ಫಾರ್ವರ್ಡ್ ಆದ ಸಂಚಾರವು ಹೊರಹೋಗುವಾಗ ನೀತಿ-ಆಧಾರಿತ ರೂಟಿಂಗ್ ವಿರುದ್ಧ ಮೌಲ್ಯಮಾಪನಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಆ ನಿಯಮಗಳನ್ನು ಹೇಗೆ ಬರೆಯಲಾಗಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಅದು ಟನೆಲ್ ಟೇಬಲ್ಗೆ ಬೀಳಬಹುದು.

ಎರಡು ಸೇರ್ಪಡೆಗಳು ಮಾರ್ಗಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತವೆ. ನೇಮ್ಸ್ಪೇಸ್ ಸಬ್ನೆಟ್ಗಾಗಿ mangle ಸರಪಳಿಯಲ್ಲಿ ಬೇಗ ಹಿಂತಿರುಗಿ, ಮತ್ತು ಆ ಸಬ್ನೆಟ್ ಅನ್ನು ಮುಖ್ಯ ಟೇಬಲ್ನಲ್ಲಿ ಇಡುವ ಮೂಲ-ಆಧಾರಿತ ನಿಯಮವನ್ನು ಸೇರಿಸಿ:

iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100

ನನ್ನ ಹೋಸ್ಟ್ನಲ್ಲಿ ಆದ್ಯತೆ 100 ಟನೆಲ್ ನಿಯಮಗಳ ಮೊದಲು ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಆ ಮೂಲಕ್ಕೆ ಸಾಮಾನ್ಯ ಟೇಬಲ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಸಂಖ್ಯೆಯನ್ನು ಕುರುಡಾಗಿ ನಕಲಿಸಬೇಡಿ:wg-quick ಸ್ಥಾಪಿಸುವ ಆದ್ಯತೆಗಳು ಆವೃತ್ತಿಗಳ ನಡುವೆ ಮತ್ತು IPv4 ಹಾಗೂ IPv6 ಸೆಟಪ್ಗಳ ನಡುವೆ ಭಿನ್ನವಾಗಿವೆ, ಆದ್ದರಿಂದ ಚಲಾಯಿಸಿip rule show ಮತ್ತು ನಿಮ್ಮ ಯಂತ್ರದಲ್ಲಿ ಟನೆಲ್ ನಿಯಮಗಳ ಮುಂದೆ ಬೀಳುವ ಆದ್ಯತೆಯನ್ನು ಆರಿಸಿ.

ನಿಯಮಗಳ ಪಟ್ಟಿಯನ್ನು ನಂಬುವ ಬದಲುಮೂಲ-ನಿರ್ದಿಷ್ಟ ಹುಡುಕಾಟ ಮೂಲಕ ಪರಿಶೀಲಿಸಿ:

ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1

ಮೊದಲ ಆದೇಶವು WireGuard ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ವರದಿ ಮಾಡಿದರೆ, ಹೊಸ ನಿಯಮ ಇನ್ನೂ ಟನೆಲ್ ನೀತಿಯ ಮುಂದಿಲ್ಲ. ಎರಡನೆಯದು ಇನ್ನೂ veth ಡೀಫಾಲ್ಟ್ ತೋರಿಸುತ್ತಿರುವಾಗ ಅದು WAN ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ವರದಿ ಮಾಡಿದರೆ, ಹೋಸ್ಟ್ ಮತ್ತು ನೇಮ್ಸ್ಪೇಸ್ ಒಪ್ಪುವುದಿಲ್ಲ ಮತ್ತು ನೀವು ಎರಡೂ ರೂಟಿಂಗ್ ಟೇಬಲ್ಗಳನ್ನು ಮತ್ತೆ ಓದಬೇಕು.

ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ

ಆದೇಶವನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಒಂದು ಸಾಲು, ಆದರೆ ಸಾಕೆಟ್ ಅನ್ನು ನಿಜವಾಗಿ ರಚಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ.ip netns exec clearnet curl -s https://ifconfig.me ಅತ್ಯಂತ ಚಿಕ್ಕ ಪ್ರಾಮಾಣಿಕ ಪರೀಕ್ಷೆ: ಇದು ನೇಮ್ಸ್ಪೇಸ್ ಜಗತ್ತಿಗೆ ತೋರಿಸುವ ವಿಳಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ, ಹೋಸ್ಟ್ ಬಳಸುವುದನ್ನಲ್ಲ.

ಸೇವೆಗಾಗಿ, ಪ್ರಕ್ರಿಯೆ ತನ್ನ ಇಡೀ ಜೀವಿತಾವಧಿಯಲ್ಲಿ ಅದರೊಳಗೆ ಇರಲು ನೇಮ್ಸ್ಪೇಸ್ ಅನ್ನು ಮಾರ್ಗದ ಮೂಲಕ ಜೋಡಿಸಿ:

[Service]
NetworkNamespacePath=/run/netns/clearnet

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

readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet

ಎರಡೂ ಔಟ್ಪುಟ್ಗಳು ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಅದೇ ಪರಿಶೀಲನೆ ಯಾವುದೇ ದೀರ್ಘಕಾಲ ಚಲಿಸುವ ಪ್ರೋಗ್ರಾಂಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಲಾಂಚರ್ ನಿಮ್ಮ ಉದ್ದೇಶವನ್ನು ಪೂರೈಸಿದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಒಮ್ಮೆ ಮಾಡುವುದು ಯೋಗ್ಯ.

ಹೆಸರಿನ ಪರಿಹಾರಕ್ಕೆ ತನ್ನದೇ ನಿರ್ಧಾರ ಬೇಕು. ನೇಮ್ಸ್ಪೇಸ್ ರಚಿಸುವುದು ಅದಕ್ಕೆ resolver ಸಂರಚನೆಯನ್ನು ನೀಡುವುದಿಲ್ಲ; ಪ್ರತಿ ನೇಮ್ಸ್ಪೇಸ್ ಫೈಲ್ಗಳನ್ನು ಇದರ ಮೂಲಕ ಬೆಂಬಲಿಸಲಾಗುತ್ತದೆ/etc/netns/<name>/resolv.conf, ಮತ್ತು ಅದಿಲ್ಲದೆ ನೀವು ತಪ್ಪಾಗಿ ಓದಲು ಸುಲಭವಾದ ವರ್ತನೆಯನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತೀರಿ. IPv6 ಗೂ ಅದೇ ನಡವಳಿಕೆ ಬೇಕು: ನೇಮ್ಸ್ಪೇಸ್ಗೆ v6 ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದರೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ v6 ಅನ್ನು ಇಷ್ಟಪಡುತ್ತಿದ್ದರೆ, ವಿನಂತಿಗಳು ಹಿಂದಕ್ಕೆ ಸರಿಯುವ ಮೊದಲು ನಿಲ್ಲಬಹುದು, ಅದು ಮುರಿದ ಟನೆಲ್ನಂತೆ ಕಾಣುತ್ತದೆ.

ಚೌಕಟ್ಟನ್ನು ಪರಿಶೀಲಿಸಿ, ಕೇವಲ ನಿರ್ಗಮನ ವಿಳಾಸವನ್ನಲ್ಲ

ಕೆಲಸ ಮಾಡುವ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಇಡೀ ಅಗತ್ಯವನ್ನಲ್ಲ. ಉಳಿದದ್ದನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ನಡೆಯಿರಿ:

• ip netns exec clearnet ip route get 1.1.1.1 veth ಡೀಫಾಲ್ಟ್ ತೋರಿಸುತ್ತದೆ, WireGuard ಇಂಟರ್ಫೇಸ್ ಅನ್ನಲ್ಲ.
• ವಿನಂತಿ ನಡೆಯುತ್ತಿರುವಾಗ ಎರಡೂ ನಿಯಮಗಳ FORWARD ಕೌಂಟರ್ಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ.
• ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕ್ರಿಯೆ ನೀವು ನಿರೀಕ್ಷಿಸುವ ನೇಮ್ಸ್ಪೇಸ್ inode ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ.
• ಮರುಬೂಟ್ನ ನಂತರ ಸೇವೆ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ನೇಮ್ಸ್ಪೇಸ್ ಇರುತ್ತದೆ; ಹಿಂದಿನ unit ವಿಫಲವಾಗುತ್ತದೆ, ಅಥವಾ ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿ, ನೇಮ್ಸ್ಪೇಸ್ನ ಹೊರಗೆ ಚಲಿಸುತ್ತದೆ.

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