ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN: ਕਿਹੜੀ ਦਿਸ਼ਾ ਨੂੰ ਸਚਮੁੱਚ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ?
ਬੇਨਤੀਆਂ ਅਤੇ ਜਵਾਬਾਂ ਦੋਵਾਂ ਨੂੰ ਇਜਾਜ਼ਤ ਚਾਹੀਦੀ ਹੈ, ਪਰ ਸਟੇਟਫੁਲ ਫਾਇਰਵਾਲ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਕਨੈਕਸ਼ਨ ਦੀ ਵਾਪਸੀ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਉਸਨੇ ਸਵੀਕਾਰ ਕੀਤਾ। ਪਤਾ ਲਗਾਓ ਕਿ ਕਿਹੜੇ ਪਾਸੇ ਨਿਯਮ ਨਹੀਂ ਹੈ।
ਦੋਵੇਂ ਸਿਰੇ ਸਥਾਪਿਤ ਟਨਲ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ, ਦੂਰ ਦੀ ਸ਼ਾਖਾ ਗੇਟਵੇ ਤੋਂ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਪਾਸੇ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਫਿਰ ਵੀ ਸਮਾਂ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ। ਆਮ ਸਲਾਹ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜੋੜਨ ਦੀ ਹੈ। ਕਦੇ ਇਹ ਸਹੀ ਹੁੰਦਾ ਹੈ, ਕਦੇ ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਨਿਯਮ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਦੇ ਦੂਜਾ ਨਿਯਮ ਹੀ ਸਟੇਟ ਤੋੜਦਾ ਹੈ। ਕਿਹੜਾ ਮਾਮਲਾ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਫਾਇਰਵਾਲ ਪੈਕੇਟ ਨੂੰ ਕਿੱਥੇ ਦੇਖਦਾ ਹੈ।
ਸਟੇਟਫੁਲ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਗਿਣਤੀ ਬਦਲਦਾ ਹੈ
ਸਟੇਟਫੁਲ ਫਾਇਰਵਾਲ ਬੇਨਤੀ ਦਰਜ ਕਰਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਨਿਯਮ ਤੋਂ ਬਿਨਾਂ ਜਵਾਬ ਲੰਘਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਨਿਯਮ ਚਾਹੀਦਾ ਡਿਜ਼ਾਈਨ ਆਮ ਹੈ। ਸਟੇਟਲੈਸ ਐਕਸੈਸ ਸੂਚੀ ਵਿੱਚ ਅਜਿਹੀ ਯਾਦ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਜਵਾਬ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਇਜਾਜ਼ਤ ਦੇਣੀ ਪੈਂਦੀ ਹੈ। ਦੋਵੇਂ ਆਪਣੇ-ਆਪਣੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਸਹੀ ਹਨ, ਇਸ ਲਈ ਸਲਾਹਾਂ ਆਪਸ ਵਿੱਚ ਟਕਰਾਉਂਦੀਆਂ ਹਨ।
ਆਪਣੇ ਸਾਹਮਣੇ ਮੌਜੂਦ ਪਲੇਟਫਾਰਮ ਦਾ ਫਾਰਵਰਡਿੰਗ ਦਸਤਾਵੇਜ਼ ਪੜ੍ਹੋ, ਅਤੇ ਜਾਂਚੋ ਕਿ ਤੁਸੀਂ ਸੰਪਾਦਿਤ ਕਰ ਰਹੇ ਨੀਤੀ ਪੈਕੇਟ ਦੇਖਣ ਵਾਲੀ ਥਾਂ 'ਤੇ ਸਟੇਟਫੁਲ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਥਾਪਿਤ ਟ੍ਰੈਫਿਕ ਲਈ ਸਪਸ਼ਟ ਵਰਜਨ, ਜਾਂ ਅਜਿਹਾ ਨਿਯਮ ਕ੍ਰਮ ਜੋ ਸਟੇਟ ਟੇਬਲ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ, ਕੰਮ ਕਰਨ ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬੁਝਾਰਤ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਨਿਯਮਾਂ ਦੀ ਗਿਣਤੀ ਲਾਗੂ ਕਰਨ ਦਾ ਵੇਰਵਾ ਹੈ, ਜਦੋਂ ਕਿ ਲੋੜ ਇਹ ਹੈ ਕਿ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਗੱਲਬਾਤ ਦੀਆਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਪੂਰੀਆਂ ਹੋ ਸਕਣ।
ਫਾਇਰਵਾਲ ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਪੈਕੇਟ ਕਿੱਥੇ ਦੇਖਦਾ ਹੈ
ਨੀਤੀ-ਆਧਾਰਿਤ ਟਨਲ ਵਿੱਚ ਫਾਇਰਵਾਲ ਡੀਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਪੈਕੇਟ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਪੈਕੇਟ ਦਾ, ਵੱਖ-ਵੱਖ ਇੰਟਰਫੇਸਾਂ 'ਤੇ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦਾ ਹੈ। ਗਲਤ ਇੰਟਰਫੇਸ ਲਈ ਲਿਖਿਆ ਨਿਯਮ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ, ਸਹੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਦੇ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਵਾਲੇ ਤੈਨਾਤੀ ਤੋਂ ਨਕਲ ਕੀਤਾ ਨਿਯਮ-ਸਮੂਹ ਇੱਕੋ ਜਿਹੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ।
ਰੂਟ-ਆਧਾਰਿਤ IPsec ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਆਧੁਨਿਕ ਲਾਗੂਕਰਨ ਟਨਲ ਇੰਟਰਫੇਸ ਪੇਸ਼ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਡੀਕ੍ਰਿਪਟ ਕੀਤਾ ਪੈਕੇਟ ਉੱਥੇ ਪਹੁੰਚਦਾ ਹੈ ਅਤੇ ਆਮ ਇੰਟਰਫੇਸ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਦੂਜੇ ਲਈ ਲਿਖੀ ਗਾਈਡ ਤੋਂ ਨਿਯਮ-ਸਮੂਹ ਨਕਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੈਨਾਤੀ ਕਿਹੜਾ ਮਾਡਲ ਵਰਤਦੀ ਹੈ। ਟਨਲ ਇੰਟਰਫੇਸ ਉਹ ਥਾਂ ਵੀ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਜਦੋਂ ਜਾਣਨਾ ਹੋਵੇ ਕਿ ਪੈਕੇਟ ਬਿਲਕੁਲ ਡੀਕ੍ਰਿਪਟ ਹੋਇਆ ਸੀ ਜਾਂ ਨਹੀਂ।
ਅਸਮਮਿਤ ਰੂਟਿੰਗ ਧਾਰਨਾ ਤੋੜਦੀ ਹੈ
ਸਟੇਟਫੁਲ ਫਾਇਰਵਾਲ ਮੰਨਦਾ ਹੈ ਕਿ ਉਹ ਗੱਲਬਾਤ ਦੇ ਦੋਵੇਂ ਅੱਧ ਦੇਖਦਾ ਹੈ। ਜੇ ਜਵਾਬ ਕਿਸੇ ਹੋਰ ਗੇਟਵੇ ਰਾਹੀਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਉਸ ਡਿਵਾਈਸ ਕੋਲ ਬੇਨਤੀ ਲਈ ਕੋਈ ਸਟੇਟ ਨਹੀਂ ਹੁੰਦੀ ਅਤੇ ਉਹ ਆਪਣੀ ਨੀਤੀ ਅਨੁਸਾਰ ਉਸਨੂੰ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਲੱਛਣ ਇੱਕ-ਦਿਸ਼ਾਵੀ ਫੇਲ ਹੈ ਜਿਸਨੂੰ ਭੇਜਣ ਵਾਲੇ ਪਾਸੇ ਦਾ ਕੋਈ ਨਿਯਮ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਜਵਾਬ ਦਾ ਰਾਹ ਟਰੇਸ ਕਰੋ ਕੁਝ ਵੀ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।
ਦੋਵੇਂ ਪਾਸਿਆਂ 'ਤੇ ਵਿਆਪਕ ਇਜਾਜ਼ਤ ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਦਾ ਰੂਟ ਜਾਂਚੋ। ਹਰ ਇੰਟਰਫੇਸ 'ਤੇ ਸਭ ਕੁਝ ਸਹਿਣਾ ਰੂਟਿੰਗ ਗਲਤੀ ਨੂੰ ਲੁਕਾਉਂਦਾ ਹੈ ਅਤੇ ਉਸੇ ਸਮੇਂ ਪਹੁੰਚ ਵਧਾਉਂਦਾ ਹੈ, ਜੋ ਉਪਲਬਧ ਸਭ ਤੋਂ ਮਾੜਾ ਸੁਮੇਲ ਹੈ।
ਅਸਲ ਸਰੋਤ ਪਤਿਆਂ ਨਾਲ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਜਾਂਚੋ
ਉਸ ਪਤੇ ਨਾਲ ਟੈਸਟ ਕਰੋ ਜੋ ਦੂਰ ਦਾ ਪਾਸਾ ਸਚਮੁੱਚ ਦੇਖਦਾ ਹੈ, ਕਿਉਂਕਿ ਅਨੁਵਾਦ ਸਰੋਤ ਨਿਯਮ ਨੂੰ ਕਿਸੇ ਨਾਲ ਵੀ ਮੇਲ ਨਾ ਖਾਣ ਦੇ ਸਕਦਾ ਹੈ। ਇੱਕੋ ਸਮੇਂ ਦੋਵੇਂ ਗੇਟਵੇ 'ਤੇ ਕੈਪਚਰ ਚਲਾਓ।
tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15
ਦੂਰ ਦੇ ਗੇਟਵੇ 'ਤੇ ਅਣਕਿਆਸੇ ਸਰੋਤ ਪਤੇ ਨਾਲ ਦਿਖਣ ਵਾਲੀ ਬੇਨਤੀ ਅਜਿਹੇ ਨਿਯਮ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ ਜੋ ਕਦੇ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਅਤੇ ਗਲਤ ਇੰਟਰਫੇਸ 'ਤੇ ਆਉਣ ਵਾਲਾ ਜਵਾਬ ਸਟੇਟ ਦੀ ਅਸੰਗਤੀ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। ਫਿਰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਦਾਇਰੇ ਦੇ ਅੰਦਰ ਇੱਕ ਮੰਜ਼ਿਲ ਅਤੇ ਬਾਹਰ ਇੱਕ ਦੀ ਜਾਂਚ ਕਰੋ, ਤਾਂ ਜੋ ਸੀਮਾ ਮੰਨੀ ਨਾ ਜਾਵੇ ਸਗੋਂ ਦਿਖਾਈ ਜਾਵੇ।
ਅਨੁਵਾਦ ਤੋਂ ਬਾਅਦ ਦਾ ਸਰੋਤ ਪਤਾ, ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਪੈਕੇਟ ਵੱਲੋਂ ਵਰਤਿਆ ਇੰਟਰਫੇਸ ਅਤੇ ਮੇਲ ਖਾਣ ਵਾਲਾ ਨਿਯਮ ਦਰਜ ਕਰੋ। ਉਹ ਤਿੰਨ ਤੱਥ ਪੂਰੀ ਜਾਂਚ ਦੁਹਰਾਏ ਬਿਨਾਂ ਅਗਲੀ ਟਿਕਟ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ।