ਰੂਟ-ਆਧਾਰਿਤ ਬਨਾਮ ਨੀਤੀ-ਆਧਾਰਿਤ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN: ਕੀ ਵੱਖਰਾ ਹੈ
ਨੀਤੀ-ਆਧਾਰਿਤ IPsec ਚੋਣਕਰਤਾ ਨਾਲ ਟ੍ਰੈਫਿਕ ਚੁਣਦਾ ਹੈ; ਰੂਟ-ਆਧਾਰਿਤ ਇਸਨੂੰ ਟਨਲ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਅਜੇ ਵੀ ਫਾਇਰਵਾਲ ਨਿਯਮ ਅਤੇ ਵਾਪਸੀ ਰੂਟ ਚਾਹੀਦਾ ਹੈ।
ਦੋਵੇਂ ਡਿਜ਼ਾਈਨ ਉਹੀ ਟ੍ਰੈਫਿਕ ਉਸੇ IPsec ਮਸ਼ੀਨਰੀ ਨਾਲ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚ ਇਹ ਫ਼ਰਕ ਹੈ ਕਿ ਕਿਹੜਾ ਪੈਕਟ ਟਨਲ ਵਿੱਚ ਦਾਖਲ ਹੋਵੇਗਾ ਇਹ ਕੌਣ ਤੈਅ ਕਰਦਾ ਹੈ। ਨੀਤੀ-ਆਧਾਰਿਤ ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਗੱਲਬਾਤ ਕੀਤੇ ਟ੍ਰੈਫਿਕ ਚੋਣਕਰਤਾ ਇਹ ਕੰਮ ਕਰਦੇ ਹਨ; ਰੂਟ-ਆਧਾਰਿਤ ਵਿੱਚ ਟਨਲ ਇੰਟਰਫੇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਰੂਟ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਰਲਾ ਦੇਣ ਨਾਲ ਉਹੀ ਜਾਣੀ-ਪਛਾਣੀ ਸਹਾਇਤਾ ਥ੍ਰੈਡ ਬਣਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਟਨਲ ਸਥਾਪਿਤ ਹੋਣ ਦੀ ਰਿਪੋਰਟ ਦਿੰਦਾ ਹੈ ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਕਿਤੇ ਨਹੀਂ ਪਹੁੰਚਦੀ। ਇਹ ਫ਼ਰਕ ਸਭ ਤੋਂ ਵੱਧ ਉਦੋਂ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਨੈੱਟਵਰਕ ਜੋੜਦੇ ਹੋ, ਰੂਟਿੰਗ ਪ੍ਰੋਟੋਕੋਲ ਚਲਾਉਂਦੇ ਹੋ, ਜਾਂ ਅਜਿਹੇ ਮਾਰਗ ਨੂੰ ਡੀਬੱਗ ਕਰਦੇ ਹੋ ਜੋ ਚੁੱਪ-ਚਾਪ ਗਲਤ ਨਿਕਾਸ ਰਾਹੀਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ।
ਟਨਲ ਵਿੱਚ ਕੀ ਦਾਖਲ ਹੁੰਦਾ ਹੈ ਇਹ ਤੈਅ ਕਰਨ ਦੇ ਦੋ ਤਰੀਕੇ
ਨੀਤੀ-ਆਧਾਰਿਤ VPN ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਪ੍ਰੀਫਿਕਸਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਸੁਰੱਖਿਆ ਨੀਤੀ ਬਣਾਉਂਦਾ ਹੈ, ਫਿਰ ਜੋ ਵੀ ਫਿੱਟ ਬੈਠੇ ਉਸਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ। ਸਾਥੀ ਨੂੰ ਅਨੁਕੂਲ ਚੋਣਕਰਤਿਆਂ ਦੀ ਗੱਲਬਾਤ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਭਾਵੀ ਦਾਇਰਾ ਆਖਰਕਾਰ ਦੋਵਾਂ ਧਿਰਾਂ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੇ ਦਾ ਕਟਾਵ ਬਣ ਜਾਂਦਾ ਹੈ। ਉਸ ਕਟਾਵ ਤੋਂ ਬਾਹਰ ਕੁਝ ਵੀ ਸੁਰੱਖਿਅਤ ਨਹੀਂ, ਰੂਟਿੰਗ ਟੇਬਲ ਕੁਝ ਵੀ ਕਹੇ।
ਰੂਟ-ਆਧਾਰਿਤ VPN ਟਨਲ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਨ ਵਾਲਾ ਇੰਟਰਫੇਸ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਰੂਟਿੰਗ ਟੇਬਲ ਨੂੰ ਉਸ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਭੇਜਣ ਦਿੰਦਾ ਹੈ। IKE ਡੀਮਨ ਅਜੇ ਵੀ ਸਥਿਤੀ ਅਤੇ ਹਰ ਇੰਟਰਫੇਸ ਦੀ ਨੀਤੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਬਾਰੀਕੀ ਹੈ ਜੋ ਲੋਕ ਉਦੋਂ ਛੱਡ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਰੂਟਾਂ ਨੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਥਾਂ ਲੈ ਲਈ ਹੈ। ਦੋਵੇਂ ਡਿਜ਼ਾਈਨ IPsec ਨਾਲ ਐਨਕ੍ਰਿਪਟ ਕਰਦੇ ਹਨ; ਸਿਰਫ਼ ਚੋਣ ਦਾ ਤੰਤਰ ਵੱਖਰਾ ਹੈ।
ਹੇਠਾਂ ਦਿੱਤੀ ਤੁਲਨਾ ਨੂੰ ਸਕੋਰਕਾਰਡ ਨਹੀਂ ਸਗੋਂ ਨਾਕਾਮੀ ਦੇ ਸੰਕੇਤਾਂ ਦੇ ਸਮੂਹ ਵਜੋਂ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਕਾਲਮ ਆਪਣੇ ਆਪ ਨਹੀਂ ਜਿੱਤਦਾ।
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
ਨੀਤੀ-ਆਧਾਰਿਤ: ਚੋਣਕਰਤਾ ਹੀ ਸਮਝੌਤਾ ਹੈ
ਚੋਣਕਰਤਿਆਂ ਦੀ ਗੱਲਬਾਤ ਹੁੰਦੀ ਹੈ, ਸਿਰਫ਼ ਸੰਰਚਨਾ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਇੱਕ ਪਾਸੇ 10.10.0.0/16 ਅਤੇ ਦੂਜੇ ਪਾਸੇ 10.10.1.0/24 ਪੇਸ਼ ਕਰੋ, ਫਿਰ ਸੰਗਠਨ ਉਹ ਢਕ ਲਵੇਗਾ ਜਿੱਥੇ ਗੱਲਬਾਤ ਰੁਕੀ ਸੀ ਅਤੇ ਬਾਕੀ ਹਰ ਮੇਜ਼ਬਾਨ ਬਾਹਰ ਰਹੇਗਾ।
ਸੰਰਚਨਾ ਫਾਇਲ ਦੀ ਥਾਂ ਸਥਾਪਿਤ ਸਥਿਤੀ ਪੜ੍ਹੋ। Linux ਸਾਥੀ ਉੱਤੇ ਕਰਨਲ ਦੀਆਂ ਆਪਣੀਆਂ ਟੇਬਲਾਂ ਹੀ ਮੂਲ ਸੱਚ ਹਨ, ਅਤੇ ਉਹ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਕਿ ਗੱਲਬਾਤ ਤੋਂ ਕੀ ਬਚਿਆ। ਸਹੀ ਪ੍ਰੀਫਿਕਸ ਦੱਸਣ ਵਾਲੀ ਪਰ ਮੇਲ ਖਾਂਦੀ ਸਥਿਤੀ ਤੋਂ ਬਿਨਾਂ ਨੀਤੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸੰਗਠਨ ਕਦੇ ਬਣਿਆ ਹੀ ਨਹੀਂ। ਗਲਤ ਪ੍ਰੀਫਿਕਸ ਲਈ ਨੀਤੀ ਨਾਲ ਜੁੜੀ ਸਥਿਤੀ ਉਲਟ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਇਹ ਸਿਹਤਮੰਦ ਦਿਖਣ ਵਾਲਾ ਟਨਲ ਬਣਾਉਂਦੀ ਹੈ ਜਦੋਂ ਕਿ ਇੱਕ ਸਬਨੈੱਟ ਕਿਤੇ ਨਹੀਂ ਪਹੁੰਚਦਾ।
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasਤੁਸੀਂ ਜਿਨ੍ਹਾਂ ਪ੍ਰੀਫਿਕਸਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹੋ ਉਹਨਾਂ ਨਾਲ ਦੋਵੇਂ ਆਉਟਪੁੱਟ ਤੁਲਨਾ ਕਰੋ। ਉਹ ਇੱਕੋ ਤੁਲਨਾ ਕੰਮ ਕਰਦੇ ਟਨਲ ਅਤੇ ਅਪਹੁੰਚ ਸਰਵਰ ਬਾਰੇ ਬਹੁਤੀਆਂ ਰਿਪੋਰਟਾਂ ਹੱਲ ਕਰ ਦਿੰਦੀ ਹੈ। ਇਹ ਇਹ ਵੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਸਾਥੀ ਬਦਲਣਾ ਹੈ, ਕਿਉਂਕਿ ਬੇਮੇਲ ਆਮ ਤੌਰ ਉੱਤੇ ਇੱਕੋ ਦਿਸ਼ਾ ਵਿੱਚ ਦਿਖਦਾ ਹੈ।
ਰੂਟ-ਆਧਾਰਿਤ: ਇੰਟਰਫੇਸ ਹੀ ਸਮਝੌਤਾ ਹੈ
XFRM ਇੰਟਰਫੇਸ ਟਨਲ ਨੂੰ ਨਾਮ ਅਤੇ ਪਛਾਣ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਉੱਥੇ ਪਹੁੰਚਦਾ ਹੈ ਕਿਉਂਕਿ ਰੂਟਿੰਗ ਟੇਬਲ ਇਹੀ ਕਹਿੰਦੀ ਹੈ। ਕਈ ਦੂਰਲੇ ਪ੍ਰੀਫਿਕਸ ਫਿਰ ਚੋਣਕਰਤਾ ਦੀ ਸਮੱਸਿਆ ਦੀ ਥਾਂ ਰੂਟਿੰਗ ਦੀ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਰੂਟਿੰਗ ਪ੍ਰੋਟੋਕੋਲ ਉਹਨਾਂ ਦਾ ਐਲਾਨ ਕਰ ਸਕਦਾ ਹੈ। ਇਹੀ ਅਸਲ ਲਾਭ ਹੈ, ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ।
ਇੰਟਰਫੇਸ ਨੀਤੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹਟਾਉਂਦਾ। ਡੀਮਨ ਇੰਟਰਫੇਸ ਦੀ ਪਛਾਣ ਨਾਲ ਬੱਝੇ ਨਿਯਮ ਹਰ ਇੰਟਰਫੇਸ ਲਈ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਗਲਤ ਇੰਟਰਫੇਸ ਉੱਤੇ ਆਉਣ ਵਾਲਾ ਪੈਕਟ ਫਿਰ ਵੀ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਜਿਸ ਸਰੋਤ ਪਤੇ ਨੂੰ ਸਾਥੀ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰੇਗਾ ਉਹ ਵੀ ਪੂਰਨ ਰੂਟ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਰੂਟ-ਆਧਾਰਿਤ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦਾਖਲਾ ਰੂਟ ਤੈਅ ਕਰਦਾ ਹੈ, ਨੀਤੀ ਗਾਇਬ ਹੋ ਗਈ ਹੈ ਨਹੀਂ।
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10ਰੂਟ ਲੱਗਣ ਤੋਂ ਬਾਅਦ ਇੰਟਰਫੇਸ ਕਾਊਂਟਰਾਂ ਵੱਲ ਧਿਆਨ ਦਿਓ। ਰੂਟ ਮੌਜੂਦ ਹੈ ਪਰ ਕਾਊਂਟਰ ਜ਼ੀਰੋ ਉੱਤੇ ਖੜ੍ਹੇ ਹਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟਨਲ ਵਿੱਚ ਕੁਝ ਵੀ ਮਿਲਾਇਆ ਨਹੀਂ ਜਾ ਰਿਹਾ, ਜੋ ਆਮ ਤੌਰ ਉੱਤੇ ਗੈਰਹਾਜ਼ਰ ਰੂਟ ਦੀ ਥਾਂ ਗੈਰਹਾਜ਼ਰ ਸਥਿਤੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
ਦੋਵੇਂ ਡਿਜ਼ਾਈਨ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਵੱਖ ਹੁੰਦੇ ਹਨ
ਨੈੱਟਵਰਕ ਜੋੜਨਾ ਇਹ ਜਾਂਚਣ ਦੀ ਸਭ ਤੋਂ ਸਾਫ਼ ਪਰਖ ਹੈ ਕਿ ਕਿਹੜਾ ਮਾਡਲ ਤੁਹਾਨੂੰ ਢੁਕਦਾ ਹੈ। ਰੂਟ-ਆਧਾਰਿਤ ਡਿਜ਼ਾਈਨ ਇੱਕ ਰੂਟ ਜੋੜਦਾ ਹੈ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਇੱਕ ਵਾਰ ਚੋਣਕਰਤਾ ਚੌੜਾ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਨੀਤੀ-ਆਧਾਰਿਤ ਡਿਜ਼ਾਈਨ ਦੋਵਾਂ ਸਾਥੀਆਂ ਉੱਤੇ ਪ੍ਰੀਫਿਕਸ ਜੋੜੀਆਂ ਸੋਧਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ। ਦੋ ਸਥਿਰ ਸਬਨੈੱਟ ਉਸ ਸੋਧ ਨੂੰ ਮਾਮੂਲੀ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਵੀਹ ਇਸਨੂੰ ਪ੍ਰੋਜੈਕਟ ਬਣਾ ਦਿੰਦੇ ਹਨ।
ਕੋਈ ਵੀ ਮਾਡਲ ਫਾਇਰਵਾਲ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ, ਅਤੇ ਤੁਲਨਾਵਾਂ ਆਮ ਤੌਰ ਉੱਤੇ ਇਸ ਬਿੰਦੂ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕ ਜਾਂਦੀਆਂ ਹਨ। ਚੌੜਾ ਚੋਣਕਰਤਾ ਜਾਂ ਚੌੜਾ ਰੂਟ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਐਨਕ੍ਰਿਪਟ ਹੋਵੇਗਾ, ਇਹ ਨਹੀਂ ਕਿ ਕੀ ਮਨਜ਼ੂਰ ਹੈ।
MTU ਦਾ ਵਿਵਹਾਰ ਵੀ ਅਮਲ ਵਿੱਚ ਵੱਖਰਾ ਹੈ। ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਲਾਭਦਾਇਕ ਪੇਲੋਡ ਘਟਾਉਂਦਾ ਹੈ, ਅਤੇ ਰੂਟ-ਆਧਾਰਿਤ ਇੰਟਰਫੇਸ ਆਪਣਾ MTU ਚੁੱਕਦਾ ਹੈ, ਇਸ ਲਈ ਦੋਵਾਂ ਗੇਟਵੇ ਉੱਤੇ MSS ਕਲੈਂਪ ਕਰਨਾ ਉਸ ਬਲੈਕ-ਹੋਲ ਲੱਛਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਛੋਟੇ ਜਵਾਬ ਆਉਂਦੇ ਹਨ ਅਤੇ ਵੱਡੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ। ਨੀਤੀ-ਆਧਾਰਿਤ ਟਨਲ ਦੂਜੇ ਪਾਸਿਓਂ ਉਸੇ ਕੰਧ ਨਾਲ ਟਕਰਾਉਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਚੋਣਕਰਤਾ ਪੈਕਟ ਦੇ ਆਕਾਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਸਾਥੀ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਦੀ ਥਾਂ ਕਲੈਂਪ ਜਾਣ-ਬੁੱਝ ਕੇ ਸੈੱਟ ਕਰੋ।
ਵਾਪਸੀ ਮਾਰਗ ਗੁਆਏ ਬਿਨਾਂ ਤਬਦੀਲੀ
ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਪ੍ਰੀਫਿਕਸ ਜੋੜੀਆਂ ਦਰਜ ਕਰੋ, ਫਿਰ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਮਾਰਗ ਹਿਲਾਓ ਅਤੇ ਉਸਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਦੇਖੋ। ਸਥਾਪਿਤ ਹੋਣ ਵਾਲਾ ਟਨਲ ਅੱਗੇ ਭੇਜਣ ਵਾਲਾ ਟਨਲ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਫ਼ਰਕ ਜਵਾਬ ਦੀ ਦਿਸ਼ਾ ਵਿੱਚ ਦਿਖਦਾ ਹੈ।
ਜਦੋਂ ਸਾਥੀ ਜੁੜਦੇ ਹਨ ਪਰ LAN ਮੇਜ਼ਬਾਨ ਨਹੀਂ, ਤਾਂ ਵਾਪਸੀ ਰੂਟ ਅਤੇ ਉਸ ਸਰੋਤ ਪਤੇ ਦੀ ਜਾਂਚ ਕਰੋ ਜੋ ਦੂਰਲਾ ਮੇਜ਼ਬਾਨ ਵਰਤੇਗਾ। ਦੋ ਇੰਟਰਫੇਸ ਵਾਲਾ ਮੇਜ਼ਬਾਨ ਗਲਤ ਵਾਲੇ ਤੋਂ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਚੋਣਕਰਤਾ ਤਬਦੀਲੀ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦੀ। ਐਲਗੋਰਿਦਮ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵਾਂ ਸਿਰਿਆਂ ਉੱਤੇ ਟ੍ਰੈਫਿਕ ਫੜੋ।
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsਕੰਮ ਕਰਦੇ ਸਮੇਂ ਟਨਲ ਉੱਤੇ ਨਿਰਭਰ ਨਾ ਕਰਨ ਵਾਲਾ ਪ੍ਰਬੰਧਕੀ ਮਾਰਗ ਰੱਖੋ। ਪਿੱਛੇ ਮੁੜਨਾ ਸੌਖਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਗੇਟਵੇ ਦੀ ਆਪਣੀ ਪਹੁੰਚ ਉਸ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਨਾ ਚੜ੍ਹੇ ਜਿਸਨੂੰ ਤੁਸੀਂ ਡੀਬੱਗ ਕਰ ਰਹੇ ਹੋ।