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

ਨੀਤੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਪ੍ਰਵਾਹ ਲਿਖੋ

ਪ੍ਰਵਾਹਾਂ ਨੂੰ ਸਰੋਤ, ਮੰਜ਼ਿਲ, ਪ੍ਰੋਟੋਕਾਲ ਅਤੇ ਪੋਰਟ ਵਾਲੀਆਂ ਕਤਾਰਾਂ ਵਜੋਂ ਲਿਖੋ। ਬਾਹਰੀ ਮਾਰਗ ’ਤੇ ਸਰੋਤ ਕਲਾਇੰਟ ਦਾ ਜਨਤਕ ਪਤਾ ਹੈ ਅਤੇ ਮੰਜ਼ਿਲ ਗੇਟਵੇ ਦਾ ਸੁਣਨ ਪੋਰਟ ਹੈ; Shorewall ਇਸਨੂੰ ਇੰਟਰਨੈੱਟ ਤੋਂ ਫਾਇਰਵਾਲ ਵੱਲ ਟ੍ਰੈਫ਼ਿਕ ਮੰਨਦਾ ਹੈ। ਅੰਦਰੂਨੀ ਮਾਰਗ ’ਤੇ ਸਰੋਤ ਟਨਲ ਪਤਾ ਰੇਂਜ ਹੈ ਅਤੇ ਮੰਜ਼ਿਲ ਮਨਜ਼ੂਰ ਸੇਵਾ ਹੈ। ਇੱਕ ਹੀ ਪ੍ਰਬੰਧਕ ਦੋਵੇਂ ਸੰਭਾਲੇ ਤਾਂ ਵੀ ਦੋਵਾਂ ਕਤਾਰਾਂ ਦੇ ਮਾਲਕ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ।

FlowZone relationshipWhat to constrain
Encrypted OpenVPN transportInternet to the firewall hostThe listener's actual protocol and port
Decrypted request to a LAN serviceVPN clients to the LAN zoneOne approved server and service
Decrypted request to the gatewayVPN clients to the firewall hostOnly the local services required
Request to another VPN clientVPN clients to VPN clientsDenied unless deliberately required

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

ਟਨਲ ਜ਼ੋਨ ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਦਾਇਰਾ ਨਿਰਧਾਰਤ ਕਰੋ

ਰੋਡ-ਵਾਰੀਅਰ ਜ਼ੋਨ /etc/shorewall/zones ਵਿੱਚ ਘੋਸ਼ਿਤ ਹੁੰਦਾ ਹੈ, ਟਨਲ ਇੰਟਰਫ਼ੇਸ /etc/shorewall/interfaces ਵਿੱਚ ਜੁੜਦਾ ਹੈ, ਅਤੇ ਬਾਹਰੀ ਕਨੈਕਸ਼ਨ /etc/shorewall/tunnels ਵਿੱਚ ਵਰਣਿਤ ਹੁੰਦਾ ਹੈ। ਸਥਾਪਿਤ ਸੰਸਕਰਣ ਦੇ ਸਿੰਟੈਕਸ ਨਾਲ ਮੇਲ ਖਾਓ, ਕਿਉਂਕਿ ਕਾਲਮ ਕ੍ਰਮ ਅਤੇ ਵਿਕਲਪ ਨਾਮ ਮੁੱਖ ਸੰਸਕਰਣਾਂ ਵਿਚਕਾਰ ਬਦਲ ਗਏ ਹਨ। ਗਾਈਡ ਦਾ ਉਦਾਹਰਨ ਪੋਰਟ ਡੈਮਨ ਦੁਆਰਾ ਅਸਲ ਵਿੱਚ ਸੁਣੇ ਜਾਣ ਵਾਲੇ ਪੋਰਟ ਤੋਂ ਵੱਖਰੇ ਪੋਰਟ ਦੀ ਆਗਿਆ ਦੇਣ ਦਾ ਕਾਰਨ ਨਹੀਂ ਹੈ। ਸਿਰਫ਼ ਸੰਖਿਆਵਾਂ ਮਿਲਣ ਕਰਕੇ TCP ਅਤੇ UDP ਬਦਲਵੇਂ ਨਹੀਂ ਹਨ।

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

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

ਸਿਰਫ਼ ਉਸੇ ਮਾਰਗ ਦੀ ਆਗਿਆ ਦਿਓ ਜਿਸਨੂੰ ਤੁਸੀਂ ਵਰਗੀਕ੍ਰਿਤ ਕੀਤਾ

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

ਕਲਾਇੰਟ-ਤੋਂ-ਕਲਾਇੰਟ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਆਪਣਾ ਫ਼ੈਸਲਾ ਚਾਹੀਦਾ ਹੈ। OpenVPN ਦਾ client-to-client ਅਤੇ Shorewall ਦਾ routeback ਦੋਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ ਕਿ ਕਲਾਇੰਟ ਇੱਕ-ਦੂਜੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਸਿਰਫ਼ ਇੱਕ LAN ਐਪਲੀਕੇਸ਼ਨ ਚੱਲਣ ਲਈ ਕੋਈ ਵੀ ਸਮਰੱਥ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ। ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਅਲੱਗ ਰੱਖਣਾ ਕਿੱਥੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

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

ਪ੍ਰਮਾਣਿਤ ਕਰੋ, ਫਿਰ ਦੋਵੇਂ ਮਾਰਗ ਸਿੱਧ ਕਰੋ

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

shorewall check

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

shorewall show zones
ip route get 192.168.10.20

ਇੱਕੋ ਕਲਾਇੰਟ ਤੋਂ ਇੱਕ ਨਵੀਂ ਮਨਜ਼ੂਰ ਬੇਨਤੀ ਅਤੇ ਇੱਕ ਜਾਣਬੁੱਝ ਕੇ ਰੱਦ ਕੀਤੀ ਬੇਨਤੀ ਦੀ ਜਾਂਚ ਕਰੋ। ਸਫਲ OpenVPN ਹੈਂਡਸ਼ੇਕ ਸਿਰਫ਼ ਬਾਹਰੀ ਅਦਲਾ-ਬਦਲੀ ਸਿੱਧ ਕਰਦਾ ਹੈ; ਮਨਜ਼ੂਰ ਸੇਵਾ ਅਤੇ ਰੱਦ ਸਰੋਤ ਤੁਹਾਡੀ ਇੱਛਤ ਅੰਦਰੂਨੀ ਨੀਤੀ ਸਿੱਧ ਕਰਦੇ ਹਨ। ਫਿਰ ਕਲਾਇੰਟ ਮੁੜ ਜੋੜੋ ਅਤੇ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਅਤੇ ਪਤਾ ਸੈਸ਼ਨਾਂ ਵਿਚਕਾਰ ਬਦਲ ਸਕਦਾ ਹੈ। ਨਤੀਜਾ ਵੱਖਰਾ ਹੋਵੇ ਤਾਂ ਨਿਯਮ ਚੌੜਾ ਕਰਨ ਦੀ ਬਜਾਏ ਜ਼ੋਨ ਦਾ ਦਾਇਰਾ ਠੀਕ ਕਰੋ।

ਸੰਬੰਧਿਤ ਲੇਖ