ਹੱਬ 'ਤੇ WireGuard ਪੀਅਰ ਗਰੁੱਪ: ਸਰੋਤ ਦੀ ਮਾਲਕੀ ਅਤੇ ਨੀਤੀ

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

ਦੋ ਕੰਮ, ਵੱਖਰੇ ਰੱਖੇ

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

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

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

ਹਰ ਪੀਅਰ ਨੂੰ ਸਿਰਫ਼ ਉਸਦਾ ਆਪਣਾ ਪਤਾ ਦਿਓ

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

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

ਗਰੁੱਪ ਵੱਖ ਕਰਨ ਵਾਲੀ ਫਾਰਵਰਡ ਨੀਤੀ ਲਿਖੋ

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

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

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

ਕ੍ਰਮ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਨੀਤੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ

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

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

ਫਾਈਲਾਂ ਦੀ ਗਿਣਤੀ ਨਹੀਂ, ਮੈਟ੍ਰਿਕਸ ਜਾਂਚੋ

ਉਮੀਦ ਕੀਤੇ ਨਤੀਜਿਆਂ ਦਾ ਛੋਟਾ ਮੈਟ੍ਰਿਕਸ ਬਣਾਓ ਅਤੇ ਹਰ ਸੈੱਲ ਜਾਂਚੋ। ਗਰੁੱਪ A ਤੋਂ ਗਰੁੱਪ A ਤੱਕ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਗਰੁੱਪ B ਤੋਂ ਗਰੁੱਪ B ਤੱਕ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ A ਤੋਂ B ਤੱਕ ਨਹੀਂ, ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਅਤੇ ਜੇ ਤੁਸੀਂ ਸਮਰਥਨ ਕਰਦੇ ਹੋ ਤਾਂ ਦੋਵੇਂ ਪਤਾ-ਪਰਿਵਾਰਾਂ ਲਈ।

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

ਪਹਿਲੇ ਦੋ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਸੰਰਚਿਤ ਹੈ। ਗਲਤ ਗਰੁੱਪ ਦੇ ਮੈਂਬਰ ਤੋਂ ping ਦੱਸਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ। conntrack ਸੂਚੀ ਦੱਸਦੀ ਹੈ ਕਿ ਪੁਰਾਣਾ ਵਹਾਅ ਅਜੇ ਵੀ ਸਵੀਕਾਰ ਹੋ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਅਲੱਗਾਅ ਦਾ ਬਦਲਾਅ ਚੁੱਪਚਾਪ ਲਾਗੂ ਨਾ ਹੋਣ ਦਾ ਕਾਰਨ ਇਹੀ ਹੈ।

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