nftables cgroup ਬਾਈਪਾਸ ਲਈ ਸਰੋਤ ਪਤੇ ਦੀ ਸੋਧ ਵੀ ਲੋੜੀਂਦੀ ਹੈ

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

ਤਿੰਨ ਫ਼ੈਸਲੇ, ਇੱਕ ਨਹੀਂ

ਵਰਗੀਕਰਨ ਦੱਸਦਾ ਹੈ ਕਿਸਨੂੰ ਛੋਟ ਹੈ। ਰੂਟਿੰਗ ਦੱਸਦੀ ਹੈ ਨਿਸ਼ਾਨਿਤ ਪੈਕਟ ਉਸ ਦੀ ਥਾਂ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ। ਸਰੋਤ ਚੋਣ ਦੱਸਦੀ ਹੈ ਦੂਰ ਵਾਲਾ ਸਿਰਾ ਕੀ ਵੇਖੇਗਾ ਅਤੇ ਜਵਾਬ ਕਿੱਥੇ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਕ੍ਰਮ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਪੈਕਟ ਬਣਦਿਆਂ ਵਰਗੀਕਰਨ ਹੁੰਦਾ ਹੈ, ਉਸ ਤੋਂ ਬਾਅਦ ਰੂਟਿੰਗ, ਅਤੇ ਬਾਹਰ ਨਿਕਲਣ ਵਾਲੇ ਬਿੰਦੂ 'ਤੇ ਅਨੁਵਾਦ ਹੁੰਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਦੱਸ ਨਹੀਂ ਸਕਦੇ ਕਿ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਪੜਾਅ ਵਿਗੜਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਡੀਬੱਗ ਨਹੀਂ ਕਰ ਰਹੇ, ਨਿਯਮ ਮੁੜ ਵਿਵਸਥਿਤ ਕਰਕੇ ਆਸ ਕਰ ਰਹੇ ਹੋ।

ਅਜਿਹਾ cgroup ਮਿਲਾਓ ਜੋ ਕੱਲ੍ਹ ਵੀ ਹੋਵੇਗਾ

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

nft list ruleset
systemctl status session.slice 2>/dev/null
cat /proc/self/cgroup

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

ਇਹ ਵੀ ਸਪੱਸ਼ਟ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀ ਵਿਧੀ ਵਰਤ ਰਹੇ ਹੋ। cgroup v1 ਦਾ net_cls ਵਰਗੀਕਰਨ ਅਤੇ cgroup v2 ਦਾ ਸਾਕਟ ਮਿਲਾਣ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ, ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਨਾਮ ਵਾਲਾ ਖੇਤਰ ਉਹਨਾਂ ਨੂੰ ਆਪਸ ਵਿੱਚ ਬਦਲਣਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦਾ।

ਦੂਜੀ ਖੋਜ route ਚੇਨ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ

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

table inet bypass {
  chain mark {
    type route hook output priority mangle; policy accept;
    socket cgroupv2 level 2 "app.slice" meta mark set 0x1 comment "app bypass"
  }
}
ip rule add fwmark 0x1 lookup 200
ip route add default via 203.0.113.1 dev wlan0 table 200

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

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

ਸਰੋਤ ਪਤਾ ਰੂਟ ਦੀ ਪੈੜ ਨਹੀਂ ਲੈਂਦਾ

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

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

ਤੰਗ ਸੋਧ ਉਹ ਸਰੋਤ ਅਨੁਵਾਦ ਨਿਯਮ ਹੈ ਜੋ ਉਸ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਿਸ਼ਾਨ ਅਤੇ ਉਸਦੇ ਅਸਲ ਆਉਟਪੁੱਟ ਇੰਟਰਫੇਸ ਤੱਕ ਸੀਮਿਤ ਹੈ, ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ NAT ਨਾਲ ਜੋੜਿਆ ਗਿਆ ਹੈ, ਉਸਨੂੰ ਬਦਲਦਾ ਨਹੀਂ:

table inet bypass {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    meta mark 0x1 oifname "wlan0" masquerade
  }
}

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

ਅਜੇ ਵੀ ਛੋਟ ਤੋਂ ਕੀ ਬਚਦਾ ਹੈ

ਨਾਮ ਹੱਲ ਕਿਸੇ ਹੋਰ cgroup ਵਿੱਚ ਵੱਖਰੀ resolver ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਆ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਸਾਕਟ ਦਾ ਵਰਗੀਕਰਨ ਉਸਦੀਆਂ ਖੋਜਾਂ ਦਾ ਨਹੀਂ ਹੁੰਦਾ। ਜੇ resolver ਦੀਆਂ ਬੇਨਤੀਆਂ ਟਨਲ ਵਿੱਚ ਰਹਿਣ ਅਤੇ ਕਨੈਕਸ਼ਨ ਬਾਹਰ ਜਾਵੇ, ਤਾਂ split-horizon ਜਵਾਬ ਮਾਰਗ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾ ਸਕਦੇ। ਉਹ ਅੰਤਰ DNS ਬੱਗ ਵਰਗੀਆਂ ਦਿਸਣ ਵਾਲੀਆਂ ਪਰ ਨਾ ਹੋਣ ਵਾਲੀਆਂ ਖਰਾਬੀਆਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।

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

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