tun0 ਨਹੀਂ ਹੈ? nftables ਵਿੱਚ ਡੀਕ੍ਰਿਪਟ ਕੀਤਾ IPsec meta ipsec ਨਾਲ ਮਿਲਾਓ

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

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

ਦੋ ਪੈਕੇਟ, ਇੱਕ ਇੰਟਰਫ਼ੇਸ

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

ਉਸਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ ਪੈਕੇਟ ਨਾਲ ਜੁੜਿਆ ਆਉਣ ਵਾਲੇ ਸੁਰੱਖਿਆ ਮਾਰਗ ਦਾ ਸੰਦਰਭ। nftables ਇਸਨੂੰ meta ipsec exists ਵਜੋਂ ਦਿਖਾਉਂਦਾ ਹੈ, ਜੋ ਸੱਚ ਹੈ ਜਦੋਂ ਪੈਕੇਟ IPsec ਸੁਰੱਖਿਆ ਮਾਰਗ ਰਾਹੀਂ ਆਇਆ ਹੋਵੇ। ਇਸਨੂੰ ਕਲਾਇੰਟ ਪੂਲ, ਮੰਜ਼ਿਲ ਅਤੇ ਸੇਵਾ ਨਾਲ ਜੋੜੋ, ਨਿਯਮ ਸੁਰੱਖਿਅਤ ਹੋਣ ਲਈ ਕਾਫ਼ੀ ਖਾਸ ਹੋ ਜਾਂਦਾ ਹੈ।

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

ਅੱਗੇ ਭੇਜਣ ਦਾ ਨਿਯਮ ਲਿਖੋ

10.90.0.0/24 ਵਿੱਚ ਕਲਾਇੰਟ ਵਾਲੀ ਪ੍ਰਮਾਣਿਤ IPv4 ਦੂਰਸਥ ਪਹੁੰਚ ਸੇਵਾ ਅਤੇ 203.0.113.40 'ਤੇ ਇੱਕ ਮਨਜ਼ੂਰ ਮੰਜ਼ਿਲ ਹੈ ਅਜਿਹਾ ਮੰਨੋ। ਉਸ ਪ੍ਰਵਾਹ ਲਈ ਨਿਯਮ ਦਾ ਟੁਕੜਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ।

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

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

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

ਆਉਣ ਵਾਲਾ ਸੰਦਰਭ ਜਾਣ ਵਾਲਾ ਸੰਦਰਭ ਨਹੀਂ ਹੈ

ਉਹੀ ਸਮੀਕਰਨ ਪਰਿਵਾਰ ਦੂਜੀ ਦਿਸ਼ਾ ਨੂੰ rt ipsec ਨਾਲ ਢਕਦਾ ਹੈ, ਜੋ ਉਸ ਜਾਣ ਵਾਲੀ ਸੁਰੱਖਿਆ ਸੰਘ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਪੈਕੇਟ ਵਰਤੇਗਾ। ਇਹ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਇਹ ਪੈਕੇਟ ਕਿੱਥੋਂ ਆਇਆ ਨਹੀਂ, ਸਗੋਂ ਅਗਲੇ ਪੜਾਅ ਵਿੱਚ ਇਹ ਸੁਰੱਖਿਅਤ ਰਹੇਗਾ ਜਾਂ ਨਹੀਂ।

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

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

NAT ਫਾਇਰਵਾਲ ਫ਼ੈਸਲਾ ਨਹੀਂ ਹੈ

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

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

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

ਸਹੀ ਅੰਦਰੂਨੀ ਸੇਵਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

nftables ਸੰਦਰਭ meta ipsec, rt ipsec ਅਤੇ ਦਿਸ਼ਾ-ਖਾਸ ਸਮੀਕਰਨਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਸਥਾਪਿਤ ਸੰਸਕਰਣ ਨਾਲ ਵਾਕ-ਰਚਨਾ ਜਾਂਚਣ ਦੀ ਥਾਂ ਉਹੀ ਹੈ। ਅਤੇ ਦਾਇਰਾ ਸਪਸ਼ਟ ਰੱਖੋ: ਇਹ IPv4 ਉਦਾਹਰਨ ਹੈ, ਇਹ IPv6 ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਅਤੇ ਇਹ ਮਨਮਾਨੀ ਜਨਤਕ ਪੋਰਟ ਭੇਜਣ ਨੂੰ VPN ਸੇਵਾ ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਬਣਾਉਂਦਾ।