VPN ਪੋਰਟ ਬਲਾਕ ਕਰਨ ਨਾਲ ਗੈਰ-ਅਧਿਕ੍ਰਿਤ ਟਨਲ ਕਿਉਂ ਨਹੀਂ ਰੁਕਦੇ

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

ਪੋਰਟ ਸੂਚੀ ਨੀਤੀ ਕਿਉਂ ਨਹੀਂ

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

ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ, ਇੱਕ ਪੋਰਟ ਦਾ ਸਫਲ ਬਲਾਕ ਪੂਰੀ ਸਮੱਸਿਆ ਹੱਲ ਹੋਣ ਦਾ ਸਬੂਤ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜੋ ਫਿਰ ਉਹ ਨਿਯੰਤਰਣ ਦੇਰ ਨਾਲ ਲਿਆਉਂਦਾ ਹੈ ਜੋ ਮਾਇਨੇ ਰੱਖਦੇ ਸਨ।

ਪ੍ਰੋਟੋਕੋਲ ਨੰਬਰ ਅਤੇ ਪੋਰਟ ਵੱਖਰੇ ਨਾਮ-ਥਾਵਾਂ ਹਨ

GRE ਨੂੰ IP ਪ੍ਰੋਟੋਕੋਲ ਨੰਬਰ 47 ਦਿੱਤਾ ਗਿਆ ਹੈ। ਇਹ TCP ਪੋਰਟ 47 ਨਹੀਂ ਹੈ ਅਤੇ UDP ਪੋਰਟ 47 ਨਹੀਂ ਹੈ, ਅਤੇ ਪੋਰਟ ਲਈ ਲਿਖਿਆ ਫਿਲਟਰ ਇਸ ਨੂੰ ਛੂੰਹਦਾ ਨਹੀਂ। ESP ਅਤੇ AH ਉਸੇ ਗੁਣ ਨਾਲ ਪ੍ਰੋਟੋਕੋਲ ਨੰਬਰ 50 ਅਤੇ 51 'ਤੇ ਹਨ। ਇਨਕੈਪਸੁਲੇਟਿਡ ਟ੍ਰੈਫਿਕ ਮਨਜ਼ੂਰ ਕਨੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ਵੀ ਲੁਕ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਸ਼੍ਰੇਣੀ ਜਾਂ ਦਸਤਖ਼ਤ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਕੱਲਾ ਕਦੇ ਉਦੇਸ਼ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰਦਾ। ਭਰੋਸਾ ਅਤੇ ਕਵਰੇਜ ਕਿਸੇ ਖਾਸ ਉਤਪਾਦ ਅਤੇ ਰੀਲੀਜ਼ ਦੇ ਹੁੰਦੇ ਹਨ, ਧਾਰਨਾ ਦੇ ਨਹੀਂ।

nft list ruleset | grep -nE 'gre|esp|ah|47|50|51'
cat /proc/net/protocols | head -20
ss -tn state established '( dport = :443 )'

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

ਡਿਵਾਈਸ ਕੋਲ ਜੋ ਅਧਿਕਾਰ ਹੈ ਉਸ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰੋ

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

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

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

conntrack -L | awk '{print $1, $4, $5}' | sort | uniq -c | sort -rn | head
ip -br addr show
ip route show default

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

ਅਪਵਾਦ ਸਪਸ਼ਟ ਕਰੋ

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

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

ਬਿਨਾਂ ਸਮੀਖਿਆ ਵਾਲਾ ਅਪਵਾਦ ਟਿਕਟ ਨੰਬਰ ਵਾਲਾ ਛੇਕ ਹੈ। ਨਾਮ, ਕਾਰਨ ਅਤੇ ਸਮੀਖਿਆ ਤਾਰੀਖ਼ ਵਾਲਾ ਅਪਵਾਦ ਇੱਕ ਫੈਸਲਾ ਹੈ।

ਨਾਅਰੇ ਦੀ ਥਾਂ ਲਿਖਤੀ ਯੋਜਨਾ ਨਾਲ ਸਵੀਕਾਰ ਕਰੋ

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

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

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