ਇੱਕ ਲੀਨਕਸ ਮਸ਼ੀਨ ਉੱਤੇ ਦੋ VPN: ਨਤੀਜੇ ਮਿਲਾਏ ਬਿਨਾਂ ਹਰ ਇੱਕ ਨੂੰ ਵੱਖਰਾ ਜਾਂਚੋ
ਦੋ ਹਰੇ ਆਈਕਨ ਤੁਲਨਾ ਨਹੀਂ ਹਨ। ਹਰ ਟਨਲ ਨੂੰ ਉਸਦੇ ਆਪਣੇ ਨਾਮ-ਥਾਂ ਵਿੱਚ ਰੱਖੋ, ਪਹਿਲਾਂ ਉਮੀਦ ਲਿਖੋ, ਅਤੇ ਨਤੀਜੇ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰਾਹ ਸਾਬਤ ਕਰੋ।
ਦੋ ਹਰੇ ਕਨੈਕਸ਼ਨ ਆਈਕਨ ਤੁਲਨਾ ਵਰਗੇ ਲੱਗਦੇ ਹਨ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਇੱਤਫ਼ਾਕ ਹੁੰਦੇ ਹਨ। ਜੇ ਜਾਂਚ ਬੇਨਤੀ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਟਨਲ ਵਰਤ ਸਕਦੀ ਸੀ, ਤਾਂ ਨਤੀਜਾ ਵਧੀਆ ਹਾਲਤ ਵਿੱਚ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਅਤੇ ਮਾੜੀ ਹਾਲਤ ਵਿੱਚ ਕਿਸੇ ਦਾ ਵੀ ਵਰਣਨ ਨਹੀਂ ਕਰਦਾ। ਹਰ ਨਿਰੀਖਣ ਨੂੰ ਨੈਟਵਰਕ ਸੰਦਰਭ, ਇੱਛਤ ਮੰਜ਼ਿਲ ਅਤੇ ਜਾਂਚ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੀ ਉਮੀਦ ਦਿਓ। ਆਪਣੇ ਆਪ ਸੰਭਾਲੀ ਲੀਨਕਸ ਮਸ਼ੀਨ ਉੱਤੇ, ਨਾਮ ਵਾਲੇ ਨੈਟਵਰਕ ਨਾਮ-ਥਾਂ ਹੀ ਉਹ ਵੱਖਰਾਪਣ ਖਰੀਦਣ ਦਾ ਸਭ ਤੋਂ ਸਸਤਾ ਤਰੀਕਾ ਹਨ।
ਦੋ ਹਰੀਆਂ ਬੱਤੀਆਂ ਤੁਲਨਾ ਨਹੀਂ ਹਨ
ਨਾਮ-ਥਾਂ ਰਾਊਟਿੰਗ ਟੇਬਲਾਂ, ਇੰਟਰਫ਼ੇਸਾਂ ਅਤੇ ਨੈਟਵਰਕ ਸਟੈਕ ਦੀ ਹਾਲਤ ਨੂੰ ਵੱਖਰਾ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਦੇ ਅੰਦਰ ਸ਼ੁਰੂ ਹੋਈ ਬੇਨਤੀ ਚੁੱਪਚਾਪ ਦੂਜੇ ਦੀ ਟਨਲ ਉਧਾਰ ਨਹੀਂ ਲੈ ਸਕਦੀ। ਜੋ ਇਹ ਵੱਖਰਾ ਨਹੀਂ ਕਰਦੀ ਉਹ ਹੈ ਪ੍ਰੋਸੈਸਰ, ਭੌਤਿਕ ਅਪਲਿੰਕ ਜਾਂ ਹੋਸਟ ਉੱਤੇ ਚੱਲ ਰਿਹਾ ਨਾਮ-ਹੱਲ ਸੇਵਾ। ਇਸੇ ਆਖਰੀ ਖੋੜ ਵਿੱਚ ਇਹਨਾਂ ਜਾਂਚਾਂ ਵਿੱਚੋਂ ਬਹੁਤੀਆਂ ਬਿਨਾਂ ਕਿਸੇ ਦੇ ਧਿਆਨ ਵਿੱਚ ਆਏ ਅਸਫਲ ਹੁੰਦੀਆਂ ਹਨ। ਨਾਮ-ਥਾਂ ਛੱਡ ਕੇ ਹੋਸਟ ਦੇ ਹੱਲਕਰਤਾ ਨੂੰ ਪੁੱਛਣ ਵਾਲੀ ਖੋਜ ਜਾਂਚ ਅਧੀਨ ਟਨਲ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਾ ਰੱਖਣ ਵਾਲਾ ਜਵਾਬ ਮੋੜਦੀ ਹੈ।
ਇਹ ਕਾਰਵਾਈ ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਅਤੇ ਮਨਜ਼ੂਰ ਦੋ ਜਾਂਚ ਨਾਮ-ਥਾਂ, ਕੰਮ ਕਰਦੀ ਬਾਹਰੀ ਕਨੈਕਟੀਵਿਟੀ ਅਤੇ ਸਮਰਥਿਤ ਕਲਾਇੰਟ ਮੰਨ ਲੈਂਦੀ ਹੈ। ਇਹ ਕੁਝ ਨਹੀਂ ਬਣਾਉਂਦੀ, ਕੁਝ ਦਰਜ ਨਹੀਂ ਕਰਦੀ ਅਤੇ ਕੋਈ ਸੰਰਚਨਾ ਨਹੀਂ ਬਦਲਦੀ। ਜਦੋਂ ਕਲਾਇੰਟ ਨੂੰ ਪੂਰਾ ਡੈਸਕਟਾਪ ਸੈਸ਼ਨ ਚਾਹੀਦਾ ਹੋਵੇ ਜਾਂ ਇਸ ਤੋਂ ਬਾਹਰ ਚੱਲਣ ਤੋਂ ਇਨਕਾਰ ਕਰੇ, ਤਾਂ ਵੱਖਰੀਆਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਹੀ ਇਮਾਨਦਾਰ ਚੋਣ ਰਹਿੰਦੀਆਂ ਹਨ।
ਪਹਿਲੀ ਦੌੜ ਤੋਂ ਪਹਿਲਾਂ ਉਮੀਦ ਪੱਕੀ ਕਰੋ
ਹਰ ਸੰਦਰਭ ਲਈ ਤੈਅ ਕਰੋ ਕਿ ਸਫਲਤਾ ਕਿਹੋ ਜਿਹੀ ਦਿਸਦੀ ਹੈ: ਹੱਲਕਰਤਾ, ਸੇਵਾ ਦਾ ਨਾਮ, ਉਮੀਦ ਕੀਤਾ ਪਤਾ ਅਤੇ ਟਨਲ ਡਿੱਗਣ 'ਤੇ ਲੋੜੀਂਦਾ ਵਿਵਹਾਰ। ਉਹ ਯੋਜਿਤ ਮੁੱਲ ਉਹਨਾਂ ਦੇ ਆਪਣੇ ਕਾਲਮ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਯੋਜਨਾ ਅਤੇ ਨਿਰੀਖਣ ਮਿਲਾਉਣ ਵਾਲਾ ਰਿਕਾਰਡ ਸਮਾਂ-ਮੋਹਰ ਵਾਲੀ ਕਾਲਪਨਿਕ ਕਹਾਣੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਂਚ-ਸੂਚੀ ਉਹੀ ਰੂਪ ਹੈ ਜੋ ਰਿਕਾਰਡ ਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੇ ਕਨੈਕਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਕਤਾਰ ਭਰਨਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
ਹੱਲਕਰਤਾ ਦੀ ਵਾਇਰਿੰਗ ਨੂੰ ਉਸ ਰਿਕਾਰਡ ਵਿੱਚ ਆਪਣੀ ਕਤਾਰ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਝੂਠ ਬੋਲਣ ਦੀ ਸਭ ਤੋਂ ਵੱਧ ਸੰਭਾਵਨਾ ਇਸੇ ਖੇਤਰ ਵਿੱਚ ਹੈ। ਨਾਮ-ਥਾਂ ਨਾਲ ਜੁੜੀਆਂ ਫ਼ਾਈਲਾਂ, ਜਿਵੇਂ ਕਿ /etc/netns/vpn-a/resolv.conf ਕਮਾਂਡ ਨਾਮ-ਥਾਂ ਦੇ ਅੰਦਰ ਚੱਲਣ 'ਤੇ ਆਪਣੇ ਆਮ ਰਾਹਾਂ 'ਤੇ ਦਿਸਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ iproute2 ਦਾ ਨਾਮ-ਥਾਂ ਹਵਾਲਾ ਦੱਸਦਾ ਹੈ, ਪਰ ਨਾਮ-ਸੇਵਾ ਬਦਲਣ ਦੀ ਸੰਰਚਨਾ ਅਤੇ ਇਸ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕੋਈ ਵੀ ਸਥਾਨਕ ਹੱਲਕਰਤਾ ਅਜੇ ਵੀ ਖੋਜ ਨੂੰ ਹੋਸਟ ਵੱਲ ਵਾਪਸ ਖਿੱਚ ਸਕਦੇ ਹਨ।
ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਟਨਲ, ਦੂਜੀ ਡਿਸਕਨੈਕਟ
B ਹੇਠਾਂ ਰਹਿੰਦਿਆਂ A ਨੂੰ ਇਸਦੇ ਮੌਜੂਦਾ ਮਾਲਕ ਰਾਹੀਂ ਜੋੜੋ, ਫਿਰ ਪ੍ਰਬੰਧਕੀ ਸੰਦਰਭ ਤੋਂ ਨੀਤੀ, ਰਾਊਟ ਅਤੇ ਚੁਣਿਆ ਰਾਹ ਵੇਖੋ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਤਿੰਨ ਕਮਾਂਡਾਂ ਹਾਲਤ ਪੜ੍ਹਦੀਆਂ ਹਨ; ਸਿਰਫ਼ ਆਖਰੀ ਇੱਕ ਨਾਮ-ਸੇਵਾ ਨਾਲ ਸੰਪਰਕ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਐਪਲੀਕੇਸ਼ਨ ਬੇਨਤੀ ਨਹੀਂ ਭੇਜਦੀ।
sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internalਰਾਊਟ ਖੋਜ ਮੰਜ਼ਿਲ ਬਾਰੇ ਇੱਕ ਕਾਲਪਨਿਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਇਹ ਨਹੀਂ ਦਿਖਾ ਸਕਦੀ ਕਿ ਸੇਵਾ ਟਰੈਫ਼ਿਕ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ। ਇਹਨਾਂ ਦੋ ਕਿਸਮਾਂ ਦੇ ਸਬੂਤ ਵੱਖਰੇ ਕਾਲਮਾਂ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਰੱਦ ਕੀਤੇ ਕਨੈਕਸ਼ਨ ਦੇ ਕੋਲ ਸਿਹਤਮੰਦ ਰਾਊਟ ਅਸਲੀ ਅਤੇ ਆਮ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ। ਫਿਰ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਇੱਕ ਬੇਨੁਕਸਾਨ ਮਨਜ਼ੂਰ ਬੇਨਤੀ ਭੇਜੋ, ਜਿਸ ਨੂੰ A ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਇਸਦੇ ਆਮ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਰਹਿਤ ਵਰਤੋਂਕਾਰ ਵਜੋਂ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ ਹੋਵੇ, ਸਰਟੀਫ਼ਿਕੇਟ ਤਸਦੀਕ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਅਛੂਤ ਰੱਖਦਿਆਂ, ਅਤੇ ਸੇਵਾ ਵੱਲੋਂ ਵੇਖੇ ਸਰੋਤ ਪਤੇ ਸਮੇਤ ਨਤੀਜਾ ਦਰਜ ਕਰੋ। A ਨੂੰ ਇਸਦੇ ਮਾਲਕ ਰਾਹੀਂ ਡਿਸਕਨੈਕਟ ਕਰੋ ਅਤੇ B ਲਈ ਪੂਰੀ ਬੁਨਿਆਦੀ ਲਾਈਨ ਦੁਹਰਾਓ, ਆਪਣੇ ਕੀਤੇ ਕਿਸੇ ਵੀ ਸੰਰਚਨਾ ਬਦਲਾਅ ਨੂੰ ਨੋਟ ਕਰਦਿਆਂ, ਵਰਨਾ ਦੋਵੇਂ ਬੁਨਿਆਦੀ ਲਾਈਨਾਂ ਤੁਲਨਾਯੋਗ ਨਹੀਂ ਰਹਿਣਗੀਆਂ।
ਦੋਵੇਂ ਉੱਪਰ, ਫਿਰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਹੇਠਾਂ
ਅਚੱਲ ਹਾਲਤ ਸੌਖਾ ਹਿੱਸਾ ਹੈ। ਦੋਵੇਂ ਟਨਲ ਜੁੜੀਆਂ ਹੋਣ 'ਤੇ ਹਰ ਸੰਦਰਭ ਦੀ ਖੋਜ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਬੇਨਤੀ ਦੁਹਰਾਓ, ਫਿਰ ਇੱਕ ਟਨਲ ਤੋੜੋ ਅਤੇ ਦੂਜੀ ਵੇਖੋ। ਜਦੋਂ ਕਨੈਕਸ਼ਨ ਦਾ ਕ੍ਰਮ ਆਪ ਹੀ ਸਵਾਲ ਹੋਵੇ ਤਾਂ ਉਲਟੇ ਕ੍ਰਮ ਵਿੱਚ ਮੁੜ ਜੁੜੋ।
sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20ਕੈਪਚਰ ਉਹ ਬਹਿਸਾਂ ਨਿਬੇੜਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਨਤੀਜਾ ਨਿਬੇੜ ਨਹੀਂ ਸਕਦਾ: ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਤੁਹਾਡੇ ਉਮੀਦ ਕੀਤੇ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਬਾਹਰ ਗਈ ਜਾਂ ਕਿਸੇ ਹੋਰ ਹੀ ਚੀਜ਼ ਰਾਹੀਂ। ਹਰ ਤਬਦੀਲੀ ਲਈ ਮਾਲਕ ਦੀ ਕਾਰਵਾਈ, ਸਮਾਂ-ਮੋਹਰ, ਰਾਊਟ ਨਤੀਜਾ, ਨਾਮ ਨਤੀਜਾ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨਤੀਜਾ ਦਰਜ ਕਰੋ। ਫਿਰ ਪ੍ਰਭਾਵਿਤ ਨਾਮ-ਥਾਂ ਦੇ ਅੰਦਰ ਸੁਰੱਖਿਅਤ ਬੰਦ ਹੋਣ ਦੀ ਲੋੜ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਵੱਖਰਾਪਣ ਕੋਈ ਕਿਲ ਸਵਿੱਚ ਨਹੀਂ ਹੈ। ਨਾਮ-ਥਾਂ ਦੋ ਟਨਲਾਂ ਨੂੰ ਵੱਖ ਰੱਖਦੀ ਹੈ; ਜਦੋਂ ਇਸਦੀ ਪਰੋਫ਼ਾਈਲ ਕਹੇ ਕਿ ਟਰੈਫ਼ਿਕ ਰੁਕਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇਹ ਕਿਸੇ ਨੂੰ ਵੀ ਟਰੈਫ਼ਿਕ ਢੋਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦੀ।
ਇਹ ਰਿਕਾਰਡ ਕੀ ਦਾਅਵਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ
ਇੱਕ ਪਾਸ ਇਸ ਬਣਤਰ ਲਈ, ਇਸ ਹੋਸਟ ਉੱਤੇ, ਉਸ ਵੇਲੇ ਉਹ ਨਿਰੀਖਣ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ ਡੈਸਕਟਾਪ ਰਾਊਟਿੰਗ ਟੇਬਲ ਸਾਂਝੀ ਕਰਨ ਵਾਲੇ ਦੋ ਕਲਾਇੰਟਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਅਤੇ ਦੋਵੇਂ ਟਨਲਾਂ ਭਾਰ ਢੋਂਦਿਆਂ ਦੇ ਥ੍ਰੂਪੁਟ ਬਾਰੇ ਵੀ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਉਹ ਵੱਖਰੀਆਂ ਜਾਂਚਾਂ ਵਾਲੇ ਵੱਖਰੇ ਸਵਾਲ ਹਨ, ਅਤੇ ਤੁਲਨਾ ਹਰ ਕਤਾਰ ਨਾਲ ਜੁੜੇ ਸੰਦਰਭ ਜਿੰਨੀ ਹੀ ਚੰਗੀ ਹੁੰਦੀ ਹੈ।
ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਰਿਕਾਰਡ ਵਿੱਚ ਸਫਲਤਾਵਾਂ ਦੇ ਕੋਲ ਰੱਖੋ, ਉਸ ਵੇਲੇ ਕਿਹੜੀ ਟਨਲ ਉੱਪਰ ਸੀ ਇਹ ਦੱਸਦਿਆਂ। ਜੋ ਸਾਫ਼ ਪੰਨਾ ਮਾਪ ਵੇਲੇ ਦੀ ਹਾਲਤ ਲੁਕਾਉਂਦਾ ਹੈ ਉਹ ਹਾਲਤ ਦਿਖਾਉਣ ਵਾਲੇ ਭੈੜੇ ਪੰਨੇ ਤੋਂ ਵੀ ਮਾੜਾ ਹੈ। ਰਿਕਾਰਡ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਮੁੜ ਵਰਤੋਂਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਸੰਦਰਭ, ਸਕੋਰ ਨਹੀਂ।
ਇੱਕ ਮਸ਼ੀਨ ਉੱਤੇ ਦੋ ਟਨਲਾਂ ਦੀ ਇਮਾਨਦਾਰ ਤੁਲਨਾ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਸਿਰਫ਼ ਉੱਨੇ ਹੀ ਸੰਦਰਭਾਂ ਵਿੱਚ ਜਿੰਨੇ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਕੰਟਰੋਲ ਕੀਤੇ। ਇਸ ਤੋਂ ਅੱਗੇ ਕੁਝ ਵੀ ਕੋਲ ਹਰਾ ਆਈਕਨ ਲੱਗੀ ਇੱਕ ਇੱਛਾ ਹੈ।