ਸਰਵਰ ਜਾਂ ਕਲਾਇੰਟ: ਦੋਹਰੀ ਭੂਮਿਕਾ ਵਾਲੇ Pi ਉੱਤੇ ਕਿਹੜੀ OpenVPN ਯੂਨਿਟ

ਇੱਕ Pi ਉੱਤੇ ਦੋ OpenVPN ਪ੍ਰੋਸੈਸ ਚੱਲਦੇ ਹਨ, ਜੋ ਇੱਕੋ ਸਮੇਂ ਘੁੰਮਦੇ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਉੱਪਰਲੇ ਪ੍ਰਦਾਤਾ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਉਹ ਹਾਰਡਵੇਅਰ ਤੋਂ ਬਿਨਾਂ ਲਗਭਗ ਕੁਝ ਵੀ ਸਾਂਝਾ ਨਹੀਂ ਕਰਦੇ। ਇੱਕ ਆਉਂਦੀਆਂ ਸੁਰੰਗਾਂ ਸੁਣਦਾ ਹੈ ਜਦਕਿ ਦੂਜਾ ਬਾਹਰ ਡਾਇਲ ਕਰਦਾ ਹੈ। ਹਰ ਇੱਕ ਆਪਣੀ ਡਾਇਰੈਕਟਰੀ ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਆਪਣਾ ਅਸਫਲਤਾ ਢੰਗ ਹੈ। ਗਲਤ ਯੂਨਿਟ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨਾ ਉਹ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਕਲਾਇੰਟ-ਸੁਧਾਰ ਇਸ ਦੀ ਬਜਾਏ ਸੁਣਨ ਵਾਲੇ ਨੂੰ ਹਿਲਾ ਦਿੰਦਾ ਹੈ।

ਯੂਨਿਟ ਦਾ ਨਾਮ ਉਸ ਡਾਇਰੈਕਟਰੀ ਨਾਲ ਮਿਲਾਓ ਜੋ ਇਹ ਲੋਡ ਕਰਦੀ ਹੈ

Upstream 2.6 ਦੋ ਟੈਂਪਲੇਟ ਯੂਨਿਟ ਦਿੰਦਾ ਹੈ, [email protected] ਅਤੇ [email protected]। ਸਰਵਰ ਟੈਂਪਲੇਟ /etc/openvpn/server ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉੱਥੋਂ %i.conf ਲੋਡ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ ਟੈਂਪਲੇਟ /etc/openvpn/client ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। roaming ਨਾਂ ਵਾਲਾ ਇੰਸਟੈਂਸ ਇੱਕੋ ਸਮੇਂ ਦੋਵੇਂ ਥਾਵਾਂ ਉੱਤੇ ਹੋ ਸਕਦਾ ਹੈ, ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟ ਵਜੋਂ, ਦੋ ਅਸੰਬੰਧਿਤ ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਨਾਲ ਅਤੇ ਸਟ੍ਰਿੰਗ ਤੋਂ ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਕੋਈ ਕੜੀ ਨਹੀਂ।

ਫਾਈਲ ਸਿਸਟਮ ਦੀ ਬਜਾਏ systemd ਨੂੰ ਪੁੱਛੋ, ਕਿਉਂਕਿ ਪੈਕੇਜ ਬਣਾਉਣ ਵਾਲੇ ਵਾਧੂ ਫਾਈਲਾਂ ਜੋੜਦੇ ਹਨ ਜੋ ਕੰਮ ਵਾਲੀ ਡਾਇਰੈਕਟਰੀ ਜਾਂ ਬਾਈਨਰੀ ਨੂੰ ਮਿਲਣ ਵਾਲੇ ਆਰਗਿਊਮੈਂਟ ਬਦਲ ਸਕਦੀਆਂ ਹਨ।

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

ਪਹਿਲਾ ਕਮਾਂਡ ਹਰ ਬਣਾਈ ਗਈ ਯੂਨਿਟ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ, ਜੋ ਅਸਫਲ ਹੋ ਕੇ ਲੋਡ ਰਹੀਆਂ ਵੀ ਸ਼ਾਮਲ ਹਨ। ਦੂਜਾ ਯੂਨਿਟ ਫਾਈਲ ਨੂੰ ਕਿਸੇ ਵੀ ਓਵਰਰਾਈਡ ਸਮੇਤ ਛਾਪਦਾ ਹੈ। ਤੀਜਾ ਸਵਾਲ ਤੈਅ ਕਰਨ ਵਾਲੀਆਂ ਦੋ ਤੱਥਾਂ ਨੂੰ ਦੇਖਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ: ਜਿਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਸ ਨੂੰ ਦਿੱਤਾ ਗਿਆ ਕੌਂਫਿਗਰੇਸ਼ਨ ਪਾਥ।

ਪੈਕਟ ਦੀ ਦਿਸ਼ਾ ਨਾਲ ਫੈਸਲਾ ਕਰੋ, ਇੰਟਰਫੇਸ ਦੇ ਨਾਮ ਨਾਲ ਨਹੀਂ

ਸਰਵਰ ਇੰਸਟੈਂਸ ਕੋਲ ਸੁਣਨ ਵਾਲਾ ਸਾਕਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਹ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਇਸ ਦਾ ਐਨਕ੍ਰਿਪਟਿਡ ਟ੍ਰਾਂਸਪੋਰਟ Pi ਉੱਤੇ ਸਥਾਨਕ ਇਨਪੁਟ ਅਤੇ ਸਥਾਨਕ ਆਉਟਪੁਟ ਹੈ, ਜਦਕਿ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਇਹ ਜੋ ਟ੍ਰੈਫਿਕ ਅੱਗੇ ਭੇਜਦਾ ਹੈ ਉਹ ਫਾਰਵਰਡਿੰਗ ਮਾਰਗ ਦੀ ਪੈਰਵੀ ਕਰਦਾ ਹੈ ਅਤੇ ਨਿਯਮਾਂ ਦੇ ਦੂਜੇ ਸਮੂਹ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ ਇੰਸਟੈਂਸ ਕੋਲ ਉਸ ਅਰਥ ਵਿੱਚ ਕੋਈ ਸੁਣਨ ਵਾਲਾ ਨਹੀਂ: ਇਹ ਇੱਕ ਸਾਥੀ ਵੱਲ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਦਾ ਐਨਕ੍ਰਿਪਟਿਡ ਟ੍ਰਾਂਸਪੋਰਟ ਹੇਠਲੀ ਪਰਤ ਵੱਲ ਸਥਾਨਕ ਆਉਟਪੁਟ ਹੈ।

ਇਹ ਅੰਤਰ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਨਿਯਮ ਕਿੱਥੇ ਆਉਂਦਾ ਹੈ। ਫਾਰਵਰਡ ਚੇਨ ਦੇ ਅੰਦਰ ਇੰਟਰਫੇਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਸਿਰਫ਼ ਉਸ ਟ੍ਰੈਫਿਕ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜੋ ਰਾਊਟਿੰਗ ਪਹਿਲਾਂ ਹੀ ਚੁਣ ਚੁੱਕੀ ਹੈ; ਇਹ ਕਦੇ ਵੀ ਮਾਰਗ ਨਹੀਂ ਚੁਣਦਾ। ਜਦੋਂ ਘੁੰਮਦੇ ਵਰਤੋਂਕਾਰ ਦੇ ਪੈਕਟ ਗਲਤ ਰਾਹ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਜਾਂਚਣ ਵਾਲੀ ਚੇਨ forward ਹੈ, output ਨਹੀਂ।

ਸਿਧਾਂਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਕਟ ਵੇਖੋ। udp/1194 ਨਾਲ ਬੱਧਾ ਸਰਵਰ ਸੁਣਨ ਵਾਲਾ ਸਾਕਟ ਦਿਖਾਉਂਦਾ ਹੈ। ਕਲਾਇੰਟ ਪ੍ਰਦਾਤਾ ਦੇ ਪਤੇ ਨਾਲ ਸੰਬੰਧ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਸੁਣਨ ਵਾਲਾ ਕੁਝ ਵੀ ਨਹੀਂ।

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

ਇੱਕ ਇੰਸਟੈਂਸ ਦਾ ਡਿਫਾਲਟ ਮਾਰਗ ਦੂਜੇ ਦੇ ਜਵਾਬ ਫੜ ਸਕਦਾ ਹੈ

ਉੱਪਰਲਾ ਕਲਾਇੰਟ ਧੱਕਦਾ redirect-gateway ਮਸ਼ੀਨ ਉੱਤੇ ਬਾਕੀ ਸਭ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਵਾਲਾ ਡਿਫਾਲਟ ਮਾਰਗ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਰਵਰ ਘੁੰਮਦੇ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਭੇਜਦਾ ਜਵਾਬ ਵੀ ਸ਼ਾਮਲ ਹਨ। OpenVPN ਸੁਰੰਗ ਪਹੁੰਚਯੋਗ ਰਹਿਣ ਲਈ ਆਪਣੇ ਸਾਥੀ ਪਤੇ ਲਈ ਇੱਕ ਅਪਵਾਦ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਉਹ ਅਪਵਾਦ ਹੋਟਲ ਦੇ ਨੈੱਟਵਰਕ ਉੱਤੇ ਬੈਠੇ ਫ਼ੋਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।

ਲੱਛਣ ਆਮ ਤੌਰ ਉੱਤੇ ਅਸਮਮਿਤ ਹੁੰਦਾ ਹੈ। ਹੱਥ ਮਿਲਾਉਣਾ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਕਲਾਇੰਟ ਜੁੜਿਆ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੇ ਜਵਾਬ ਪੈਕਟ ਤੋਂ ਬਾਅਦ ਟ੍ਰੈਫਿਕ ਮਰ ਜਾਂਦਾ ਹੈ। ਸਰੋਤ-ਆਧਾਰਿਤ ਨੀਤੀ ਰਾਊਟਿੰਗ, ਜਾਂ --mark ਨਾਲ ਸਰਵਰ ਇੰਸਟੈਂਸ ਉੱਤੇ ਲਾਇਆ ਪੈਕਟ ਮਾਰਕ, ਦੋਵੇਂ ਪ੍ਰਵਾਹਾਂ ਨੂੰ ਵੱਖ ਰੱਖਦਾ ਹੈ; ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਕੱਲਾ ਪੂਰਾ ਨਿਯਮ ਸਮੂਹ ਨਹੀਂ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਉਸ ਟੇਬਲ ਵਿੱਚ ਵੈਧ ਮਾਰਗ ਚਾਹੀਦੇ ਹਨ ਜੋ ਉਹ ਚੁਣਦੇ ਹਨ।

ਸੁਰੰਗ ਦੀ ਸਥਿਤੀ ਦੀ ਬਜਾਏ ਸਥਾਨਕ ਫੈਸਲਾ ਪਰਖੋ, ਕਿਉਂਕਿ OpenVPN ਪੈਕਟ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਕਰਨਲ ਸਰੋਤ ਅਤੇ ਇੰਟਰਫੇਸ ਚੁਣਦਾ ਹੈ।

ip route get 203.0.113.44
ip rule show

ਇੱਕ ਭੂਮਿਕਾ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਾਬਤ ਕਰੋ ਕਿ ਦੂਜੀ ਬਚੀ ਰਹੀ

ਜਦੋਂ ਦੋਵੇਂ ਭੂਮਿਕਾਵਾਂ ਇੱਕੋ ਹੇਠਲੀ ਪਰਤ ਉੱਤੇ ਨਿਰਭਰ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਵਰਤੋਂਕਾਰ ਟ੍ਰੈਫਿਕ ਫਾਰਵਰਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉੱਪਰਲਾ ਮਾਰਗ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ ਤਾਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇਸ ਦਾ ਸੁਣਨ ਵਾਲਾ ਜਾਂ ਇਸ ਦਾ ਪੂਲ ਬਦਲ ਰਹੇ ਹੋ ਤਾਂ ਪਹਿਲਾਂ ਸਰਵਰ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ। ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਬਾਅਦ ਵਿੱਚ ਦੋਵੇਂ ਯੂਨਿਟ ਪੱਕੇ ਕਰੋ, ਕਿਉਂਕਿ ਅਸਫਲ ਮੁੜ-ਸ਼ੁਰੂਆਤ ਦੂਜੀ ਭੂਮਿਕਾ ਨੂੰ ਪੁਰਾਣੀ ਸਥਿਤੀ ਨਾਲ ਚੱਲਦੀ ਛੱਡ ਸਕਦੀ ਹੈ।

ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕਣ ਦੀ ਸ਼ਰਤ ਲਿਖੋ: ਉੱਪਰਲੀ ਸੁਰੰਗ ਗੁਆਉਣ ਨਾਲ ਘੁੰਮਦੇ ਵਰਤੋਂਕਾਰ ਰੁਕਦੇ ਹਨ, ਜਾਂ Pi ਦੇ ਆਪਣੇ ਉੱਪਰਲੇ ਲਿੰਕ ਉੱਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ? DNS ਅਤੇ IPv6 ਨੂੰ ਵੀ ਸਪਸ਼ਟ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਧੱਕਿਆ ਰਿਜ਼ੋਲਵਰ ਅਕਸਰ ਉਸ ਮਾਰਗ ਨਾਲੋਂ ਵੱਧ ਜੀਵਦਾ ਹੈ ਜਿਸ ਨੇ ਇਸ ਨੂੰ ਲਾਭਦਾਇਕ ਬਣਾਇਆ।

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

ਬਦਲਾਅ ਨੂੰ ਸਿਰਫ਼ ਤਦ ਸਵੀਕਾਰ ਕਰੋ ਜਦੋਂ ਤਿੰਨ ਗੱਲਾਂ ਇੱਕੋ ਸਮੇਂ ਸੱਚ ਹੋਣ: ਨਵਾਂ ਆਉਂਦਾ ਕਨੈਕਸ਼ਨ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਫਾਰਵਰਡ ਕੀਤੀ ਐਪਲੀਕੇਸ਼ਨ ਲੋੜੀਂਦੇ ਨਿਕਾਸ ਰਾਹੀਂ ਆਪਣੇ ਟਿਕਾਣੇ ਪਹੁੰਚਦੀ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਪ੍ਰੋਸੈਸ ਅਜੇ ਵੀ ਆਪਣੇ ਉਮੀਦ ਕੀਤੇ ਸਾਥੀ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ। ਜੇ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਇੰਸਟੈਂਸ ਜਾਂ ਗਲਤ ਮਾਰਗ ਬਦਲਿਆ ਹੈ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਹੋਰ ਕੁਝ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਏ ਯੂਨਿਟ ਨੂੰ ਦੁਬਾਰਾ ਪੜ੍ਹਨਾ ਹੈ।