ਇੱਕ Pi, ਦੋ OpenVPN ਇੰਸਟੈਂਸ: ਹਰ ਯੂਨਿਟ ਕੀ ਪੜ੍ਹਦੀ ਹੈ
ਇੱਕ Pi ਉੱਤੇ ਦੋ OpenVPN ਡੈਮਨ ਵੱਖਰੀਆਂ ਕਾਨਫਿਗ ਫਾਈਲਾਂ ਪੜ੍ਹਦੇ ਹਨ ਅਤੇ ਵੱਖਰੇ ਹੁੱਕਾਂ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ। ਹਰ ਇੰਸਟੈਂਸ ਨੂੰ ਨਕਸ਼ੇ ਉੱਤੇ ਲਿਆਓ, ਫਿਰ ਪੇਲੋਡ ਮਾਰਗ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ।
ਪਰੋਫਾਈਲ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ OpenVPN ਪ੍ਰਕਿਰਿਆਵਾਂ ਗਿਣੋ। ਰੋਮਿੰਗ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਅਤੇ ਨਾਲ ਹੀ ਅੱਪਸਟ੍ਰੀਮ ਸੇਵਾ ਨੂੰ ਡਾਇਲ ਕਰਦਾ Pi ਦੋ ਡੈਮਨ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਤੁਹਾਡੇ ਦੁਆਰਾ ਟਾਈਪ ਕੀਤੇ ਇੰਸਟੈਂਸ ਨਾਂ ਨਾਲ ਚੁਣੀ ਕਾਨਫਿਗ ਫਾਈਲ ਪੜ੍ਹਦਾ ਹੈ। ਪੈਕੇਜ ਟੈਂਪਲੇਟ ਫਿਰ ਹਰ ਡੈਮਨ ਨੂੰ ਆਪਣੀ ਕਾਰਜ ਡਾਇਰੈਕਟਰੀ, ਆਪਣੀ ਰਨਟਾਈਮ ਸਥਿਤੀ ਫਾਈਲ ਅਤੇ ਆਪਣਾ ਟਨਲ ਯੰਤਰ ਦਿੰਦੇ ਹਨ। ਜੇ ਇਹ ਵੰਡ ਗਲਤ ਕੀਤੀ, ਤਾਂ ਤੁਸੀਂ ਉਸ ਫਾਈਲ ਵਿੱਚ ਸਹੀ ਸੈਟਿੰਗ ਬਦਲਣ ਵਿੱਚ ਇੱਕ ਸ਼ਾਮ ਲੰਘਾਓਗੇ ਜਿਸ ਨੂੰ ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਕਦੇ ਨਹੀਂ ਖੋਲ੍ਹਦੀ।
ਹਰ ਇੰਸਟੈਂਸ ਨਾਂ ਆਪਣੀ ਫਾਈਲ ਚੁਣਦਾ ਹੈ
OpenVPN 2.6 ਨਾਲ ਆਉਣ ਵਾਲੀਆਂ ਯੂਨਿਟ ਫਾਈਲਾਂ ਵਿੱਚ, ਸਟਾਰਟ ਆਰਗਿਊਮੈਂਟਾਂ ਵਿੱਚ @ ਚਿੰਨ੍ਹ ਤੋਂ ਬਾਅਦ ਦੇ ਟੈਕਸਟ ਨਾਲ ਭਰੀ ਜਾਣ ਵਾਲੀ ਇੰਸਟੈਂਸ ਪਲੇਸਹੋਲਡਰ ਹੁੰਦੀ ਹੈ। ਸਰਵਰ ਟੈਂਪਲੇਟ ਸਰਵਰ ਕਾਨਫਿਗ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਚੱਲਦਾ ਹੈ ਅਤੇ ਉੱਥੇ ਮੌਜੂਦ %i.conf ਵਿਰੁੱਧ ਆਪਣਾ ਆਰਗਿਊਮੈਂਟ ਹੱਲ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਕਲਾਇੰਟ ਟੈਂਪਲੇਟ ਕਲਾਇੰਟ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਇਹੀ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ [email protected] ਸਰਵਰ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ admits.conf ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ [email protected] ਕਲਾਇੰਟ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ uplink.conf ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ ਇਨ੍ਹਾਂ ਨਾਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦਾ ਵੀ ਦੂਜੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕੋਈ ਅਰਥ ਨਹੀਂ।
ਪੈਕੇਜ ਨੇ ਅੱਪਸਟ੍ਰੀਮ ਡਿਫਾਲਟ ਰੱਖੇ ਹਨ ਅਜਿਹਾ ਮੰਨਣ ਦੀ ਥਾਂ ਮਸ਼ੀਨ ਉੱਤੇ ਨਕਸ਼ਾ ਪੁਸ਼ਟ ਕਰੋ। ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦਾ drop-in ਕਾਰਜ ਡਾਇਰੈਕਟਰੀ ਜਾਂ ਕਾਨਫਿਗ ਆਰਗਿਊਮੈਂਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਸਕਦਾ ਹੈ।
systemctl cat [email protected]
systemctl cat [email protected]ਉਸ ਆਉਟਪੁੱਟ ਵਿੱਚ WorkingDirectory ਲਾਈਨ ਅਤੇ ਕਾਨਫਿਗ ਆਰਗਿਊਮੈਂਟ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਕਿਹੜੀ ਫਾਈਲ ਲੋਡ ਹੁੰਦੀ ਹੈ ਇਹ ਸਿਰਫ਼ ਸਰਗਰਮ ਯੂਨਿਟ ਤੈਅ ਕਰਦੀ ਹੈ। ExecStart ਵਿੱਚ --config ਜੋੜਨ ਵਾਲਾ drop-in ਟੈਂਪਲੇਟ ਦਾ ਰਾਹ ਸਹੀ ਦਿਸਣ ਦੇ ਬਾਵਜੂਦ ਟੈਂਪਲੇਟ ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ। ਸਥਾਨਕ ਓਵਰਰਾਈਡ ਚੱਲ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਜਾਣਨ ਲਈ ਫਰੈਗਮੈਂਟ ਅਤੇ drop-in ਦੇ ਰਾਹ ਪੁੱਛੋ। ਜੇ ਦੋਵੇਂ ਭੂਮਿਕਾਵਾਂ ਇੱਕ ਫਾਈਲ ਉੱਤੇ ਹੱਲ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟ ਦੋਵੇਂ ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਹੈ, ਅਤੇ ਉਸ ਫਾਈਲ ਵਿੱਚ ਪਿਛਲਾ ਵਿਕਲਪ ਚੁੱਪਚਾਪ ਜਿੱਤਦਾ ਹੈ।
ਸਥਾਨਕ ਆਵਾਜਾਈ ਅਤੇ ਫਾਰਵਰਡ ਕੀਤਾ ਪੇਲੋਡ ਵੱਖਰੇ ਹੁੱਕਾਂ ਉੱਤੇ ਟਕਰਾਉਂਦੇ ਹਨ
ਸਰਵਰ ਦਾ ਹਰ ਰੋਮਿੰਗ ਵਰਤੋਂਕਾਰ ਨਾਲ ਐਨਕ੍ਰਿਪਟਿਡ ਕਨੈਕਸ਼ਨ Pi ਉੱਤੇ ਹੀ ਬਣਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਦੇ ਬਾਹਰਲੇ ਜਵਾਬ ਸਥਾਨਕ ਆਉਟਪੁੱਟ ਹੁੱਕ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ। ਕਲਾਇੰਟ ਦਾ ਅੱਪਸਟ੍ਰੀਮ ਪੀਅਰ ਨਾਲ ਕਨੈਕਸ਼ਨ ਵੀ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਬਣਿਆ ਆਉਟਪੁੱਟ ਹੈ, ਭਾਵੇਂ ਇਹ ਦੂਰ ਦੇ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਫਾਰਵਰਡ ਕੀਤਾ ਪੇਲੋਡ ਤੀਜੀ ਸ਼੍ਰੇਣੀ ਹੈ, ਅਤੇ ਕਰਨਲ ਇਸ ਨੂੰ ਤਾਂ ਹੀ ਮਿਲਾਉਂਦਾ ਹੈ ਜਦੋਂ ਇਹ ਪੈਕੇਟ ਲਈ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਯੰਤਰ ਪਹਿਲਾਂ ਹੀ ਚੁਣ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ।
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
ਫਾਰਵਰਡ ਚੇਨ ਅੰਦਰ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਨਾਲ ਮਿਲਦਾ ਨਿਯਮ ਉਸ ਪੈਕੇਟ ਨੂੰ ਆਗਿਆ ਦੇ ਸਕਦਾ ਹੈ ਜਾਂ ਸੁੱਟ ਸਕਦਾ ਹੈ ਜੋ ਰਾਊਟਿੰਗ ਨੇ ਪਹਿਲਾਂ ਹੀ ਉਸ ਇੰਟਰਫੇਸ ਨੂੰ ਦਿੱਤਾ ਹੈ, ਪਰ ਇਹ ਕਦੇ ਇੰਟਰਫੇਸ ਨਹੀਂ ਚੁਣਦਾ। ਜਦੋਂ ਇੱਕ ਹੋਸਟ ਇੱਕ ਟਨਲ ਖ਼ਤਮ ਕਰਕੇ ਦੂਜਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਵਰਤੋਂਕਾਰ ਪੇਲੋਡ ਨੂੰ ਅੱਪਸਟ੍ਰੀਮ ਟਨਲ ਵਿੱਚ ਭੇਜਣ ਵਾਲੀ ਨੀਤੀ ਅਤੇ Pi ਦੇ ਆਪਣੇ ਐਨਕ੍ਰਿਪਟਿਡ ਜਵਾਬਾਂ ਦੀ ਰੱਖਿਆ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਦੋ ਵੱਖਰੇ ਫ਼ੈਸਲੇ ਹਨ। ਇਹ ਇਤਫ਼ਾਕਨ ਇੱਕੋ ਭੌਤਿਕ NIC ਉੱਤੇ ਪੈਂਦੇ ਹਨ, ਇਸ ਲਈ ਇਨ੍ਹਾਂ ਵਿੱਚ ਉਲਝਣ ਹੁੰਦੀ ਹੈ।
ਇਹ ਫ਼ਰਕ ਆਮ ਅੱਧ-ਅਸਫਲਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। ਵਰਤੋਂਕਾਰ ਜੁੜਦੇ ਹਨ, ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਵੀ ਉਨ੍ਹਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਗਲਤ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਹੈਂਡਸ਼ੇਕ ਸਥਾਨਕ ਸੀ ਅਤੇ ਪੇਲੋਡ ਫਾਰਵਰਡ ਸੀ ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਦੀ ਜਾਂਚ ਹੋਈ ਸੀ।
ਆਯਾਤ ਕੀਤਾ ਰਾਹ ਤੁਹਾਡੇ ਵਰਤੋਂਕਾਰਾਂ ਵੱਲ ਜਾਣ ਵਾਲੇ ਜਵਾਬ ਨਿਗਲ ਸਕਦਾ ਹੈ
ਕਲਾਇੰਟ ਪਰੋਫਾਈਲ ਦੀ ਸੁਰੱਖਿਆ ਸੈਟਿੰਗ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਅੱਪਸਟ੍ਰੀਮ Pi ਦੀ ਰਾਊਟਿੰਗ ਟੇਬਲ ਵਿੱਚ ਕੀ push ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਚੌੜਾ ਰੀਡਾਇਰੈਕਟ ਉਹ ਵਿਕਲਪ ਹੈ ਜੋ ਚੱਲਦੇ ਦੋਹਰੀ-ਭੂਮਿਕਾ ਹੋਸਟ ਨੂੰ ਟੁੱਟਿਆ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਜੇ push ਕੀਤਾ ਰਾਹ ਰੋਮਿੰਗ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਜਨਤਕ ਪਤਿਆਂ ਨੂੰ ਢਕਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਵੱਲੋਂ ਉਨ੍ਹਾਂ ਵੱਲ ਬਣਾਏ ਜਵਾਬ underlay ਰਾਹੀਂ ਬਾਹਰ ਜਾਣ ਦੀ ਥਾਂ ਨਵੇਂ ਰਾਹ ਨੂੰ ਲੱਭ ਕੇ ਅੱਪਸਟ੍ਰੀਮ ਟਨਲ ਵਿੱਚ ਵੜ ਸਕਦੇ ਹਨ। ਲੋਕ ਅਕਸਰ ਪ੍ਰਦਾਤਾ ਵੱਲ ਦਾ ਟਨਲ ਅਜੇ ਵੀ ਚੱਲਦਾ ਹੈ ਇਹ ਪੁਸ਼ਟ ਕਰਕੇ ਉੱਥੇ ਹੀ ਰੁਕ ਜਾਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਟ੍ਰੈਫਿਕ ਟਨਲ ਦਾ ਆਪਣਾ ਆਵਾਜਾਈ ਹੈ ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਗਲਤ ਵਿਵਹਾਰ ਕਰਦਿਆਂ ਵੀ ਵਗਦਾ ਰਹਿੰਦਾ ਹੈ।
ਸਰੋਤ ਜਾਂ mark ਅਧਾਰਿਤ ਨੀਤੀ ਹੀ ਦੋਵੇਂ ਧਾਰਾਵਾਂ ਨੂੰ ਵੱਖ ਰੱਖਣ ਦਾ ਤਰੀਕਾ ਹੈ। OpenVPN ਦਾ Linux mark ਵਿਕਲਪ ਡੈਮਨ ਦੇ ਆਪਣੇ ਐਨਕ੍ਰਿਪਟਿਡ ਪੈਕੇਟਾਂ ਉੱਤੇ ਫਾਇਰਵਾਲ mark ਲਾਉਂਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਫਿਰ ਰਾਊਟਿੰਗ ਨਿਯਮ ਸਮਰਪਿਤ ਟੇਬਲ ਵਿੱਚ ਭੇਜ ਸਕਦਾ ਹੈ। ਸਰੋਤ ਪਤੇ ਵੀ ਉੱਨੇ ਹੀ ਚੰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਸਰਵਰ ਦੇ ਬਾਹਰਲੇ ਜਵਾਬ ਹਮੇਸ਼ਾ ਇੱਕ underlay ਪਤੇ ਤੋਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ। ਦੋਵੇਂ ਪਹੁੰਚਾਂ ਨੂੰ ਉਸ ਟੇਬਲ ਵਿੱਚ ਵੈਧ ਰਾਹ ਅਤੇ ਪ੍ਰਦਾਤਾ ਦੇ endpoint ਲਈ ਛੋਟ ਚਾਹੀਦੀ ਹੈ, ਨਹੀਂ ਤਾਂ ਟਨਲ ਆਪ ਹੀ ਉੱਪਰ ਨਹੀਂ ਆਉਂਦਾ।
ਕੋਈ ਵੀ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਜਵਾਬ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਰਾਹ ਜਾਵੇਗਾ। ਹੇਠਾਂ ਦਿੱਤੇ ਪਤੇ Pi ਦੇ underlay ਪਤੇ ਅਤੇ ਇੱਕ ਰੋਮਿੰਗ ਵਰਤੋਂਕਾਰ ਦੇ ਜਨਤਕ ਪਤੇ ਲਈ ਪਲੇਸਹੋਲਡਰ ਹਨ।
ip rule show
ip route get 198.51.100.7 from 192.0.2.10ਵੰਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਭੂਮਿਕਾ ਰੋਕੋ
ਤਿੰਨ ਧਾਰਾਵਾਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਸਫਲ ਹੈਂਡਸ਼ੇਕ ਬਾਕੀ ਦੋ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਨਵਾਂ ਆਉਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰੋ, ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਐਪਲੀਕੇਸ਼ਨ ਅੱਪਸਟ੍ਰੀਮ ਨਿਕਾਸ ਰਾਹੀਂ ਭੇਜੋ, ਅਤੇ ਪੁਸ਼ਟ ਕਰੋ ਕਿ ਦੋਵੇਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਜੇ ਵੀ ਆਪਣੇ ਪੀਅਰਾਂ ਤੱਕ ਪਹੁੰਚਦੀਆਂ ਹਨ।
ਫਿਰ ਕਲਾਇੰਟ ਭੂਮਿਕਾ ਰੋਕੋ ਅਤੇ ਵੇਖੋ ਕਿ ਸਰਵਰ ਭੂਮਿਕਾ ਕੀ ਬਚਾਉਂਦੀ ਹੈ। ਇੱਕ ਇੰਸਟੈਂਸ ਲਈ ਸੀ ਪਰ ਦੋਵਾਂ ਉੱਤੇ ਲਾਗੂ ਹੋਇਆ ਰਾਹ ਜਾਂ mark ਨਿਯਮ ਲੱਭਣ ਦਾ ਇਹ ਸਭ ਤੋਂ ਸਸਤਾ ਤਰੀਕਾ ਹੈ।
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerਤੁਸੀਂ ਇਹ ਵੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਕਲਾਇੰਟ ਭੂਮਿਕਾ ਬੰਦ ਹੋਣ ਵੇਲੇ ਲਿਸਨਰ ਅਜੇ ਵੀ ਬੱਝਾ ਹੈ, ਟਨਲ ਯੰਤਰ ਅਜੇ ਵੀ ਮੌਜੂਦ ਹੈ ਅਤੇ ਲੌਗ ਨਵੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਮੁਕਤ ਹੈ। ਜੇ ਕਲਾਇੰਟ ਰੋਕਣ ਨਾਲ ਸਰਵਰ ਦੇ ਮੌਜੂਦਾ ਵਰਤੋਂਕਾਰਾਂ ਵੱਲ ਜਾਣ ਵਾਲੇ ਜਵਾਬ ਵੀ ਕੱਟ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਦੋਵੇਂ ਭੂਮਿਕਾਵਾਂ ਉਹ ਚੀਜ਼ ਸਾਂਝੀ ਕਰਦੀਆਂ ਹਨ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਤੱਕ ਸੀਮਤ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ। ਹਰ ਬਦਲਾਅ ਨੇ ਕਿਹੜੇ ਇੰਸਟੈਂਸ, ਕਿਹੜੀ ਕਾਨਫਿਗ ਫਾਈਲ ਅਤੇ ਕਿਹੜੇ ਧਾਰਾ ਮਾਲਕ ਨੂੰ ਛੋਹਿਆ ਇਹ ਲਿਖੋ, ਨਹੀਂ ਤਾਂ ਇਸ ਹੋਸਟ ਨੂੰ ਅੱਗੇ ਡੀਬੱਗ ਕਰਨ ਵਾਲਾ ਬੰਦਾ ਉਹੀ ਖੋਜ ਸਿਫ਼ਰ ਤੋਂ ਦੁਹਰਾਏਗਾ।