OpenVPN ਕਲਾਇੰਟਾਂ ਨੂੰ Cloudflare ਰਾਹੀਂ ਰੂਟ ਕਰੀਏ? ਪਹਿਲਾਂ ਭੂਮਿਕਾ ਜਾਂਚੋ
ਡਿਵਾਈਸ ਕਲਾਇੰਟ ਰਾਊਟਰ ਨਹੀਂ ਹੈ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ Cloudflare ਭੂਮਿਕਾ ਹੋਰ ਹੋਸਟਾਂ ਦੇ ਪੈਕਟ ਫਾਰਵਰਡ ਕਰਦੀ ਹੈ, ਫਿਰ ਸਰਵਰ ਦੀ ਆਪਣੀ ਟਨਲ ਨੂੰ ਇਸਦੇ ਪੁਰਾਣੇ ਰਾਹ 'ਤੇ ਰੱਖੋ।
ਤੁਹਾਡੇ ਕੋਲ ਚੱਲਦਾ OpenVPN ਸਰਵਰ ਹੈ ਅਤੇ ਇੱਕ ਹੋਸਟ ਹੈ ਜੋ Cloudflare ਦਾ ਡਿਵਾਈਸ ਸੌਫਟਵੇਅਰ ਵੀ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਅਗਲਾ ਸਪਸ਼ਟ ਕਦਮ ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ ਨੂੰ ਉੱਥੇ ਭੇਜਣਾ ਲੱਗਦਾ ਹੈ। ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਦੋ ਚੱਲਦੇ ਕਨੈਕਸ਼ਨ ਮਿਲ ਕੇ ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਨਹੀਂ ਬਣਦੇ। ਜਿਹੜੀ ਚੀਜ਼ ਘੱਟ ਹੈ ਉਹ ਦੂਜੇ ਦੇ ਪੈਕਟ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਭੂਮਿਕਾ ਹੈ, ਅਤੇ ਉਹ ਨੀਤੀ ਜੋ ਉਨ੍ਹਾਂ ਪੈਕਟਾਂ ਨੂੰ ਆਉਣ 'ਤੇ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਦੀ ਹੈ।
ਕਿਸੇ ਵੀ ਨਿਯਮ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਸਵਾਲ ਆਉਂਦੇ ਹਨ: ਕਿਹੜਾ ਟ੍ਰੈਫਿਕ ਅੰਦਰ ਆਉਂਦਾ ਹੈ, ਉਹ ਅੱਗੇ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ, ਜਵਾਬ ਵਾਪਸੀ ਦਾ ਰਾਹ ਕਿਵੇਂ ਲੱਭਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਉਹ ਦੂਜਾ ਰਾਹ ਫੇਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਡਿਜ਼ਾਈਨ ਕੀ ਕਰਦਾ ਹੈ। ਪਹਿਲੇ ਦੋ ਸਮਰੱਥਾ ਦੇ ਸਵਾਲ ਹਨ।
ਇੱਕ ਹੋਸਟ 'ਤੇ ਦੋ ਸੇਵਾਵਾਂ ਟ੍ਰਾਂਜ਼ਿਟ ਰਾਹ ਨਹੀਂ ਹਨ
ਡਿਵਾਈਸ ਕਲਾਇੰਟ ਉਸ ਮਸ਼ੀਨ 'ਤੇ ਪੈਦਾ ਹੋਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ ਜਿੱਥੇ ਇਹ ਚੱਲਦਾ ਹੈ। ਇਹ ਨਾਮ ਹੱਲ ਜਾਂ ਚੁਣੇ ਹੋਏ ਐਪਲੀਕੇਸ਼ਨ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਆਪਣੀ ਟਨਲ ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਨੀਤੀ ਉਸ ਡਿਵਾਈਸ ਦੇ ਵਰਤੋਂਕਾਰ ਅਤੇ ਉਸ ਡਿਵਾਈਸ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਲਿਖੀ ਗਈ ਹੈ। OpenVPN ਕਲਾਇੰਟ ਤੋਂ ਫਾਰਵਰਡ ਕੀਤਾ ਪੈਕਟ ਸਥਾਨਕ ਆਉਟਪੁੱਟ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਉਹੀ ਨਿਯਮ ਇਸਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਨਹੀਂ ਕਰਦੇ। ਇਹ ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਅਜਿਹੀ ਵਿਸਥਾਰ ਨਹੀਂ ਹੈ ਜਿਸਨੂੰ ਵਿਆਪਕ ਨਿਯਮ ਨਾਲ ਢੱਕਿਆ ਜਾ ਸਕੇ, ਕਿਉਂਕਿ ਇਹ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਸੌਫਟਵੇਅਰ ਪੈਕਟ ਨੂੰ ਕੁਝ ਵੀ ਦੇਖਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇਸ ਲਈ ਡਿਜ਼ਾਈਨ ਦਾ ਸਵਾਲ ਸਮਰੱਥਾ ਦਾ ਸਵਾਲ ਹੈ। ਜਾਂ ਤਾਂ ਸਥਾਪਿਤ ਉਤਪਾਦ ਕੋਲ ਹੋਰ ਨੈੱਟਵਰਕਾਂ ਲਈ ਟ੍ਰੈਫਿਕ ਫਾਰਵਰਡ ਕਰਨ ਵਾਲੀ ਦਸਤਾਵੇਜ਼ੀ ਭੂਮਿਕਾ ਹੈ, ਜਾਂ ਟ੍ਰਾਂਜ਼ਿਟ ਕਾਰਜ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਿਸੇ ਹੋਰ ਥਾਂ ਦਾ ਹੈ।
Cloudflare ਦੀ ਕਿਹੜੀ ਭੂਮਿਕਾ ਫਾਰਵਰਡ ਕਰ ਸਕਦੀ ਹੈ
Cloudflare ਦਾ ਡਿਵਾਈਸ ਕਲਾਇੰਟ ਵੱਖਰੇ ਦਾਇਰੇ ਵਾਲੇ ਮੋਡ ਦਿੰਦਾ ਹੈ: ਸਿਰਫ਼ ਨਾਮ ਹੱਲ, ਡਿਵਾਈਸ ਤੋਂ ਟ੍ਰੈਫਿਕ, ਅਤੇ ਕਈ ਵਾਰ ਦੋਵੇਂ। ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਮੋਡ ਹੋਸਟ ਨੂੰ ਦੂਜੀ ਟਨਲ ਰਾਹੀਂ ਆਉਣ ਵਾਲੀ ਨਿੱਜੀ ਰੇਂਜ ਲਈ ਰਾਊਟਰ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਸਮਰਪਿਤ ਰੂਟਿੰਗ ਭੂਮਿਕਾ ਆਪਣੇ ਕਨੈਕਟਰ, ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਤੇ ਨੈੱਟਵਰਕ ਮਾਡਲ ਵਾਲਾ ਵੱਖਰਾ ਉਤਪਾਦ ਹੈ।
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਰੂਟ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਪਿਤ ਭੂਮਿਕਾ ਜਾਂਚੋ। ਪੜ੍ਹੋ ਕਿ ਕਨੈਕਟਰ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਬਣਾਉਂਦਾ ਹੈ, ਇਹ ਖਾਸ ਪ੍ਰੀਫਿਕਸ ਜਾਂ ਡਿਫਾਲਟ ਰੂਟ ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਸਥਾਨਕ ਨੀਤੀ ਸਥਾਨਕ ਪੈਕਟਾਂ ਵਾਂਗ ਫਾਰਵਰਡ ਕੀਤੇ ਪੈਕਟਾਂ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ ਸਿਰਫ਼ ਸਥਾਨਕ ਟ੍ਰੈਫਿਕ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਨੁਵਾਦ ਨਿਯਮ ਭਾਵੇਂ ਕਿਵੇਂ ਲਿਖਿਆ ਹੋਵੇ, OpenVPN ਸਰਵਰ ਟ੍ਰਾਂਜ਼ਿਟ ਬਿੰਦੂ ਨਹੀਂ ਬਣ ਸਕਦਾ।
ਇੱਥੇ ਹੀ ਜਨਤਕ ਨਿਕਾਸ ਦੀ ਲੋੜ ਸਟੀਕ ਰੂਪ ਵਿੱਚ ਦੱਸਣੀ ਪੈਂਦੀ ਹੈ। ਫਾਰਵਰਡ ਕੀਤੇ ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ ਲਈ Cloudflare ਵੱਲੋਂ ਦਿੱਤਾ ਨਿਕਾਸ ਇੱਕ ਖਾਸ ਵਰਤੋਂ-ਕੇਸ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਉਸ ਸੇਵਾ ਦੇ ਸਾਹਮਣੇ ਪੁਸ਼ਟੀ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਹੈ।
ਬਾਹਰੀ ਟਨਲ ਨੂੰ ਨਵੇਂ ਰਾਹ ਤੋਂ ਆਜ਼ਾਦ ਰੱਖੋ
ਜਿਸ ਪਲ ਤੁਸੀਂ ਨਵੇਂ ਇੰਟਰਫੇਸ ਵੱਲ ਡਿਫਾਲਟ ਰੂਟ ਜੋੜਦੇ ਹੋ, ਉਸੇ ਪਲ ਸਰਵਰ ਦਾ ਆਪਣਾ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਇਸ ਲਈ ਮੁਕਾਬਲਾ ਕਰਨ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ OpenVPN ਕਲਾਇੰਟਾਂ ਨੂੰ ਦਿੱਤੇ ਜਵਾਬ ਅਤੇ ਮਸ਼ੀਨ ਵੱਲ ਤੁਹਾਡਾ SSH ਸੈਸ਼ਨ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਆਮ ਲੱਛਣ ਉਹ ਟਨਲ ਹੈ ਜੋ ਸਥਾਪਿਤ ਹੋ ਕੇ ਮਰ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਅਜਿਹਾ ਪ੍ਰਬੰਧਕ ਜੋ ਬਾਹਰ ਤਾਲਾ ਲੱਗ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਬਦਲਾਅ ਕੰਮ ਕਰਦਾ ਦਿਸਦਾ ਹੈ। ਐਂਡਪੌਇੰਟ ਲਈ ip route get ਦੀ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਸਰਵਰ ਦੀ ਆਪਣੀ ਢੋਆ-ਢੁਆਈ ਨੂੰ ਜਿੱਥੇ ਸੀ ਉੱਥੇ ਰੱਖਣ ਲਈ ਨੀਤੀ-ਅਧਾਰਿਤ ਰੂਟਿੰਗ ਜਾਂ ਹੋਸਟ ਰੂਟ ਵਰਤੋ। ਉਹ ਤੁਲਨਾ ਮਸ਼ੀਨ ਤੋਂ ਹੀ ਕਰੋ, ਕਿਉਂਕਿ ਸਰਵਰ ਦਾ ਆਪਣੇ ਰਾਹ ਬਾਰੇ ਆਪਣਾ ਨਜ਼ਰੀਆ ਹੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।
ਸਰਵਰ ਦੇ ਜਨਤਕ ਪਤੇ ਲਈ ਛੋਟ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਦੂਰ-ਸਥ ਪ੍ਰਬੰਧਕ ਦਾ ਵਾਪਸੀ ਰਾਹ ਵੱਖਰਾ ਪ੍ਰਵਾਹ ਹੈ। ਉਨ੍ਹਾਂ ਪ੍ਰਵਾਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਬਦਲਾਅ ਨੂੰ ਸਹਿੰਦਾ ਰਹਿਣਾ ਹੈ ਤੈਅ ਕਰੋ, ਫਿਰ ਪਹਿਲੇ ਦੇ ਬਾਕੀ ਸਾਰਿਆਂ ਨੂੰ ਢੱਕਣ ਦੀ ਧਾਰਨਾ ਦੀ ਥਾਂ ਹਰੇਕ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਅਨੁਵਾਦ ਨੂੰ ਇੱਕ ਪ੍ਰਵਾਹ ਤੱਕ ਸੀਮਿਤ ਕਰੋ
ਪ੍ਰਾਪਤ ਪੈਕਟ ਫਾਰਵਰਡਿੰਗ ਰਾਹ ਲੰਘਦੇ ਹਨ, ਸਥਾਨਕ ਆਉਟਪੁੱਟ ਰਾਹ ਨਹੀਂ, ਇਸ ਲਈ ਮਾਇਨੇ ਰੱਖਣ ਵਾਲਾ ਨਿਯਮ forward ਹੁੱਕ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਜਿੱਥੇ ਅਗਲੇ ਇੰਟਰਫੇਸ ਨੂੰ ਅਨੁਵਾਦ ਚਾਹੀਦਾ ਹੈ, ਉੱਥੇ ਸਰੋਤ ਨੂੰ ਕਲਾਇੰਟ ਪੂਲ ਤੱਕ, ਮੰਜ਼ਿਲ ਨੂੰ ਮਨਜ਼ੂਰ ਵਸਤੂ ਤੱਕ ਅਤੇ ਨਿਕਾਸ ਨੂੰ ਉਸ ਇੱਕ ਇੰਟਰਫੇਸ ਤੱਕ ਸੀਮਿਤ ਕਰੋ। ਸਿਰਫ਼ ਇੰਟਰਫੇਸ ਨਾਲ ਬੱਝਾ masquerade ਨਿਯਮ ਆਪਣੇ ਆਪ ਕੋਈ ਰਾਹ ਨਹੀਂ ਚੁਣਦਾ ਅਤੇ ਕਿਸੇ ਹੋਰ ਫਿਲਟਰ ਤੋਂ ਅੱਗੇ ਫਾਰਵਰਡਿੰਗ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ।
ਫੇਲ ਹੋਣ 'ਤੇ ਬੰਦ ਹੋਣ ਦਾ ਵਿਵਹਾਰ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ, ਫਿਰ ਇਸਦੀ ਜਾਂਚ ਕਰੋ। ਅਗਲਾ ਰਾਹ ਰੋਕੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਚੁੱਪਚਾਪ ਆਮ ਅਪਲਿੰਕ 'ਤੇ ਵਾਪਸ ਜਾਣ ਦੀ ਥਾਂ ਲੋੜੀਂਦਾ ਨਿਕਾਸ ਗੁਆ ਦਿੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਹੀ ਉਹ ਨਤੀਜਾ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਨਹੀਂ ਦੇਖਦਾ ਜਦ ਤੱਕ ਟ੍ਰੈਫਿਕ ਗਲਤ ਦਰਵਾਜ਼ੇ ਰਾਹੀਂ ਬਾਹਰ ਨਹੀਂ ਜਾਣ ਲੱਗਦਾ। ਨਾਮ ਹੱਲ ਅਤੇ IPv6 ਲਈ ਜਾਂਚ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਸਿਰਫ਼ v4 ਲਈ ਨਿਯਮ-ਸਮੂਹ v6 ਰਾਹ ਖੁੱਲ੍ਹਾ ਛੱਡ ਦਿੰਦਾ ਹੈ।
ਤੁਸੀਂ ਜਿਨ੍ਹਾਂ ਚਾਰ ਜਵਾਬਾਂ 'ਤੇ ਰੁਕੇ ਅਤੇ ਹਰੇਕ ਨੂੰ ਸਾਬਤ ਕਰਨ ਵਾਲਾ ਨਿਰੀਖਣ ਲਿਖੋ। ਜਿਸ ਟ੍ਰਾਂਜ਼ਿਟ ਰਾਹ ਦਾ ਤੁਸੀਂ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ, ਉਹੀ ਅਗਲੀ ਘਟਨਾ ਸਮੀਖਿਆ ਵਿੱਚ ਤੁਸੀਂ ਬਚਾ ਸਕਦੇ ਹੋ।