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

ಏನನ್ನೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ

ಪರಿಚಿತ ಜೋಡಣೆ ವೈರ್ಲೆಸ್ ರೇಡಿಯೊ ಮತ್ತು ವೈರ್ಡ್ ಪೋರ್ಟ್ ಅನ್ನು br0 ಒಳಗೆ ಇಡುತ್ತದೆ, ಬ್ರಿಡ್ಜ್ ವಿರುದ್ಧ hostapd ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು dnsmasq ನಿಂದ ಗುತ್ತಿಗೆಗಳನ್ನು ಹಂಚುತ್ತದೆ, ಆದರೆ OpenVPN ಕ್ಲೈಂಟ್ tun0 ರಚಿಸುತ್ತದೆ. ಆಗ ಮೂರು ಪ್ರತ್ಯೇಕ ಅಗತ್ಯಗಳು ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ: ಆಕ್ಸೆಸ್ ಪಾಯಿಂಟ್ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಗೇಟ್ವೇ ಆಗಿ Pi ಬೇಕು, Pi ಗೆ ತನ್ನ ಸರ್ವರ್ ತಲುಪಲು ಇಂಟರ್ನೆಟ್ಗೆ ರೂಟ್ ಬೇಕು, ಮತ್ತು ಬ್ರಿಡ್ಜ್ಗೆ ಆ ಕ್ಲೈಂಟ್ಗಳು ಬಳಸಬಹುದಾದ ಗೇಟ್ವೇ ವಿಳಾಸ ಬೇಕು.

ಬದಲಾಯಿಸುವ ಮೊದಲು ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಈ ನಾಲ್ಕು ಆದೇಶಗಳು ಇಂಟರ್ಫೇಸ್ ಸಮಸ್ಯೆಯನ್ನು ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ.

ip -br addr
ip route show
ip link show master br0
bridge link show

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

ಬ್ರಿಡ್ಜ್ಗೆ ಅದಕ್ಕೆ ಸೇರಿದ ಡಿಫಾಲ್ಟ್ ರೂಟ್ ನೀಡಿ

Raspberry Pi OS ಸಾಮಾನ್ಯವಾಗಿ ಬ್ರಿಡ್ಜ್ ಅನ್ನು ಡಿಫಾಲ್ಟ್ ರೂಟ್ ಇಲ್ಲದೆ ಬಿಡುತ್ತದೆ, ಇಂಟರ್ಫೇಸ್ ಫೈಲ್ ಬರೆದ ನಂತರ ಬ್ರಿಡ್ಜ್ ಹುಟ್ಟಿದ್ದರೆ. ಬ್ಲಾಕ್ /etc/dhcpcd.conf ನಲ್ಲಿ ಇರಬೇಕು, ಮತ್ತು ಅದು Pi ಅಲ್ಲ, ಮೇಲಿನ ರೌಟರ್ ಅನ್ನು ಹೆಸರಿಸಬೇಕು.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

ಆ ಉದಾಹರಣೆಯಲ್ಲಿ 192.168.50.1 ಇರುವ ರೌಟರ್ ಮತ್ತು 192.168.50.2 ಅದೇ ಸಬ್ನೆಟ್ನಲ್ಲಿ Pi ಯ ಬ್ರಿಡ್ಜ್ ವಿಳಾಸ, ಆದ್ದರಿಂದ ಸಂಖ್ಯೆಗಳನ್ನು ನಕಲಿಸುವ ಬದಲು ನಿಮ್ಮದೇ ಯೋಜನೆಯನ್ನು ಹಾಕಿ. ಬ್ರಿಡ್ಜ್ ಸದಸ್ಯರು ಸಹ ರೌಟರ್ಗಳನ್ನು ಕೇಳಬಾರದು, ಇಲ್ಲದಿದ್ದರೆ Pi ಗೆ ಸ್ಪರ್ಧಿಸುವ ಡಿಫಾಲ್ಟ್ಗಳು ಉಳಿಯುತ್ತವೆ, ಅವುಗಳ ವಿಜೇತ ಮೆಟ್ರಿಕ್ ಮತ್ತು ಸಮಯವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ, ಉದ್ದೇಶವನ್ನಲ್ಲ.

systemctl restart dhcpcd ನಂತರ ip route show default br0 ಅನ್ನು ಒಮ್ಮೆ ಪಟ್ಟಿ ಮಾಡಬೇಕು ಮತ್ತು ವೈರ್ಡ್ ಪೋರ್ಟ್ನಿಂದ ನಕಲು ಇರಬಾರದು. ಕೋಷ್ಟಕವಲ್ಲ, ಹುಡುಕಾಟವನ್ನು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಹಳೆಯ ನಮೂದು ಗೆಲ್ಲುವ ನಮೂದಿನ ಪಕ್ಕದಲ್ಲಿ ಕುಳಿತಿರಬಹುದು: ip -4 route get 203.0.113.10 br0 ಅನ್ನು ಹೆಸರಿಸಬೇಕು. ಆ ವಿಳಾಸ TEST-NET-3 ದಾಖಲೆ ಶ್ರೇಣಿಯಿಂದ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದನ್ನು ಓದುವಾಗ ಅದು ನಿಜವಾದ ಸರ್ವರ್ನೊಂದಿಗೆ ಘರ್ಷಿಸಲಾರದು.

ಟನೆಲ್ ತನ್ನದೇ ಸರ್ವರ್ಗೆ ಇರುವ ಪಥವನ್ನು ಅಪಹರಿಸದಂತೆ ತಡೆಯಿರಿ

redirect-gateway ಸ್ವೀಕರಿಸುವ OpenVPN ಕ್ಲೈಂಟ್ ಡಿಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ವಹಿಸಿಕೊಂಡು ಟನೆಲ್ಗೆ ತಿರುಗಿಸುತ್ತದೆ. ಪ್ರತಿ ಆಕ್ಸೆಸ್ ಪಾಯಿಂಟ್ ಕ್ಲೈಂಟ್ VPN ಬಳಸಬೇಕಾದಾಗ ಇದು ಸರಿ, ಮತ್ತು ಕೆಲವು ಗಮ್ಯಸ್ಥಾನಗಳು ಮಾತ್ರ ಬಳಸಬೇಕಾದಾಗ ತಪ್ಪು. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, Pi ಯ ಸರ್ವರ್ನೊಂದಿಗಿನ ಸ್ವಂತ ಸಂಪರ್ಕವು ಅದು ಇನ್ನೂ ನಿರ್ಮಿಸುತ್ತಿರುವ ಟನೆಲ್ನ ಒಳಗೆ ಹೋಗಬಾರದು. OpenVPN ಡಿಫಾಲ್ಟ್ ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸುವಾಗ ಮೂಲ ಗೇಟ್ವೇ ಮೂಲಕ ದೂರದತ್ತ ಹೋಸ್ಟ್ ರೂಟ್ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ಸಾರಿಗೆಯನ್ನು ಜೀವಂತವಾಗಿ ಇರಿಸುವ ವರ್ತನೆ; ಆ ರೂಟ್ ಇಲ್ಲದಿದ್ದರೆ, ಟನೆಲ್ ಸ್ಥಾಪಿತವಾದ ಕೂಡಲೇ ಕುಸಿಯುತ್ತದೆ.

ಸಂಪರ್ಕಕ್ಕೆ ಮೊದಲು ಮತ್ತು ನಂತರ ಆ ಸಾರಿಗೆ ಪಥದ ತ್ವರಿತ ಹೋಲಿಕೆ ಆ ಹತ್ತು ಸೆಕೆಂಡುಗಳಿಗೆ ಯೋಗ್ಯವಾಗಿದೆ. ip -4 route get 203.0.113.10 ಎರಡೂ ಸ್ಥಿತಿಗಳಲ್ಲಿ ಒಳಪದರದ ಸಾಧನವನ್ನು ಹೆಸರಿಸಬೇಕು, ಬದಲಾಗುವುದು ಮೆಟ್ರಿಕ್ ಮಾತ್ರ. ಟನೆಲ್ ಮೇಲಕ್ಕೆ ಬಂದ ನಂತರ ಅದು tun0 ಅನ್ನು ಹೆಸರಿಸಿದರೆ, ಹೋಸ್ಟ್ ರೂಟ್ ಎಂದೂ ಸ್ಥಾಪನೆಯಾಗಿಲ್ಲ ಮತ್ತು ಮುಂದಿನ ಮರುಸಂಪರ್ಕ ವಿಫಲವಾಗುತ್ತದೆ.

ಟನೆಲ್ ಅನ್ನು ಆಯ್ದ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಮಾತ್ರ ದಾಟಬೇಕಾದಾಗ, route-nopull ಬಳಸಿ ಮತ್ತು ಬೇಕಾದ ರೂಟ್ಗಳನ್ನು ಕೈಯಿಂದ ಸೇರಿಸಿ, ಅಥವಾ ಸರ್ವರ್ನಿಂದ ಸಣ್ಣ ಗುಂಪನ್ನು ಕಳುಹಿಸಿ. ಆ ವಿನ್ಯಾಸದಲ್ಲಿ ಬ್ರಿಡ್ಜ್ ಡಿಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು DNS ಮುಂದಿನ ನಿರ್ಧಾರವಾಗುತ್ತದೆ: dnsmasq ಅನ್ನು ಮನೆಯ ರಿಸಾಲ್ವರ್ಗೆ ಮುಂದಿಸುವುದು ನಿಜವಾಗಿ ಅಲ್ಲಿರುವ ಹೆಸರುಗಳಿಗೆ ಮಾತ್ರ ಅರ್ಥಪೂರ್ಣ.

ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು NAT ವಿಷಯವನ್ನು ನಿರ್ಧರಿಸಿ

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT ನಿಯಮವು ಸರ್ವರ್ ಆಕ್ಸೆಸ್ ಪಾಯಿಂಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಸ್ವೀಕರಿಸದಿದ್ದಾಗ ಕೆಲಸ ಮಾಡುವ ಶಾರ್ಟ್ಕಟ್, ಆದರೆ ಅದರ ಬೆಲೆ ದೂರದ ಲಾಗ್ಗಳಲ್ಲಿ ಪ್ರತಿ ಕ್ಲೈಂಟ್ Pi ಯ ಟನೆಲ್ ವಿಳಾಸವಾಗಿ ಕಾಣುವುದು. NAT ಇಲ್ಲದೆ ಪ್ರಿಫಿಕ್ಸ್ ರೂಟ್ ಮಾಡುವುದು ವಿಳಾಸಗಳನ್ನು ಗೋಚರವಾಗಿ ಇಡುತ್ತದೆ ಮತ್ತು ಮನೆಯ ಬದಿಯಲ್ಲಿ 192.168.50.0/24 ಗೆ ಮರಳು ರೂಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ಫೈರ್ವಾಲ್ ನಿಯಮಗಳ ಪಕ್ಕದಲ್ಲಿ ಆಯ್ಕೆಯನ್ನು ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ವಿನ್ಯಾಸದಲ್ಲಿ ಅಗೋಚರವಾದ NAT ನಿಯಮ ಆರು ತಿಂಗಳ ನಂತರ ವಿವರಿಸಲಾಗದಂತಾಗುತ್ತದೆ. IPv6 ಅನ್ನು ಅದೇ ನಿರ್ಧಾರದಲ್ಲಿ ಇಡಿ; ಮುರಿದ IPv6 ಪಥದ ಪಕ್ಕದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ IPv4 ಪಥ ಬ್ರೌಸರ್ನಲ್ಲಿ ಇನ್ನೂ ಅರ್ಧ ಮುರಿದಂತೆಯೇ ಓದುತ್ತದೆ.

ಕ್ಲೈಂಟ್ನಿಂದ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಸ್ವಚ್ಛವಾಗಿ ಹಿಂತಿರುಗಿಸಿ

ಆಕ್ಸೆಸ್ ಪಾಯಿಂಟ್ನಲ್ಲಿರುವ ಫೋನ್ ಅಥವಾ ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ ಈ ಕ್ರಮದಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ: dnsmasq ನಿಂದ ಗುತ್ತಿಗೆ, ಬ್ರಿಡ್ಜ್ ವಿಳಾಸಕ್ಕೆ ping, ನಂತರ ಟನೆಲ್ನ ದೂರದ ಬದಿಯಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನ. ಪ್ರತಿ ಹಂತವೂ ಒಂದು ಪದರವನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಒಂದೇ ನಿರುಪಯುಕ್ತ ವೈಫಲ್ಯವನ್ನು ಉತ್ಪಾದಿಸುವ ಬದಲು.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

ನಂತರ Pi ಗೆ ಇನ್ನೂ ತನ್ನದೇ ಹೊರಹೋಗುವ ಪಥ ಇದೆ ಎಂದು ದೃಢೀಕರಿಸಿ: ip route get 203.0.113.10 ಒಳಪದರದ ಸಾಧನವನ್ನು ಹೆಸರಿಸಬೇಕು, ಮತ್ತು ಸರ್ವರ್ ICMP ಗೆ ಅನುಮತಿ ನೀಡಿದರೆ ping -c 3 -I br0 203.0.113.10 ಉತ್ತರಿಸಬೇಕು. ಮೊದಲ ಎರಡು ಕ್ಲೈಂಟ್ ಹಂತಗಳು ಉತ್ತೀರ್ಣವಾಗಿ ಮೂರನೆಯದು ವಿಫಲವಾದರೆ, ದೋಷ ಫಾರ್ವರ್ಡಿಂಗ್ ಅಥವಾ NAT ನಲ್ಲಿದೆ. ಎರಡನೆಯ ಹಂತ ವಿಫಲವಾದರೆ, ಬ್ರಿಡ್ಜ್ ಅಥವಾ DHCP ಇನ್ನೂ ಅಪೂರ್ಣವಾಗಿದೆ.

ರೋಲ್ಬ್ಯಾಕ್ ಒಂದು ಫೈಲ್ ಸಂಪಾದನೆ ಮತ್ತು ಎರಡು ಆದೇಶಗಳು: ಬ್ಲಾಕ್ ತೆಗೆದುಹಾಕಿ, dhcpcd ಮರುಪ್ರಾರಂಭಿಸಿ, ಮತ್ತು ಡಿಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ip route replace default via 192.168.50.1 dev br0 ನಿಂದ ಬದಲಾಯಿಸಿ. ನಿರ್ವಹಣಾ ಕಿಟಕಿ ಮುಚ್ಚುವ ಮೊದಲು ಇದನ್ನು ಮಾಡಿ, ನಂತರವಲ್ಲ, ಏಕೆಂದರೆ ಡಿಫಾಲ್ಟ್ ರೂಟ್ ಕಳೆದುಕೊಂಡ Pi ಅನ್ನು ಸರಿಪಡಿಸಲು ನೀವು ಬಳಸುವ ನೆಟ್ವರ್ಕ್ನಿಂದಲೇ ತಲುಪಲಾಗದು.

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