ਕਈ TAP ਕਲਾਇੰਟ ਲਈ ਹਰ ਇੱਕ ਦਾ ਵੱਖਰਾ ਸਰਵਰ ਪ੍ਰਕਿਰਿਆ, ਵੱਖਰਾ UDP ਪੋਰਟ ਅਤੇ ਹੋਸਟ 'ਤੇ ਵੱਖਰਾ TAP ਯੰਤਰ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੈ। Ethernet ਮੋਡ ਵਿੱਚ ਇੱਕ OpenVPN ਸਰਵਰ ਕਈ ਪ੍ਰਮਾਣਿਤ ਕਲਾਇੰਟ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਬ੍ਰਿਜ ਨਾਲ ਜੋੜ ਸਕਦਾ ਹੈ, ਅਤੇ ਪਰਤ 2 ਦੇ ਹਿੱਸੇ ਨੂੰ ਵਧਾਉਣ ਦਾ ਇਹੀ ਦਸਤਾਵੇਜ਼ੀ ਤਰੀਕਾ ਹੈ। ਇੱਕ-ਪ੍ਰਕਿਰਿਆ ਡਿਜ਼ਾਈਨ ਹੀ ਹੈ ਜੋ ਮੈਨੂਅਲ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇਹੀ ਸਹੀ ਡਿਫਾਲਟ ਹੈ।

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

ਦੋ ਆਰਕੀਟੈਕਚਰ, ਦੋ ਸੈਟਿੰਗ ਨਹੀਂ

ਰਾਊਟਿਡ TUN ਤੈਨਾਤੀ ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਸਰਵਰ ਦੇ ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਵਿੱਚ ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ ਲਿੰਕ ਦਿੰਦੀ ਹੈ। ਬ੍ਰਾਡਕਾਸਟ ਸਰਵਰ 'ਤੇ ਰੁਕ ਜਾਂਦੇ ਹਨ, ਕਲਾਇੰਟ ਇੱਕ ਦੂਜੇ ਦੇ ਫ੍ਰੇਮ ਨਹੀਂ ਦੇਖ ਸਕਦੇ, ਅਤੇ ਕਲਾਇੰਟਾਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਹੋਵੇ ਤਾਂ ਉਸਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਰਾਊਟ ਅਤੇ ਫਿਲਟਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਬ੍ਰਿਜ ਵਾਲੀ TAP ਤੈਨਾਤੀ ਕਲਾਇੰਟਾਂ ਨੂੰ ਇੱਕੋ Ethernet ਹਿੱਸੇ ਦੇ ਮੈਂਬਰ ਬਣਾ ਦਿੰਦੀ ਹੈ। ਉਹ ਬ੍ਰਾਡਕਾਸਟ ਦੇਖਦੇ ਹਨ, ARP ਨਾਲ ਇੱਕ ਦੂਜੇ ਨੂੰ ਲੱਭ ਸਕਦੇ ਹਨ, ਅਤੇ ਵੱਖ ਰਹਿਣ ਲਈ ਰਾਊਟਿੰਗ ਦੀ ਥਾਂ ਬ੍ਰਿਜ ਅਤੇ ਫਾਇਰਵਾਲ ਨੀਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਇਹ ਉਦੋਂ ਲਾਹੇਵੰਦ ਹੈ ਜਦੋਂ ਕਲਾਇੰਟ ਉਸੇ ਸਵਿੱਚ ਵਿੱਚ ਲੱਗੇ ਹੋਣ ਵਾਂਗ ਦਿਖਣੇ ਚਾਹੀਦੇ ਹਨ।

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

server-bridge ਸਹਾਇਕ ਕੀ ਕਰਦਾ ਹੈ

server-bridge ਸਹਾਇਕ ਬਹੁ-ਕਲਾਇੰਟ Ethernet ਮੋਡ ਕਨਫਿਗਰ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਪਤਾ-ਪੂਲ ਰੂਪ ਗੇਟਵੇ, ਨੈੱਟਮਾਸਕ ਅਤੇ ਬ੍ਰਿਜ ਵਾਲੇ ਸਬਨੈੱਟ ਦੇ ਅੰਦਰ ਸਮਰਪਿਤ ਰੇਂਜ ਲੈਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ 192.168.50.1 'ਤੇ ਗੇਟਵੇ ਅਤੇ 192.168.50.160 ਤੋਂ 192.168.50.199 ਤੱਕ ਪੂਲ।

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

ਬਾਹਰੀ ਸਰਵਰ ਪਤੇ ਦੇਣ ਵਾਲੀਆਂ ਤੈਨਾਤੀਆਂ ਲਈ DHCP-ਪ੍ਰੌਕਸੀ ਰੂਪ ਮੌਜੂਦ ਹੈ। ਇਸਦੀਆਂ ਆਪਣੀਆਂ ਪੂਰਵ ਸ਼ਰਤਾਂ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਰੂਪ ਮਿਲਾਉਣ ਨਾਲ ਠੀਕ ਉਹੀ ਟਕਰਾਅ ਪੈਦਾ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਦਸਤਾਵੇਜ਼ ਚੇਤਾਵਨੀ ਦਿੰਦੇ ਹਨ। ਬ੍ਰਿਜ ਵਾਲੇ ਸਬਨੈੱਟ ਲਈ ਇੱਕ ਹੀ ਅਲਾਟਕਰ ਚੁਣੋ।

ਅਲੱਗਾਅ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਗਿਣਤੀ ਤੋਂ ਨਹੀਂ ਆਉਂਦਾ

ਉਸੇ ਅਣ-ਸੀਮਤ ਬ੍ਰਿਜ ਨਾਲ ਜੁੜੀਆਂ ਅੱਠ OpenVPN ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਜੇ ਵੀ ਇੱਕੋ ਬ੍ਰਾਡਕਾਸਟ ਡੋਮੇਨ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ। ਕਲਾਇੰਟ ਬ੍ਰਿਜ ਰਾਹੀਂ ਇੱਕ ਦੂਜੇ ਲਈ ARP ਭੇਜ ਸਕਦੇ ਹਨ, ਅਤੇ ਸਰੋਤਿਆਂ ਦੀ ਗਿਣਤੀ ਨੇ ਇਸ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ।

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

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

ਕਦੋਂ ਕਈ ਪ੍ਰਕਿਰਿਆਵਾਂ ਫਿਰ ਵੀ ਸਹੀ

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

ਜੇ ਕਈ ਵਰਤੋ ਤਾਂ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣਾ ਸਰੋਤਾ ਅਤੇ ਯੰਤਰ-ਮਾਲਕੀ ਦਿਓ ਅਤੇ ਪਤਾ ਰੇਂਜਾਂ ਦਾ ਤਾਲਮੇਲ ਕਰੋ। ਜੋ ਦੋਵੇਂ ਸਰਵਰ ਮੰਨਦੇ ਹਨ ਕਿ ਉਸੇ ਬ੍ਰਿਜ 'ਤੇ ਉਹੀ ਪੂਲ ਉਹਨਾਂ ਦਾ ਹੈ, ਉਹ ਅੰਤ ਵਿੱਚ ਉਹੀ ਪਤਾ ਦੇਣਗੇ।

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

ਡਾਇਗ੍ਰਾਮ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲ ਰਹੇ ਹੋਸਟ ਤੋਂ ਬ੍ਰਿਜ ਅਤੇ ਸਰਵਰ ਮੋਡ ਪੜ੍ਹੋ। ਜੋ ਕਨਫਿਗਰੇਸ਼ਨ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਉਹੀ ਹੈ ਜੋ ਕਰਨਲ ਅਤੇ ਡੀਮਨ ਨੇ ਅਸਲ ਵਿੱਚ ਲੋਡ ਕੀਤਾ, ਅਤੇ ਸਮੀਖਿਅਕ ਵੀ ਉਹੀ ਜਾਂਚ ਸਕਦਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ