ਸਿਰਫ਼ TCP 443 ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੇ ਨੈੱਟਵਰਕ UDP ਨੂੰ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਲੰਘਣ ਦੇਣ ਵਾਲੇ ਨੈੱਟਵਰਕਾਂ ਨਾਲ ਇਕੱਠੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਸਰਵਰ ਨੂੰ ਦੋਵਾਂ ਦੀ ਸੇਵਾ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। proto udp ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ ਦੂਜੇ ਸਮੂਹ ਨੂੰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪਹਿਲੇ ਉੱਤੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਅਤੇ proto tcp ਕਹਿਣ ਲਈ ਉਹੀ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਸੋਧਣ ਨਾਲ ਦੂਜਾ ਸਰੋਤਾ ਨਹੀਂ ਬਣਦਾ। ਇਹ ਨਿਰਦੇਸ਼ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਲਈ ਇੱਕ ਹੀ ਟਰਾਂਸਪੋਰਟ ਚੁਣਦਾ ਹੈ। ਬਾਕੀ ਸਭ ਇਸ ਸੀਮਾ ਤੋਂ ਨਿਕਲਦਾ ਹੈ।

ਜਾਂ ਤੁਸੀਂ ਇੱਕ ਤੋਂ ਵੱਧ ਪ੍ਰਕਿਰਿਆਵਾਂ ਚਲਾਓ, ਜਾਂ ਅਜਿਹਾ ਸੰਸਕਰਣ ਚਲਾਓ ਜੋ ਇੱਕੋ ਸਮੇਂ ਕਈ ਸਾਕਟ ਬੰਨ੍ਹ ਸਕੇ।

2.7 ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਹੀ ਟਰਾਂਸਪੋਰਟ ਬੰਨ੍ਹਦੀ ਹੈ

ਕਮਿਊਨਿਟੀ OpenVPN ਉਹ ਸਾਕਟ ਬੰਨ੍ਹਦਾ ਹੈ ਜਿਸ ਦਾ proto ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਨਿਰਦੇਸ਼ ਇੰਸਟੈਂਸ ਲਈ ਇੱਕ ਹੀ ਟਰਾਂਸਪੋਰਟ ਚੁਣਦਾ ਹੈ। TCP ਅਤੇ UDP ਵੱਖਰੇ ਸਟੈਕ ਹਨ, ਇਸ ਲਈ ਉਹੀ ਪੋਰਟ ਨੰਬਰ ਇੱਕੋ ਸਮੇਂ ਦੋਵੇਂ ਲੈ ਸਕਦੇ ਹਨ, ਪਰ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ। ਇਸ ਲਈ 2.6 ਲੜੀ ਤੁਹਾਨੂੰ ਹਰ ਡੈਮਨ ਲਈ ਇੱਕ ਟਰਾਂਸਪੋਰਟ ਦਿੰਦੀ ਹੈ। OpenVPN 2.7 ਨੇ ਸਰਵਰਾਂ ਲਈ ਇਹ ਸੀਮਾ ਹਟਾ ਦਿੱਤੀ, ਜੋ ਇੱਕ ਹੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਕਈ --local ਬਿਆਨਾਂ ਰਾਹੀਂ ਕਈ ਸਾਕਟ ਬੰਨ੍ਹ ਸਕਦੇ ਹਨ।

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

ਦੋ ਇੰਸਟੈਂਸ ਚਲਾਉਣ ਦੇ ਤਿੰਨ ਤਰੀਕੇ

TAP ਇੰਟਰਫ਼ੇਸ ਨਾਲ, ਹਰ ਟਰਾਂਸਪੋਰਟ ਲਈ ਇੱਕ ਇੰਸਟੈਂਸ ਚਲਾਓ ਅਤੇ ਹੋਸਟ ਉੱਤੇ ਦੋ tap ਜੰਤਰ ਬ੍ਰਿਜ ਕਰੋ। ਦੋਵੇਂ ਕਲਾਇੰਟ ਸਮੂਹ ਇੱਕੋ ਬਰਾਡਕਾਸਟ ਡੋਮੇਨ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਇੱਕ ਪਤਾ ਪੂਲ ਉਨ੍ਹਾਂ ਨੂੰ ਢਕ ਸਕਦਾ ਹੈ ਅਤੇ ਬਰਾਡਕਾਸਟ ਉੱਤੇ ਨਿਰਭਰ ਪ੍ਰੋਟੋਕਾਲ ਕੰਮ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ। TUN ਨਾਲ ਬ੍ਰਿਜਿੰਗ ਉਪਲਬਧ ਨਹੀਂ, ਇਸ ਲਈ ਸਭ ਤੋਂ ਸਧਾਰਨ ਵੰਡ ਹਰ ਇੰਸਟੈਂਸ ਨੂੰ ਆਪਣਾ ਸਬਨੈੱਟ ਦਿੰਦੀ ਹੈ ਅਤੇ ਰਾਊਟਿੰਗ ਦੋਵੇਂ ਕਲਾਇੰਟ ਸਮੂਹ ਵੱਖਰੇ ਰੱਖਦੀ ਹੈ। ਤੀਜਾ ਵਿਕਲਪ ਇੱਕ ਹੀ ਪੂਲ ਰੱਖਦਾ ਹੈ: ਹਰ ਇੰਸਟੈਂਸ learn-address ਸਕ੍ਰਿਪਟ ਬੁਲਾਉਂਦਾ ਹੈ, ਜੋ ਉਸ ਇੰਸਟੈਂਸ ਦੇ ਜੰਤਰ ਰਾਹੀਂ ਕਲਾਇੰਟ ਲਈ /32 ਰੂਟ ਸਥਾਪਤ ਕਰਦੀ ਹੈ।

ਉਹ ਤੀਜੀ ਬਣਤਰ ਹੀ ਹੈ ਜੋ ਲੋਕ ਮੰਗਦੇ ਹਨ ਅਤੇ ਜਿਸ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਧਿਆਨ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਕ੍ਰਿਪਟ ਡੇਟਾ ਪਥ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸ਼ਾਮਲ ਕਰਨ, ਅੱਪਡੇਟ ਕਰਨ ਤੇ ਮਿਟਾਉਣ ਦੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਠੀਕ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਹੈ।

ArrangementInterfacesAddress poolCost
Bridged TAP pairTwo tap devices joined by a bridgeOne shared poolBroadcast traffic and bridge maintenance
Two TUN subnetsTwo tun devices, no bridgeOne pool per instanceRouting rules and two plans
Shared pool with routesTwo tun devices plus a hookOne pool across bothA script on the data path

ਦੋਵੇਂ ਇੰਸਟੈਂਸ ਵੱਖਰੇ ਰੱਖੋ

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

ਯੂਨਿਟਾਂ ਅਤੇ ਪ੍ਰੋਫਾਈਲਾਂ ਦੇ ਨਾਂ ਇਸ ਤਰ੍ਹਾਂ ਰੱਖੋ ਕਿ ਫ਼ਾਈਲ ਨਾਂ ਤੋਂ ਹੀ ਟਰਾਂਸਪੋਰਟ ਸਪਸ਼ਟ ਹੋਵੇ। ਅਗਲੇ ਆਪਰੇਟਰ ਨੂੰ ਇਹ ਜਾਣਨ ਲਈ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਖੋਲ੍ਹਣੀ ਨਾ ਪਵੇ ਕਿ ਕਿਹੜਾ TCP ਹੈ।

ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਸਰੋਤੇ ਨਾਲ ਮਿਲਾਓ

proto tcp ਚਲਾਉਂਦਾ ਸਰਵਰ proto tcp-client ਵਾਲੇ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਾਲੇ ਵੀ proto udp ਰੱਖਣ ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ ਉਸ ਸਰੋਤੇ ਸਾਮ੍ਹਣੇ ਬਿਨਾਂ ਉਸ ਗਲਤੀ ਦੇ ਸਮਾਂ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਵਰਤੋਂਕਾਰ ਕਾਰਵਾਈ ਕਰ ਸਕੇ। ਜੇ ਡਿਪਲੌਇਮੈਂਟ ਦੋਵੇਂ ਟਰਾਂਸਪੋਰਟ ਦਿੰਦਾ ਹੈ ਤਾਂ ਦੋ ਪ੍ਰੋਫਾਈਲ ਰੱਖੋ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਲੇਬਲ ਕਰੋ ਕਿ ਸਹਾਇਤਾ ਨੂੰ ਪਤਾ ਲੱਗੇ ਕਿਹੜਾ ਅਜ਼ਮਾਇਆ ਗਿਆ। ਸਿਰਫ਼ ਪੋਰਟ ਨੰਬਰ ਟਰਾਂਸਪੋਰਟ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦਾ।

ਫ਼ਾਇਰਵਾਲ ਨਿਯਮ ਉਹੀ ਵੰਡ ਅਪਣਾਉਂਦੇ ਹਨ: UDP 1194 ਲਈ ਨਿਯਮ TCP 1194 ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਅਤੇ ਇੱਕ ਪਤੇ ਲਈ ਨਿਯਮ ਦੂਜੇ ਸਰੋਤੇ ਨੂੰ ਨਹੀਂ ਢਕਦਾ।

ਪਹਿਲਾਂ ਸਰਵਰ ਦਾ ਦ੍ਰਿਸ਼ ਪੜ੍ਹੋ

ਸਰਵਰ ਉੱਤੇ ss -lntup ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ TCP ਅਤੇ UDP ਦੋਵੇਂ ਸਰੋਤੇ ਦਿਖਦੇ ਹਨ। ਫਿਰ ਹਰ ਕਿਸਮ ਦਾ ਇੱਕ ਕਲਾਇੰਟ ਜੋੜੋ ਅਤੇ ਵੱਖਰੇ ਪਤਿਆਂ ਵਾਲੀਆਂ ਦੋ ਐਂਟਰੀਆਂ ਲਈ ਸਥਿਤੀ ਆਉਟਪੁੱਟ ਜਾਂਚੋ। ਜੇ ਸਾਕਟ ਹਨ ਅਤੇ ਕੋਈ ਕਲਾਇੰਟ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਡੈਮਨ ਦੇ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪਥ ਜਾਂ ਫ਼ਾਇਰਵਾਲ ਪੈਕਟ ਰੱਦ ਕਰ ਰਹੇ ਹਨ।

ਕਦੇ ਨਾ ਦਿਖਣ ਵਾਲਾ ਸਾਕਟ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਜਾਂ ਬਾਈਂਡ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਦਿਖ ਕੇ ਵੀ ਕਦੇ ਕਨੈਕਸ਼ਨ ਦਰਜ ਨਾ ਕਰਨ ਵਾਲਾ ਸਾਕਟ ਫਿਲਟਰਿੰਗ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਕਲਾਇੰਟ ਤੋਂ ਦੋਵੇਂ ਇੱਕੋ ਜਿਹੇ ਦਿਖਦੇ ਹਨ, ਇਸੇ ਲਈ ਸਰਵਰ ਦਾ ਆਪਣਾ ਦ੍ਰਿਸ਼ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ। ਧਿਆਨ ਰੱਖੋ ਕਿ TCP ਵਿੱਚ ਹੈੱਡ-ਆਫ਼-ਲਾਈਨ ਬਲਾਕਿੰਗ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਇਹ ਦੇਣਾ ਸਾਫ਼ UDP ਪਥ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਲਈ ਸੁਧਾਰ ਨਹੀਂ ਸਗੋਂ ਪਹੁੰਚ ਦਾ ਉਪਾਅ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ