ਦੋ ਕਲਾਇੰਟ ਸਮੂਹ, ਇੱਕ ਸਰਵਰ: ਨੀਤੀ ਕਿੱਥੇ ਲਾਗੂ ਕਰੀਏ
ਸਬਨੈੱਟ ਸਮੂਹਾਂ ਨੂੰ ਲੇਬਲ ਕਰਦੇ ਹਨ; ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰਦੇ। ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜਾ ਫਾਰਵਰਡਿੰਗ ਮਾਰਗ ਨਿਯਮ ਦਾ ਮਾਲਕ ਹੈ, ਫਿਰ ਉਹ ਮੈਟ੍ਰਿਕਸ ਲਿਖੋ ਜੋ ਲਾਗੂਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਹੈ।
ਦੋ ਕਲਾਇੰਟ ਸਮੂਹਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਸਬਨੈੱਟਾਂ ਉੱਤੇ ਰੱਖਣਾ ਵੱਖਰੇਵੇਂ ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਇਹ ਨਹੀਂ ਹੈ। ਪਤੇ ਦੱਸਦੇ ਹਨ ਕਿ ਪੈਕਟ ਦਿਖਣ ਵਿੱਚ ਕਿੱਥੋਂ ਆ ਰਿਹਾ ਹੈ, ਜਦੋਂ ਕਿ ਇਜਾਜ਼ਤ ਉਹ ਫੈਸਲਾ ਹੈ ਜੋ ਇਸਨੂੰ ਫਾਰਵਰਡ ਕਰਨ ਵਾਲਾ ਲੈਂਦਾ ਹੈ। ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਮਾਸਕ ਨਹੀਂ, ਸੰਰਚਨਾ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਸਾਥੀਆਂ ਦਾ ਟਰੈਫਿਕ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ।
ਸਬਨੈੱਟ ਇੱਕ ਲੇਬਲ ਹੈ, ਨਿਯਮ ਨਹੀਂ
ਹਰ ਸਮੂਹ ਲਈ ਇੱਕ ਪੂਲ ਦੇਣਾ ਤੁਹਾਨੂੰ ਪੜ੍ਹਨਯੋਗ ਪਤੇ ਦਿੰਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਵਾਧੂ ਰੂਟ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟ ਨੇ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕੀਤੀ ਹੈ, ਅਤੇ ਪਹੁੰਚ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ। ਬੋਲਣ ਦੀ ਇਜਾਜ਼ਤ ਫਾਰਵਰਡਿੰਗ ਫੈਸਲੇ ਵਿੱਚ ਹੈ, ਜੋ ਸਰਵਰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਹੈ ਉਸ ਅਨੁਸਾਰ ਡੀਮਨ ਜਾਂ ਕਰਨਲ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ।
ਪਤੇ ਦੀ ਮਾਲਕੀ ਹੀ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਸਮੂਹ ਚੋਣਕਾਰ ਵਜੋਂ ਵਰਤੋਂਯੋਗ ਬਣਾਉਂਦੀ ਹੈ। ਹਰ ਪ੍ਰਮਾਣਿਤ ਪਛਾਣ ਨੂੰ ਅਨੁਮਾਨਿਤ ਪਤੇ ਜਾਂ ਰੇਂਜ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਈ ਡਿਵਾਈਸਾਂ ਇੱਕ ਹੀ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਅਤੇ ਇੱਕ ਹੀ ਅਲਾਟਮੈਂਟ ਸਾਂਝੀ ਕਰਨ ਨਾਲ ਉਹ ਮੇਲ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਸਰੋਤ ਪ੍ਰੀਫਿਕਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣ ਅਤੇ ਸਮਕਾਲੀਤਾ ਹੱਲ ਕਰੋ, ਕਿਉਂਕਿ ਕਿਹੜੀ ਮਸ਼ੀਨ ਕਾਲ ਕਰ ਰਹੀ ਹੈ ਇਸਦਾ ਅਨੁਮਾਨ ਲਾਉਣ ਵਾਲੀ ਨੀਤੀ ਸਭ ਤੋਂ ਮਾੜੇ ਪਲ ਵਿੱਚ ਗਲਤ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ।
ਉਹ ਮਾਰਗ ਚੁਣੋ ਜੋ ਸਾਥੀਆਂ ਦਾ ਟਰੈਫਿਕ ਲੈ ਜਾਂਦਾ ਹੈ
ਜਦੋਂ ਡੀਮਨ ਆਪਣੀ ਪ੍ਰਕਿਰਿਆ ਅੰਦਰ ਸਾਥੀਆਂ ਦੇ ਪੈਕਟ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ, ਉਹ ਪੈਕਟ ਕਦੇ ਵੀ ਹੋਸਟ ਦੇ ਫਾਰਵਰਡਿੰਗ ਹੁੱਕ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਇਸ ਲਈ ਕਰਨਲ ਦਾ ਨਿਯਮ ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕਦਾ। ਉਹ ਅੰਦਰੂਨੀ ਫਾਰਵਰਡਿੰਗ ਬੰਦ ਕਰੋ, ਕਰਨਲ ਫਾਰਵਰਡਿੰਗ ਬਿੰਦੂ ਬਣ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ ਆਮ ਫਾਰਵਰਡ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।
# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chainਆਫਲੋਡ ਕੀਤੇ ਡੇਟਾ ਚੈਨਲ ਅਤੇ ਉਤਪਾਦ-ਪ੍ਰਬੰਧਿਤ ਸਰਵਰ ਆਪਣੇ ਪ੍ਰਵਰਤਨ ਮਾਡਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਭਾਈਚਾਰੇ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਮੰਨਣ ਦੀ ਬਜਾਏ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਚਲਾ ਰਹੇ ਹੋ। ਬਚਣਯੋਗ ਅਸਫਲਤਾ ਉਹ ਨਿਯਮ ਹੈ ਜੋ ਸਮੀਖਿਆ ਵਿੱਚ ਸਹੀ ਦਿਖਦਾ ਹੈ ਅਤੇ ਰਨਟਾਈਮ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਪੁੱਛਿਆ ਜਾਂਦਾ।
ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਮੈਟ੍ਰਿਕਸ ਲਿਖੋ
ਛੋਟਾ ਮੈਟ੍ਰਿਕਸ ਨਿਯਮ-ਸਮੂਹ ਨਾਲੋਂ ਸਮੀਖਿਆ ਕਰਨਾ ਸੌਖਾ ਹੈ, ਅਤੇ ਇਹ ਉਹ ਇਕਰਾਰਨਾਮਾ ਹੈ ਜੋ ਲਾਗੂਆਂ ਨੂੰ ਪੂਰਾ ਕਰਨਾ ਹੈ: ਇੱਕੋ ਸਮੂਹ ਦੇ ਸਾਥੀ ਮਨਜ਼ੂਰ, ਸਮੂਹਾਂ ਵਿਚਕਾਰ ਸਾਥੀ ਵਰਜਿਤ, ਦੋਵੇਂ ਸਮੂਹਾਂ ਨੂੰ ਇੱਕ ਨਾਮਿਤ ਸਾਂਝੀ ਸੇਵਾ ਤੱਕ ਮਨਜ਼ੂਰੀ, ਬਾਕੀ ਸਭ ਵਰਜਿਤ। ਫਾਇਰਵਾਲ ਸੰਪਾਦਕ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਚਾਰ ਲਾਈਨਾਂ ਲਿਖੋ। ਜੋ ਸਮੀਖਿਅਕ ਨਿਯਮਾਂ ਦਾ ਸੰਟੈਕਸ ਨਹੀਂ ਪੜ੍ਹਦਾ ਉਹ ਵੀ ਮੈਟ੍ਰਿਕਸ ਜਾਂਚ ਸਕਦਾ ਹੈ। ਫਿਰ ਲਾਗੂਆਂ ਨੂੰ ਸਿਰਫ਼ ਲਾਈਨਾਂ ਨਾਲ ਮੇਲ ਖਾਣਾ ਹੈ।
| Source | Destination | Decision |
|---|---|---|
| Group A address | Another Group A address | Allow |
| Group A address | A Group B address | Deny |
| Either group | The shared internal service | Allow |
| Either group | Anything not listed | Deny |
ਲਿਖਦੇ ਸਮੇਂ ਤਿੰਨ ਮੰਜ਼ਿਲ ਵਰਗ ਵੱਖਰੇ ਰੱਖੋ। VPN ਹੋਸਟ ਉੱਤੇ ਸੇਵਾ ਸਥਾਨਕ ਇਨਪੁਟ ਹੈ, ਦੂਜਾ ਕਲਾਇੰਟ ਸਾਥੀ ਟਰਾਂਜ਼ਿਟ ਹੈ, ਅਤੇ ਗੇਟਵੇ ਪਿੱਛੇ ਦੀ ਮਸ਼ੀਨ ਵੱਖਰਾ ਫਾਰਵਰਡਿੰਗ ਮਾਰਗ ਹੈ। ਇੱਕ ਉਦਾਰ ਨਿਯਮ ਤਿੰਨੇ ਹਾਦਸਾਵਸ਼ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਸਮੂਹ ਨੀਤੀ ਵਾਧੂ ਕਦਮਾਂ ਵਾਲਾ ਸਮਤਲ ਨੈੱਟਵਰਕ ਬਣ ਜਾਂਦੀ ਹੈ। ਹਰ ਕਤਾਰ ਦੇ ਕੋਲ ਵਰਗ ਲਿਖੋ ਤਾਂ ਜੋ ਇਰਾਦਾ ਅਗਲੀ ਸੋਧ ਤੱਕ ਬਚਿਆ ਰਹੇ।
ਨਿਯਮ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਉਹ ਟਿਕਦੇ ਹਨ
ਫਾਇਰਵਾਲ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਜਿੱਥੇ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ ਉੱਥੇ ਹੀ ਫੈਸਲੇ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਸੇ ਵੀ ਮਨਜ਼ੂਰੀ ਦੇਣ ਵਾਲੇ ਨਿਯਮ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਉਹਨਾਂ ਨੂੰ ਨਿਗਲ ਸਕਦਾ ਹੈ। ਨਿਯਮਾਂ ਦਾ ਕ੍ਰਮ ਨੀਤੀ ਦਾ ਹਿੱਸਾ ਹੈ, ਅਤੇ ਵਿਆਪਕ ਮਨਜ਼ੂਰੀ ਤੋਂ ਬਾਅਦ ਰੱਖਿਆ ਸਹੀ ਨਿਯਮ ਕੁਝ ਵੀ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ। ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਨਿਯਮ ਨੰਬਰ ਨੋਟ ਕਰੋ। ਸੰਪਾਦਕ ਵਿੱਚ ਮੌਜੂਦ ਪਰ ਚੱਲ ਰਹੇ ਨਿਯਮ-ਸਮੂਹ ਵਿੱਚ ਨਾ ਹੋਣ ਵਾਲੀ ਨੀਤੀ ਯੋਜਨਾ ਹੈ, ਨਿਯੰਤਰਣ ਨਹੀਂ।
ਨੀਤੀ ਬਦਲਣ 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਪ੍ਰਵਾਹਾਂ ਦਾ ਕੀ ਹੋਵੇਗਾ ਇਹ ਤੈਅ ਕਰੋ, ਕਿਉਂਕਿ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਖੋਲ੍ਹਿਆ ਸੈਸ਼ਨ ਬਾਅਦ ਵਿੱਚ ਵੀ ਚੱਲ ਸਕਦਾ ਹੈ। ਜਾਣ ਵਾਲੇ ਮੈਂਬਰ ਨੂੰ ਤੁਰੰਤ ਪਹੁੰਚ ਗੁਆਉਣੀ ਹੋਵੇ ਤਾਂ ਕਨੈਕਸ਼ਨ ਦੇ ਆਪਣੇ ਆਪ ਬੰਦ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ ਉਸ ਸਥਿਤੀ ਨੂੰ ਖਤਮ ਕਰਨ ਦਾ ਤਰੀਕਾ ਨਿਯਮ-ਸਮੂਹ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਫਾਇਰਵਾਲ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਦਾ ਮਾਲਕ ਸਿਸਟਮ ਰਾਹੀਂ ਨਿਯਮ ਪੱਕੇ ਕਰੋ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਕੋਲ ਮੈਟ੍ਰਿਕਸ ਦਰਜ ਕਰੋ। ਦਰਜ ਨਾ ਕੀਤੀ ਨੀਤੀ ਅਗਲੀ ਘਟਨਾ ਵਿੱਚ ਯਾਦ ਤੋਂ ਦੁਬਾਰਾ ਕੱਢੀ ਜਾਂਦੀ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਕਾਹਲੇ ਵਿਅਕਤੀ ਵੱਲੋਂ।
ਦੋਵਾਂ ਪਾਸਿਆਂ ਤੋਂ ਸਾਬਤ ਕਰੋ
ਹਰ ਸਮੂਹ ਦੇ ਇੱਕ ਕਲਾਇੰਟ ਤੋਂ ਇੱਕੋ ਸਮੂਹ ਦੀ ਪਹੁੰਚ, ਸਮੂਹਾਂ ਵਿਚਕਾਰ ਅਸਫਲਤਾ ਅਤੇ ਸਾਂਝੀ ਸੇਵਾ ਦੀ ਜਾਂਚ ਕਰੋ। ਇੱਕ ਕਲਾਇੰਟ ਤੋਂ ਇੱਕੋ ਜਾਂਚ ਮੈਟ੍ਰਿਕਸ ਦਾ ਅੱਧਾ ਹਿੱਸਾ ਸਾਬਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਛੱਡਿਆ ਅੱਧਾ ਆਮ ਤੌਰ 'ਤੇ ਗਲਤ ਹੁੰਦਾ ਹੈ। ਇਨਕਾਰ ਦੀ ਦਿਸ਼ਾ ਦੋ ਵਾਰ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਕੈਸ਼ ਕੀਤਾ ਸੈਸ਼ਨ ਲਾਗੂ ਕਰਨ ਦੀ ਗਲਤੀ ਲੁਕਾ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਕਿਹੜੀ ਜੋੜੀ ਜਾਂਚੀ ਇਹ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਇਸਨੂੰ ਨਾ ਦੁਹਰਾਏ।
ਜੇ ਸੁਰੰਗ IPv6 ਲੈ ਜਾਂਦੀ ਹੈ ਤਾਂ ਉਸ 'ਤੇ ਜਾਂਚ ਦੁਹਰਾਓ, ਅਤੇ ਆਮ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਮਾਣਿਕਰਨ ਕਾਇਮ ਰੱਖੋ। ਸਰੋਤ ਪ੍ਰੀਫਿਕਸ ਖਾਤਾ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਨੈੱਟਵਰਕ ਨੀਤੀ ਪਾਰ ਕਰਨ ਦਾ ਅਰਥ ਇਹ ਨਹੀਂ ਕਿ ਸੇਵਾ ਨੂੰ ਕਾਲ ਕਰਨ ਵਾਲੇ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।