OpenVPN ਕਲਾਇੰਟ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕਦੇ: ਸਬਨੈੱਟ ਜਾਂ net30?
ਕਲਾਇੰਟ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਪਰ ਇੱਕ-ਦੂਜੇ ਤੱਕ ਨਹੀਂ। ਇੱਕ ping ਨਾਲ ਖ਼ਰਾਬੀ ਵੱਖ ਕਰੋ, ਫਿਰ ਸਬਨੈੱਟ ਟੋਪੋਲੋਜੀ, client-to-client ਜਾਂ ਬ੍ਰਿਜ ਕੀਤਾ TAP ਖੰਡ ਚੁਣੋ।
ਦੋ ਅਸੰਬੰਧਿਤ ਖ਼ਰਾਬੀਆਂ ਇੱਕੋ ਸ਼ਿਕਾਇਤ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਪਹਿਲੀ ਵਿੱਚ ਇੱਕ ਕਲਾਇੰਟ ਦੂਜੇ ਤੱਕ ਟਨਲ ਪਤੇ ਨਾਲ ਵੀ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਕਿਉਂਕਿ ਪਤੇ ਇੱਕੋ ਸਬਨੈੱਟ ਵਿੱਚ ਨਹੀਂ ਹਨ ਜਾਂ ਸਰਵਰ ਸਹਿਯੋਗੀ ਟ੍ਰੈਫ਼ਿਕ ਅੱਗੇ ਨਹੀਂ ਭੇਜਦਾ। ਦੂਜੀ ਵਿੱਚ ping ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਐਪ ਦੀ ਜੰਤਰ ਸੂਚੀ ਖਾਲੀ ਰਹਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਖੋਜ 3 ਪਰਤ ਦੀ ਟਨਲ ਵਹਾ ਨਹੀਂ ਸਕਦੀ ਅਜਿਹੇ broadcast ਉੱਤੇ ਨਿਰਭਰ ਹੈ। ਇੱਕ ping ਦੋਹਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਹੱਲ ਦੂਜੇ ਦੇ ਹੱਲ ਵਰਗਾ ਬਿਲਕੁਲ ਨਹੀਂ ਹੈ।
ਇੱਕ ping ਸਮੱਸਿਆ ਨੂੰ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ
ਇੱਕ ਕਲਾਇੰਟ ਤੋਂ ਦੂਜੇ ਕਲਾਇੰਟ ਦੇ ਟਨਲ ਪਤੇ ਉੱਤੇ ping ਕਰੋ, ਉਸਦੇ ਨਾਮ ਉੱਤੇ ਨਹੀਂ ਅਤੇ ਉਸਦੇ LAN ਪਤੇ ਉੱਤੇ ਨਹੀਂ। ਜੇ ਉਹ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਅੱਗੇ ਭੇਜਣਾ ਜਾਂ ਪਤਾ-ਨਿਰਧਾਰਣ ਸਮੱਸਿਆ ਹੈ ਅਤੇ ਉਹ ਠੀਕ ਹੋਣ ਤੱਕ ਖੋਜ ਅਪ੍ਰਸੰਗਿਕ ਹੈ। ਜੇ ਉਹ ਸਫਲ ਹੋਵੇ, ਤਾਂ ਅੱਗੇ ਭੇਜਣਾ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਬਾਕੀ ਖਾਲੀ ਥਾਂ broadcast ਜਾਂ ਨਾਮ ਹੱਲ ਹੈ।
ip addr show tun0ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਦਾ ਇੰਟਰਫ਼ੇਸ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਨੈੱਟਮਾਸਕ ਟੋਪੋਲੋਜੀ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ। /24 ਜਾਂ ਹੋਰ ਸਬਨੈੱਟ ਮਾਸਕ ਦਾ ਮਤਲਬ ਸਾਂਝਾ ਪੂਲ; ਸਹਿਯੋਗੀ ਪਤੇ ਵਾਲਾ /30 ਦਾ ਮਤਲਬ ਪੁਰਾਣਾ ਬਿੰਦੂ-ਤੋਂ-ਬਿੰਦੂ ਖਾਕਾ, ਜਿੱਥੇ ਹਰ ਕਲਾਇੰਟ ਦਾ ਠੀਕ ਇੱਕ ਗੁਆਂਢੀ ਹੁੰਦਾ ਹੈ, ਸਰਵਰ।
net30 ਬਨਾਮ ਸਬਨੈੱਟ, ਕਲਾਇੰਟ ਪਾਸਿਓਂ ਪੜ੍ਹਿਆ
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
net30 ਵਿੱਚ ਸਰਵਰ ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਛੋਟਾ ਬਲਾਕ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਰਵਰ ਅੱਗੇ ਭੇਜੇ ਬਿਨਾਂ ਦੂਜੇ ਕਲਾਇੰਟ ਦੇ ਟਨਲ ਪਤੇ ਤੱਕ ਕੋਈ ਰਸਤਾ ਨਹੀਂ ਹੁੰਦਾ। ਸਬਨੈੱਟ ਵਿੱਚ ਪੂਰਾ ਪੂਲ ਇੱਕ ਨੈੱਟਵਰਕ ਹੈ, ਹਰ ਕਲਾਇੰਟ ਹਰ ਇੱਕ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਅੱਗੇ ਭੇਜਦਾ ਹੈ। ਇਸੇ ਲਈ ਇੱਕ ਸਰਵਰ ਸੰਰਚਨਾ ਤੰਦਰੁਸਤ ਦਿਸ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਸਹਿਯੋਗੀਆਂ ਵਿਚਕਾਰ ping ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ: ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ, ਕਲਾਇੰਟ ਇੱਕੋ ਨੈੱਟਵਰਕ ਵਿੱਚ ਨਹੀਂ ਹਨ ਬੱਸ। ਕਲਾਇੰਟ ਚੱਲਦੀ ਲਿੰਕ ਅਤੇ ਜਵਾਬ ਨ ਦੇਣ ਵਾਲਾ ਸਹਿਯੋਗੀ ਪਤਾ ਦੇਖਦਾ ਹੈ, ਜੋ firewall ਵਾਂਗ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ ਪਰ ਅਸਲ ਵਿੱਚ ਪਤਾ-ਨਿਰਧਾਰਣ ਦਾ ਖਾਕਾ ਹੈ।
ਡਾਇਰੈਕਟਿਵ ਬਦਲਣਾ ਸਰਵਰ ਪਾਸੇ ਦਾ ਸੰਪਾਦਨ ਅਤੇ ਮੁੜ ਸ਼ੁਰੂ ਹੈ, ਅਤੇ ਇਹ ਪਹਿਲਾਂ ਖੁੱਲ੍ਹੇ ਸੈਸ਼ਨਾਂ ਉੱਤੇ ਨਹੀਂ ਬਲਕਿ ਅਗਲੇ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਤਬਦੀਲੀ ਦਾ ਫ਼ੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਦੁਬਾਰਾ ਜੋੜੋ। ਜੇ ਜੰਤਰ ਵੈੱਬ ਇੰਟਰਫ਼ੇਸ ਤੋਂ ਸੰਰਚਨਾ ਮੁੜ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਡਾਇਰੈਕਟਿਵ, ਫ਼ਾਈਲ ਅਤੇ ਤਾਰੀਖ਼ ਦਰਜ ਕਰੋ, ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਹੋਣ ’ਤੇ ਉਸੇ ਰਾਹੀਂ ਸੰਪਾਦਨ ਕਰੋ, ਕਿਉਂਕਿ ਮੁੜ ਨਿਰਮਾਣ ਅਗਲੀ ਵਾਰ ਸੰਭਾਲਣ ’ਤੇ ਹੱਥ ਨਾਲ ਕੀਤਾ ਸੰਪਾਦਨ ਮਿਟਾ ਦੇਵੇਗਾ।
client-to-client ਇੱਕ ਵੱਖਰਾ ਦਰਵਾਜ਼ਾ ਹੈ
ਇੱਕੋ ਸਬਨੈੱਟ ਦੇ ਅੰਦਰ ਵੀ ਸਰਵਰ ਉਹ ਪੈਕਟ ਸੁੱਟ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ ਕਲਾਇੰਟ ਤੋਂ ਆਉਂਦੇ ਹਨ ਅਤੇ ਦੂਜੇ ਲਈ ਸੰਬੋਧਿਤ ਹਨ, ਜਦ ਤੱਕ client-to-client ਸੈੱਟ ਨਹੀਂ ਹੁੰਦਾ। ਉਹ ਕੀਵਰਡ ਸਰਵਰ ਨੂੰ ਸਿਰਫ਼ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੇ ਅੰਤ ਬਿੰਦੂ ਦੀ ਥਾਂ ਸਹਿਯੋਗੀ ਟ੍ਰੈਫ਼ਿਕ ਦਾ ਅੱਗੇ ਭੇਜਣ ਵਾਲਾ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਟੋਪੋਲੋਜੀ ਠੀਕ ਕਰਨ ਤੋਂ ਬਾਅਦ ਲੋਕ ਜੋ ਦੂਜੀ ਸ਼ਰਤ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਉਹ ਇਹੀ ਹੈ।
ਇਹ broadcast ਤੱਕ ਨਹੀਂ ਫੈਲਦਾ। ਇਹ ਸੈਟਿੰਗ ਕਲਾਇੰਟਾਂ ਵਿਚਕਾਰ unicast ਅੱਗੇ ਭੇਜਦੀ ਹੈ; ਇਹ ਟਨਲ ਨੂੰ ਸਾਂਝਾ ਖੰਡ ਨਹੀਂ ਬਣਾਉਂਦੀ, ਅਤੇ ਇਸਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ multicast ਖੋਜ ਸਵਾਲ ਹਰ ਸਹਿਯੋਗੀ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਾਏਗੀ।
TUN ਬਨਾਮ TAP, ਅਤੇ ਹਰ ਇੱਕ ਕੀ ਵਹਾ ਸਕਦਾ ਹੈ
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
tap ਜੰਤਰ ਨੂੰ LAN ਵਿੱਚ ਬ੍ਰਿਜ ਕਰਨ ਨਾਲ ਦੂਰਲੇ ਕਲਾਇੰਟ ਦਫ਼ਤਰ ਦੇ broadcast ਡੋਮੇਨ ਵਿੱਚ ਆ ਜਾਂਦੇ ਹਨ, ਜੋ ਖੋਜ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਦਾ ਹੈ। ਕੀਮਤ ਉਹ ਪਲੇਟਫ਼ਾਰਮ ਹਨ ਜੋ TAP ਲਾਗੂ ਨਹੀਂ ਕਰਦੇ, ਸਰਵਰ ਉੱਤੇ ਹੋਣਾ ਲਾਜ਼ਮੀ ਬ੍ਰਿਜ, ਅਤੇ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਖੇਤਰ ਜਿੱਥੇ ਦਫ਼ਤਰ ਦੀ ਤਾਰ ਉੱਤੇ broadcast ਤੂਫ਼ਾਨ ਹਰ ਦੂਰਲੇ ਲੈਪਟਾਪ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ।
ਨਾਮ ਹੱਲ ਚਾਹੁਣ ਵਾਲੇ ਦੋ ਜਾਂ ਤਿੰਨ ਵਰਕਸਟੇਸ਼ਨਾਂ ਲਈ hosts ਐਂਟਰੀ ਜਾਂ unicast ਪਤਾ ਬ੍ਰਿਜ ਨਾਲੋਂ ਬਹੁਤ ਸਸਤਾ ਹੈ। TAP ਵੱਲ ਤਦੋਂ ਹੀ ਵਧੋ ਜਦੋਂ ਤੁਸੀਂ ਬਦਲ ਨਹੀਂ ਸਕਦੇ ਉਹ ਪਰੋਟੋਕੋਲ 2 ਪਰਤ ਦੀ ਖੋਜ ਉੱਤੇ ਨਿਰਭਰ ਹੋਵੇ, ਅਤੇ ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਨਹੀਂ।
ਬ੍ਰਿਜ ਤੋਂ ਬਿਨਾਂ ਇੱਕੋ ਸਬਨੈੱਟ ਦੇ ਕਲਾਇੰਟ
LAN ਰੇਂਜ ਵਿੱਚੋਂ ਪਤਾ ਦੇਣਾ ਕਲਾਇੰਟ ਨੂੰ ਤਾਰ ਉੱਤੇ ਨਹੀਂ ਬਿਠਾਉਂਦਾ। ਸਰਵਰ ਟਨਲ ਅਤੇ ਈਥਰਨੈੱਟ ਵਿਚਕਾਰ ਰਸਤਾ ਬਣਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਉਸ ਪਤੇ ਲਈ ARP ਸਰਵਰ ਦੇ ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਰੁਕ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬਾਕੀ LAN ਨੂੰ ਕਦੇ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਉਹ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ।
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP ਉਹ ਖਾਲੀ ਥਾਂ ਬੰਦ ਕਰਦਾ ਹੈ, ਸਰਵਰ ਕਲਾਇੰਟ ਵੱਲੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਰੇਂਜ ਲਈ parpd ਐਂਟਰੀਆਂ ਸੰਭਾਲਦਾ ਹੈ ਜਦੋਂ ਕਲਾਇੰਟ ਆਉਂਦੇ-ਜਾਂਦੇ ਹਨ, ਜਦੋਂ ਕਿ sysctl net.ipv4.conf.eth0.proxy_arp=1 ਹਰ ਉਸ ਚੀਜ਼ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜੋ ਕਿਤੇ ਹੋਰ ਰਸਤਾ ਲੈਂਦੀ ਹੈ, ਜੋ ਰੁੱਝੇ ਖੰਡ ਉੱਤੇ ਆਪਣੇ ਹੀ ਹੈਰਾਨੀ ਪੈਦਾ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਚੌੜਾ ਹੈ।
ਤੁਸੀਂ ਜੋ ਵੀ ਰਸਤਾ ਚੁਣੋ, ਟਨਲ ਅਤੇ ਤਾਰ ਵਿਚਕਾਰੋਂ NAT ਹਟਾਓ। MASQUERADE ਨਿਯਮ ਠੀਕ ਉਹੀ ਪਤਾ-ਨਿਰਧਾਰਣ ਸਵਾਲ ਲੁਕਾਉਂਦਾ ਹੈ ਜਿਸਦਾ ਤੁਸੀਂ ਜਵਾਬ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਇਹ ਅਗਲੇ ਬੰਦੇ ਲਈ ਅਜਿਹੀ ਟੋਪੋਲੋਜੀ ਵੀ ਛੱਡਦਾ ਹੈ ਜਿਸ ਬਾਰੇ ਉਹ ਕਲਾਇੰਟ ਪਾਸਿਓਂ ਸੋਚ ਹੀ ਨਹੀਂ ਸਕਦਾ।
ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਉੱਤੇ tcpdump -ni tun0 ਨਾਲ ਇੱਕ ਕੋਸ਼ਿਸ਼ ਫੜੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਸਹਿਯੋਗੀ ਪੈਕਟ ਆਉਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਆ ਕੇ ਸੁੱਟਿਆ ਜਾਣਾ client-to-client ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ; ਕਦੇ ਨਾ ਆਉਣਾ ਟੋਪੋਲੋਜੀ ਜਾਂ ਰਸਤਾ-ਨਿਰਧਾਰਣ ਵੱਲ। OpenVPN 2.6 ਦਸਤਾਵੇਜ਼ ਦੋਵੇਂ ਕੀਵਰਡ ਅਤੇ ਡਿਫ਼ਾਲਟ ਟੋਪੋਲੋਜੀ ਦਰਜ ਕਰਦਾ ਹੈ, ਅਤੇ ਫੋਰਮ ਪੋਸਟ ਤੋਂ ਲਾਈਨ ਕਾਪੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਸੰਸਕਰਣ ਨਾਲ ਮਿਲਾਉਣਾ ਢੁੱਕਵਾਂ ਹੈ।
- tun ਇੰਟਰਫ਼ੇਸ /30 ਸਹਿਯੋਗੀ ਜੋੜੀ ਦੀ ਥਾਂ ਪੂਲ ਮਾਸਕ ਦਿਖਾਉਂਦਾ ਹੈ।
- ਖੋਜ ਜਾਂਚਣ ਤੋਂ ਪਹਿਲਾਂ ਦੂਜੇ ਟਨਲ ਪਤੇ ਉੱਤੇ ਸਿੱਧਾ ping ਸਫਲ ਹੁੰਦਾ ਹੈ।
- ਜਦੋਂ ਵੀ ਸਹਿਯੋਗੀਆਂ ਨੂੰ ਪੈਕਟ ਬਦਲਣੇ ਹੁੰਦੇ ਹਨ, ਸਰਵਰ ਸੰਰਚਨਾ ਵਿੱਚ
client-to-clientਹੁੰਦਾ ਹੈ। - ਐਪ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ ਕਹਿਣ ਦੀ ਥਾਂ ਉਸ ਖੋਜ ਪਰੋਟੋਕੋਲ ਦਾ ਨਾਮ ਦੱਸੋ ਜੋ ਤੁਸੀਂ ਜਾਂਚ ਰਹੇ ਹੋ।
- TAP ਤਦੋਂ ਹੀ ਵਰਤੋ ਜਦੋਂ ਸਮੂਹ ਦਾ ਹਰ ਕਲਾਇੰਟ ਪਲੇਟਫ਼ਾਰਮ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੋਵੇ।
- ਇੱਕੋ ਸਬਨੈੱਟ ਅੰਦਰ ਪਹੁੰਚ ਮਹੱਤਵਪੂਰਨ ਹੋਣ ’ਤੇ NAT ਨੂੰ ਟਨਲ ਅਤੇ LAN ਵਿਚਕਾਰਲੇ ਰਸਤੇ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।