ਡੀਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਬਾਅਦ: ਤੁਹਾਡਾ VPN ਟ੍ਰੈਫਿਕ ਪਹਿਲਾਂ ਕਿਹੜੀ ਨੀਤੀ ਵੇਖਦੀ ਹੈ

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

ਪੋਰਟ ਨਾਲ ਨਹੀਂ, ਨੀਤੀ-ਹੁੱਕ ਨਾਲ ਫੈਸਲਾ ਕਰੋ

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

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

ਦੋ ਰਸਤੇ, ਦੋ ਵੱਖਰੀਆਂ ਲਾਗੂਕਰਨ ਕਹਾਣੀਆਂ

ਦੋ ਆਕਾਰ ਆਮ ਹਨ ਅਤੇ ਹਰ ਇੱਕ ਵੱਖਰੀ ਲੋੜ ਲਈ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ।

endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnet

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

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

ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20

ਟੋਪੋਲੋਜੀ ਨੂੰ ਅਲੱਗਾਉਣ ਤੋਂ ਵੱਖ ਰੱਖੋ

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

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

ਹਰ ਥਾਂ ਲਈ ਨਾਕਾਮੀ ਅਤੇ ਪ੍ਰਬੰਧਨ ਦੀ ਜਾਂਚ ਕਰੋ

ਹਰ ਥਾਂ ਦਾ ਨਾਕਾਮੀ ਢੰਗ ਹੈ ਅਤੇ ਲਾਹੇਵੰਦ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੋਈ ਹਿੱਸਾ ਰੁਕਣ ਤੇ ਕੀ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਇੱਕ ਮਰੇ ਯੰਤਰ ਉੱਤੇ ਕਈ ਤਾਰਕਿਕ ਇੰਟਰਫੇਸ ਆਜ਼ਾਦ ਬਹਾਲੀ ਨਹੀਂ ਦਿੰਦੇ, ਅਤੇ ਇੱਕੋ ਬਿਜਲੀ ਜਾਂ ਇੱਕੋ ਪ੍ਰਸ਼ਾਸਕ ਸਾਂਝਾ ਕਰਨ ਵਾਲਾ ਹੇਠਲਾ ਫਾਇਰਵਾਲ ਦੂਜੀ ਸੀਮਾ ਨਹੀਂ ਹੈ। ਪੁੱਛੋ ਕਿ ਪ੍ਰਬੰਧਨ ਰਾਹ ਕਿੱਥੋਂ ਲੰਘਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੇਵਲ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਣ ਵਾਲਾ ਕੰਸੋਲ ਕੋਈ ਬਹਾਲੀ ਰਾਹ ਨਹੀਂ; ssh [email protected] true ਟਨਲ ਤੋਂ ਬਾਹਰੋਂ ਚਲਾਉਣਾ ਇਹ ਸਾਬਤ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਸਸਤਾ ਤਰੀਕਾ ਹੈ ਕਿ ਕੰਸੋਲ ਇਸ ਤੇ ਨਿਰਭਰ ਨਹੀਂ। ਇੱਕ ਪਲੇਟਫਾਰਮ ਦੇ ਸਮੂਹ ਨੀਤੀ ਦਸਤਾਵੇਜ਼ ਆਪਣਾ ਫਿਲਟਰ ਡੀਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਬਾਅਦ ਅਤੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਟ੍ਰੈਫਿਕ ਉੱਤੇ ਰੱਖਦੇ ਹਨ, ਜੋ ਕਿਸੇ ਵੀ ਉਤਪਾਦ ਵਿੱਚ ਲੱਭਣ ਵਾਲਾ ਉਹੀ ਨਾਂ ਵਾਲਾ ਹੁੱਕ ਹੈ।

ਹਰ ਉਮੀਦਵਾਰ ਦੀ ਨਾਕਾਮੀ ਕਹਾਣੀ ਲਾਗੂਕਰਨ ਕਹਾਣੀ ਦੇ ਕੋਲ ਲਿਖੋ। ਜਾਂਚ ਵਿੱਚ ਜਿੱਤਣ ਅਤੇ ਬਹਾਲੀ ਵਿੱਚ ਹਾਰਨ ਵਾਲੀ ਥਾਂ ਇੱਕ ਵਟਾਂਦਰਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਘਟਨਾ ਵੇਲੇ ਲੱਭਣ ਦੀ ਥਾਂ ਇੰਝ ਹੀ ਦਰਜ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਮਨਜ਼ੂਰ ਅਤੇ ਰੱਦ ਕੀਤੇ ਫਲੋ ਨਾਲ ਸਵੀਕਾਰ ਕਰੋ

ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਟੈਸਟ ਯੋਜਨਾ ਨਾਲ ਅਸਲ VPN ਸਰੋਤ ਤੋਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਜਾਂਚੋ: ਚੱਲਣਾ ਚਾਹੀਦਾ ਐਪਲੀਕੇਸ਼ਨ, ਨਾ ਚੱਲਣਾ ਚਾਹੀਦਾ ਸਰੋਤ ਅਤੇ ਜਵਾਬ ਦੀ ਵਾਪਸੀ ਦੀ ਦਿਸ਼ਾ। ਰੱਦ ਕਰਨਾ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਹੈ ਕਿ ਨੀਤੀ ਸਰਗਰਮ ਹੈ, ਜਦੋਂ ਕਿ ਮਨਜ਼ੂਰ ਫਲੋ ਕੇਵਲ ਰਸਤੇ ਦੇ ਹੋਣ ਦੀ ਗੱਲ ਕਹਿੰਦਾ ਹੈ।

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