VPN ਨਾਲ ਜੁੜੇ ਦੋ ਦਫ਼ਤਰਾਂ ਵਿਚਕਾਰ ਪਹੁੰਚ ਨੂੰ ਕਿਵੇਂ ਸੀਮਤ ਕਰੀਏ

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

ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਕੰਮ ਕਰੋ, ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਨੀਤੀ ਕਦਮ ਪਾਸ ਹੋਣ ਤੱਕ ਟਨਲ ਦਾ ਰਾਹ ਨਾ ਚੌੜਾ ਕਰੋ।

ਗੇਟਵੇ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਮੈਟ੍ਰਿਕਸ ਲਿਖੋ

ਇੱਕ ਲਾਭਦਾਇਕ ਕਤਾਰ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦੱਸਦੀ ਹੈ: ਸਰੋਤ ਸਮੂਹ, ਮੰਜ਼ਿਲ ਹੋਸਟ ਜਾਂ ਸੇਵਾ ਨੈੱਟਵਰਕ, ਅਤੇ ਉਹ ਪ੍ਰੋਟੋਕੋਲ ਤੇ ਪੋਰਟ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਵਰਤਦੀ ਹੈ। ਸ਼ਾਖਾ ਅਤੇ ਡੇਟਾ ਸੈਂਟਰ ਐਂਟਰੀਆਂ ਨਹੀਂ ਹਨ। ਨਿੱਜੀ DNS ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਸੇਵਾਵਾਂ ਆਪਣੀਆਂ ਕਤਾਰਾਂ ਤਾਂ ਹੀ ਪ੍ਰਾਪਤ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਉਨ੍ਹਾਂ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੀ।

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

ਜਿੱਥੇ ਪੈਕੇਟ ਡੀਕ੍ਰਿਪਟ ਹੁੰਦੇ ਹਨ ਉੱਥੇ ਹੀ ਲਾਗੂ ਕਰੋ

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

ਟ੍ਰੈਫਿਕ ਚੋਣਕਰਤਾ ਰਾਊਟਿੰਗ ਦਾ ਫੈਸਲਾ ਹਨ, ਅਧਿਕਾਰ ਦਾ ਫੈਸਲਾ ਨਹੀਂ। ਦੋਵੇਂ ਸਬਨੈੱਟ ਢਕਣ ਵਾਲਾ ਚੌੜਾ ਚੋਣਕਰਤਾ ਰਾਊਟਿੰਗ ਲਈ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਫਾਇਰਵਾਲ ਅਜੇ ਵੀ ਇੱਕ ਹੋਸਟ ਵੱਲ ਸਿਰਫ਼ TCP 443 ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਚੋਣਕਰਤਾ ਟਨਲ ਲਈ ਗੱਲਬਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਇਸ ਵਿੱਚ ਕੀ ਦਾਖਲ ਹੋ ਸਕਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਕੋਈ ਯੰਤਰ ਕੀ ਵਰਤ ਸਕਦਾ ਹੈ। ਚੋਣਕਰਤਾ ਚੌੜਾ ਹੈ ਇਸ ਲਈ ਕਦੇ ਵੀ ਫਾਇਰਵਾਲ ਨਿਯਮ ਨਾ ਚੌੜਾ ਕਰੋ।

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT ਅਤੇ ਓਵਰਲੈਪਿੰਗ ਸਬਨੈੱਟ ਨਿਯਮ ਬਦਲਦੇ ਹਨ

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

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

ਇਨਕਾਰ ਸਾਬਤ ਕਰੋ, ਸਿਰਫ਼ ਸਫਲਤਾ ਨਹੀਂ

ਸਿਰਫ਼ ਇਜਾਜ਼ਤ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਜਾਂਚ ਬਹੁਤ ਘੱਟ ਸਾਬਤ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਉੱਪਰ ਕਿਤੇ ਇੱਕ ਢਿੱਲਾ ਨਿਯਮ ਉਹੀ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ।

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

ਸੂਚੀ ਨੂੰ ਜੀਵਤ ਰੱਖੋ

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

ਟਨਲ ਪਿੱਛੇ ਵੀ ਹੋਸਟ-ਪੱਧਰੀ ਪਾਬੰਦੀਆਂ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਸਰਵਰ ਦਾ ਆਪਣਾ ਫਾਇਰਵਾਲ ਸ਼ਾਖਾ ਦੀ ਰੇਂਜ ਨੂੰ ਸਿਰਫ਼ ਉਸ ਸੇਵਾ ਲਈ ਸਵੀਕਾਰ ਕਰੇ ਜੋ ਇਹ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਮਿਲਦੇ ਦੋ ਪਰਤ ਪੂਰੀ ਤਰ੍ਹਾਂ ਭਰੋਸਾ ਕੀਤੇ ਇੱਕ ਪਰਤ ਨਾਲੋਂ ਆਡਿਟ ਕਰਨਾ ਸੌਖਾ ਹੈ।