Minecraft VPN ਰਾਹੀਂ: ਸਰਵਰ ਸੂਚੀ ਵਿੱਚ ਕਿਹੜਾ ਪਤਾ ਜਾਂਦਾ ਹੈ?
VPN ਅੰਤ ਬਿੰਦੂ ਸੁਰੰਗ ਬਣਾਉਂਦਾ ਹੈ; ਖੇਡ ਨੂੰ ਹੋਸਟ ਦਾ ਨਿੱਜੀ ਪਤਾ ਅਤੇ ਪੋਰਟ ਚਾਹੀਦਾ ਹੈ। ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਪਤਿਆਂ ਨਾਲ ਜੋੜੋ, ਫਿਰ ਸਰੋਤਾ, ਮਾਰਗ ਅਤੇ ਹੋਸਟ ਨਿਯਮ ਜਾਂਚੋ।
Minecraft ਦੀ ਸਰਵਰ ਸੂਚੀ ਵਿੱਚ VPN ਅੰਤ ਬਿੰਦੂ ਲਿਖਣਾ ਤਰਕਸੰਗਤ ਲੱਗਦਾ ਹੈ ਅਤੇ ਹਰ ਵਾਰ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਪਤਾ ਸੁਰੰਗ ਖਤਮ ਕਰਦਾ ਹੈ, ਖੇਡ ਨੂੰ ਹੋਸਟ ਨਹੀਂ ਕਰਦਾ। ਉਸੇ VPN ਨਾਲ ਜੁੜੇ ਖਿਡਾਰੀ ਕੋਲ ਖੇਡ ਦੇ ਹੋਸਟ ਤੱਕ ਪਹਿਲਾਂ ਹੀ ਮਾਰਗ ਹੈ, ਇਸ ਲਈ ਐਂਟਰੀ ਨੂੰ ਹੋਸਟ ਅਤੇ ਉਹ ਪੋਰਟ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਖੇਡ ਸੁਣਦੀ ਹੈ। ਇਹ ਦੋਵੇਂ ਸਹੀ ਕਰ ਲਵੋ ਅਤੇ ਬਾਕੀ ਸਮੱਸਿਆ ਆਮ ਸੇਵਾ-ਪਹੁੰਚ ਹੈ, ਜੋ ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ ਲੱਗਣ ਨਾਲੋਂ ਬਹੁਤ ਛੋਟੀ ਜਾਂਚ ਸੂਚੀ ਹੈ।
ਦੋ ਪਤੇ, ਦੋ ਕੰਮ
ਇੱਕ ਪਤਾ ਜਨਤਕ ਢਾਂਚਾ ਹੈ: ਸਾਥੀਆਂ ਵਿਚਕਾਰ ਐਨਕ੍ਰਿਪਟਿਡ ਪੈਕਟ ਲੈ ਜਾਣ ਵਾਲਾ ਟਰਾਂਸਪੋਰਟ ਅੰਤ ਬਿੰਦੂ। ਦੂਜਾ ਸਮਰਪਿਤ ਸਰਵਰ ਚਲਾਉਣ ਵਾਲੀ ਮਸ਼ੀਨ ਦਾ ਨਿੱਜੀ ਪਤਾ ਹੈ। ਇਹ ਆਪਸ ਵਿੱਚ ਬਦਲੇ ਨਹੀਂ ਜਾ ਸਕਦੇ, ਅਤੇ ਇੱਕ ਨੂੰ ਦੂਜੇ ਨਾਲ ਬਦਲਣ ਨਾਲ ਕਨੈਕਸ਼ਨ ਰੱਦ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਫਾਇਰਵਾਲ ਸਮੱਸਿਆ ਵਰਗਾ ਦਿਖਣ ਵਾਲਾ ਸਮਾਂ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।
| Role | Address | Where it belongs |
|---|---|---|
| Public transport endpoint | 203.0.113.40 | VPN client configuration, never the game |
| Game host on the VPN | 10.60.0.20 | Server address field, with the port |
| Player peer | 10.60.0.30 | Assigned by the tunnel, nothing to type |
ਡਿਫਾਲਟ ਪੋਰਟ ਨਾਲ, ਖਿਡਾਰੀ 10.60.0.20:25565 ਲਿਖਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। Mojang ਦਾ Java ਸਰਵਰ ਡਾਊਨਲੋਡ ਪੇਜ 25565 ਨੂੰ ਡਿਫਾਲਟ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਪੋਰਟ ਬਦਲਣ ਵਾਲੇ ਸਰਵਰ ਆਪਰੇਟਰ 'ਤੇ ਪੁਰਾਣੇ ਟਿਊਟੋਰਿਅਲ ਤੋਂ ਸ਼ੱਕ ਕਰਨ ਦੀ ਬਜਾਏ ਭਰੋਸਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਉਸ ਪਤੇ ਨੂੰ ਸੱਚੀ ਸੇਵਾ ਬਣਾਓ
ਪਹੁੰਚਯੋਗ ਪਤਾ ਜ਼ਰੂਰੀ ਹੈ ਅਤੇ ਕਾਫੀ ਨਹੀਂ। ਸਮਰਪਿਤ ਸਰਵਰ ਚੱਲ ਰਿਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਖਿਡਾਰੀ ਦੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਚਲਾਈ ਜਾ ਰਹੀ ਵਰਜ਼ਨ ਨਾਲ ਅਨੁਕੂਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਸ ਪਤੇ 'ਤੇ ਸੁਣਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਸੁਰੰਗ ਪਹੁੰਚਾ ਸਕੇ। ਸਿਰਫ਼ loopback ਨਾਲ ਬੱਝੀ ਪ੍ਰਕਿਰਿਆ ਇਸ ਲਈ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੋ ਜਾਂਦੀ ਕਿ ਕਿਸੇ ਨੇ ਮਸ਼ੀਨ ਵਿੱਚ ਦੂਜਾ ਪਤਾ ਜੋੜ ਦਿੱਤਾ।
ਫਾਇਰਵਾਲ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤਾ ਪੱਕਾ ਕਰੋ:
ss -lntp | grep 25565
nc -vz 10.60.0.20 25565ਪਹਿਲੀ ਲਾਈਨ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਅਸਲ ਵਿੱਚ ਕਿਸ ਨਾਲ ਬੱਝੀ ਹੈ, ਅਤੇ ਦੂਜੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਸਾਥੀ TCP ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜਦੋਂ ਬੰਧਨ 127.0.0.1 ਹੁੰਦਾ ਹੈ, ਤਦ VPN ਸੰਰਚਨਾ ਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ ਨਤੀਜਾ ਨਹੀਂ ਬਦਲਦੀ, ਅਤੇ ਇਹ ਇੱਕੋ ਵੇਰਵਾ «VPN ਟੁੱਟ ਗਿਆ ਹੈ» ਵਰਗੀਆਂ ਹੈਰਾਨੀਜਨਕ ਗਿਣਤੀ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।
ਸਾਥੀ ਨੀਤੀ, ਫਾਇਰਵਾਲ ਅਤੇ ਵਾਪਸੀ ਮਾਰਗ
ਸਰੋਤੇ ਦੇ ਉੱਤੇ ਦੋ ਇਜਾਜ਼ਤ ਸਵਾਲ ਬੈਠੇ ਹਨ। VPN ਸਾਥੀ ਸੰਰਚਨਾ ਨੂੰ ਦੋਵਾਂ ਸਾਥੀਆਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਖੇਡ ਦੇ ਹੋਸਟ ਦੇ ਫਾਇਰਵਾਲ ਨੂੰ ਉਸ ਸਾਥੀ ਤੋਂ ਖੇਡ ਦਾ ਪੋਰਟ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਖੇਡ ਸੇਵਾ ਅਤੇ ਅਧਿਕਾਰਤ ਸਾਥੀਆਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ, ਹੋਸਟ ਦਾ ਫਾਇਰਵਾਲ ਬੰਦ ਕਰਨ ਦੀ ਬਜਾਏ, ਜੋ ਦੋ ਲਾਈਨਾਂ ਦੇ ਨਿਯਮ ਨੂੰ ਬਹੁਤ ਵੱਡੀ ਸਮੱਸਿਆ ਨਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਸੰਕਰੇ ਨਿਯਮ ਹੀ ਇਸਦਾ ਇੱਕੋ ਸੰਸਕਰਣ ਹਨ ਜੋ ਇੱਕ ਪੈਰੇ ਦੇ ਜਾਇਜ਼ੇ ਤੋਂ ਬਿਨਾਂ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆ ਪਾਰ ਕਰਦੇ ਹਨ।
ਫਿਰ ਯਾਦ ਰੱਖੋ ਕਿ ਸਫਲ ping ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ। VPN ਗੇਟਵੇ ਤੱਕ ਪਹੁੰਚਣਾ, ਜਾਂ ਖੇਡ ਦੇ ਹੋਸਟ ਤੋਂ ਜਵਾਬ ਮਿਲਣਾ, ਸਿਰਫ਼ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ICMP ਨੇ ਮਾਰਗ ਪਾਰ ਕੀਤਾ। ਖੇਡ ਕਨੈਕਸ਼ਨ ਲਈ ਖਾਸ ਪੋਰਟ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਖੁੱਲ੍ਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਵਾਪਸੀ ਮਾਰਗ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਮਾਰਗ ਜਿੰਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਜਦੋਂ ਸਰਵਰ ਗੇਟਵੇ ਪਿੱਛੇ ਹੋਵੇ
ਉੱਪਰਲੇ ਉਦਾਹਰਨ ਵਿੱਚ ਖੇਡ ਦਾ ਸਰਵਰ ਸਾਥੀ ਹੈ, ਜੋ ਪਤਾ ਯੋਜਨਾ ਨੂੰ ਸਰਲ ਰੱਖਦਾ ਹੈ। ਜੇ ਸਰਵਰ ਇਸ ਦੀ ਬਜਾਏ VPN ਗੇਟਵੇ ਪਿੱਛੇ ਕਿਸੇ LAN 'ਤੇ ਹੈ, ਤਾਂ ਖਿਡਾਰੀ ਨੂੰ ਸਰਵਰ ਦਾ ਰੂਟ ਕਰਨ ਯੋਗ ਨਿੱਜੀ ਪਤਾ ਚਾਹੀਦਾ ਹੈ, ਗੇਟਵੇ ਨੂੰ ਉਸ LAN ਲਈ ਫਾਰਵਰਡਿੰਗ ਸੰਰਚਿਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ LAN ਹੋਸਟ ਨੂੰ ਸੁਰੰਗ ਵਾਲੇ ਕਲਾਇੰਟ ਵੱਲ ਵਾਪਸੀ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ। ਵਾਪਸੀ ਮਾਰਗ ਖੁੱਟ ਗਿਆ ਤਾਂ ਹੈਂਡਸ਼ੇਕ ਅੱਧ ਵਿੱਚ ਮਰ ਜਾਂਦਾ ਹੈ, ਜੋ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਉਲਝਾਉਣ ਵਾਲੀ ਅਸਫਲਤਾ ਹੈ।
ਇਸ ਟੋਪੋਲੋਜੀ ਦੀ ਨਕਲ ਕਰਨ ਲਈ ਉਦਾਹਰਨ ਦਾ ਸਾਥੀ ਪਤਾ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ 'ਤੇ ਕਾਪੀ ਨਾ ਕਰੋ। ਉਦਾਹਰਨ ਵਿੱਚ ਪਤੇ ਭੂਮਿਕਾਵਾਂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਪਤਾ ਦੋ ਭੂਮਿਕਾਵਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਵਰਤਣ ਨਾਲ ਅਜਿਹਾ ਓਵਰਲੈਪ ਬਣਦਾ ਹੈ ਜਿਸ ਨੂੰ ਰੂਟਿੰਗ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦੀ।
ਖੋਜ, ਖਾਤੇ ਅਤੇ ਕੀ ਨਾ ਬਦਲੋ
ਆਪਣੇ-ਆਪ LAN ਖੋਜ ਘੋਸ਼ਣਾਵਾਂ 'ਤੇ ਬਣੀ ਸੁਵਿਧਾ ਹੈ। ਰੂਟ ਕੀਤੇ VPN ਨੂੰ ਉਹ ਬ੍ਰਾਡਕਾਸਟ ਲੈ ਜਾਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਇਸ ਲਈ LAN ਸੂਚੀ ਵਿੱਚ ਐਂਟਰੀ ਨਾ ਹੋਣਾ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਸਪਸ਼ਟ ਨਿੱਜੀ ਪਤਾ ਕੰਮ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਪਤਾ ਲਿਖੋ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ। ਜੇ ਜੁੜਦਾ ਹੈ, ਤਾਂ ਖੋਜ ਦਾ ਪਾੜਾ ਖਰਾਬੀ ਨਹੀਂ, ਵਰਤੋਂ ਦੀ ਅਸੁਵਿਧਾ ਹੈ, ਅਤੇ ਜਾਂਚ ਕਰਨ ਦੀ ਬਜਾਏ ਇਸ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਦਰਜ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਖੇਡ ਦੀ ਆਮ ਖਾਤਾ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਦਾਖਲਾ ਨੀਤੀ ਵੀ ਅਛੋਹ ਰੱਖੋ। ਕੰਮ ਕਰਨ ਵਾਲਾ ਨਿੱਜੀ ਮਾਰਗ ਮਾਰਗ ਦਿੰਦਾ ਹੈ, ਮੈਂਬਰਸ਼ਿਪ ਨਹੀਂ, ਅਤੇ ਐਡਾਪਟਰ ਤਰਜੀਹਾਂ ਦੀ ਕੋਈ ਵੀ ਮਿਲਾਵਟ ਕਲਾਇੰਟ ਵੱਲੋਂ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਮੰਜ਼ਿਲ ਦੀ ਪਛਾਣ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦੀ।