ਇੱਕ Pi 'ਤੇ hostapd ਅਤੇ OpenVPN: ਡਿਫ਼ਾਲਟ ਰੂਟ ਕਿਸਦਾ ਹੈ?
hostapd ਅਤੇ OpenVPN ਕਲਾਇੰਟ ਇੱਕ Pi ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹਨ, ਜਦੋਂ ਬ੍ਰਿਜ ਆਪਣਾ ਡਿਫ਼ਾਲਟ ਰੂਟ ਰੱਖਦਾ ਹੈ ਅਤੇ ਟਨਲ ਆਪਣੇ ਸਰਵਰ ਤੱਕ ਦਾ ਰਾਹ ਰੱਖਦਾ ਹੈ। ਕਮਾਂਡਾਂ ਅਤੇ ਰੋਲਬੈਕ।
ਫ਼ੋਨ ਐਕਸੈਸ ਪੁਆਇੰਟ ਨਾਲ ਜੁੜਦੇ ਹਨ, ਪਤਾ ਲੈਂਦੇ ਹਨ ਅਤੇ ਫਿਰ ਟਨਲ ਉੱਠਦੇ ਹੀ ਕਿਤੇ ਵੀ ਨਹੀਂ ਪਹੁੰਚਦੇ। ਉਸ ਹਾਲਤ ਵਿੱਚ 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 ਉਸ ਨੈੱਟਵਰਕ ਤੋਂ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ ਜੋ ਤੁਸੀਂ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਵਰਤੋਗੇ।