ਇੱਕ Linux ਗੇਟਵੇ 'ਤੇ ਦੋ OpenVPN ਕਲਾਇੰਟ: ਨੀਤੀ ਵੰਡੋ

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

ਕਰਨਲ ਤੈਅ ਕਰਦਾ ਹੈ, ਡੈਮਨ ਨਹੀਂ

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

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

ਹਰ ਨਕਲ ਨੂੰ ਆਪਣਾ ਸਰੋਤ-ਸਮੂਹ ਦਿਓ

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull ਸਰਵਰ ਵੱਲੋਂ ਧੱਕੇ ਰੂਟ ਨੂੰ ਸਥਾਨਕ ਸਾਰਣੀ ਤੋਂ ਬਾਹਰ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਨੀਤੀ ਦੀਆਂ ਸਾਰਣੀਆਂ ਸਪੱਸ਼ਟ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਤਾਂ ਤੁਸੀਂ ਇਹੀ ਚਾਹੁੰਦੇ ਹੋ। ਕੀ ਕੋਈ ਦਿੱਤਾ ਸਰਵਰ redirect-gateway ਵਿਕਲਪ ਵੀ ਧੱਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਫਿਲਟਰ ਰੂਪ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਇਹ ਮੰਨਣ ਦੀ ਥਾਂ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਵੇਖਣਾ ਬਿਹਤਰ ਹੈ।

ਮੈਟ੍ਰਿਕਸ ਲਿਖੋ: ਸਰੋਤ, ਸਾਰਣੀ, ਯੰਤਰ

ਹਰ ਕਲਾਇੰਟ ਸਮੂਹ ਲਈ, ਸਰੋਤ ਪਤੇ ਨਾਲ ਸਾਰਣੀ ਚੁਣਨ ਵਾਲਾ ਨਿਯਮ ਜੋੜੋ, ਫਿਰ ਲੋੜੀਂਦਾ ਰਾਹ ਉਸ ਸਾਰਣੀ ਵਿੱਚ ਰੱਖੋ:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

ਸੁਰੰਗ ਦੀ ਆਪਣੀ ਆਵਾਜਾਈ ਕਲਾਇੰਟ ਸਮੂਹ ਵਿੱਚ ਨਹੀਂ

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

ਸਥਾਨਕ ਪ੍ਰਬੰਧਨ ਸੈਸ਼ਨ ਅਤੇ ਹੇਠਲੀ ਪਰਤ ਦਾ ਰਾਹ ਨੀਤੀ ਦੀਆਂ ਸਾਰਣੀਆਂ ਤੋਂ ਬਾਹਰ ਸਪੱਸ਼ਟ ਰੱਖੋ। ਉਹ ਛੋਟਾਂ ਮੈਟ੍ਰਿਕਸ ਦੇ ਕੋਲ ਲਿਖੋ; ਉਹ ਡਿਜ਼ਾਈਨ ਦਾ ਹਿੱਸਾ ਹਨ, ਕਿਸੇ ਘਟਨਾ ਵੇਲੇ ਮੁੜ ਲੱਭਣ ਵਾਲਾ ਉਪਾਅ ਨਹੀਂ।

ਰਾਹ ਚੁਣਨਾ ਉਸਦੀ ਆਗਿਆ ਨਹੀਂ

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

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

ਇੱਕ ਸੁਰੰਗ ਡਿੱਗਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ

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

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