ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਇੱਕੋ ਸਬਨੈੱਟ: ਦੂਰ ਦੇ LAN ਨੂੰ ਖੁੱਲ੍ਹੀ ਰੇਂਜ 'ਤੇ ਮੈਪ ਕਰੋ
ਕਲਾਇੰਟ-ਪਾਸੇ ਪਤਾ ਮੈਪਿੰਗ ਓਵਰਲੈਪ ਹੁੰਦੇ ਦੂਰ ਦੇ LAN ਨੂੰ ਖੁੱਲ੍ਹੀ ਰੇਂਜ ਹੇਠ ਪੇਸ਼ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਸਿਰਫ਼ ਕੁਝ ਕਲਾਇੰਟ ਇਸਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ ਅਤੇ ਵਾਪਸੀ ਮਾਰਗ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਘਰ ਅਤੇ ਦਫ਼ਤਰ ਦੋਵੇਂ 192.168.1.0/24 ਵਰਤਦੇ ਹਨ, ਇਸ ਲਈ 192.168.1.1 'ਤੇ ਬੇਨਤੀ ਦੇ ਦੋ ਸੰਭਾਵਿਤ ਜਵਾਬ ਹਨ ਅਤੇ ਕਲਾਇੰਟ ਬਿਨਾਂ ਪੁੱਛੇ ਇੱਕ ਚੁਣਦਾ ਹੈ। ਚੱਲਦੇ ਦਫ਼ਤਰ ਦੇ ਨੈੱਟਵਰਕ ਨੂੰ ਦੁਬਾਰਾ ਨੰਬਰ ਕਰਨਾ ਘੱਟ ਹੀ ਪ੍ਰਸਿੱਧ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਰਾਊਟਰ ਦੇ ਪਤੇ ਅਕਸਰ ਪ੍ਰਿੰਟਰਾਂ, ਕੈਮਰਿਆਂ ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਧਸੇ ਹੁੰਦੇ ਹਨ। ਕਲਾਇੰਟ-ਪਾਸੇ ਪਤਾ ਮੈਪਿੰਗ ਇਸ ਦੀ ਥਾਂ ਦੂਰ ਦੇ ਨੈੱਟਵਰਕ ਨੂੰ ਖੁੱਲ੍ਹੀ ਰੇਂਜ ਹੇਠ ਪੇਸ਼ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਹੋਸਟ ਭਾਗ ਉਹੀ ਰਹਿ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ 192.168.1.20 10.203.41.20 ਵਜੋਂ ਦਿਸੇ। ਮੁਸ਼ਕਲ ਇਹ ਹੈ ਕਿ ਸਿਰਫ਼ ਕੁਝ ਕਲਾਇੰਟ ਇਸਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਵਾਪਸੀ ਮਾਰਗ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦੀ।
ਇੱਕੋ ਹੋਸਟ ਦੇ ਦੋ ਦ੍ਰਿਸ਼
ਮੈਪਿੰਗ ਹੋਸਟ ਭਾਗ ਰੱਖਦੀ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਨੈੱਟਵਰਕ ਭਾਗ ਬਦਲਦੀ ਹੈ। ਫਿਰ ਉਹੀ ਮਸ਼ੀਨ ਤੁਸੀਂ ਕਿੱਥੇ ਖੜ੍ਹੇ ਹੋ ਇਸ ਦੇ ਅਨੁਸਾਰ ਦੋ ਪਤਿਆਂ 'ਤੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਕੁਝ ਵੀ ਸੰਰਚਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਕਾਲਮ ਲਿਖ ਲੈਣ ਨਾਲ ਬਾਅਦ ਵਿੱਚ ਲੌਗ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਗਲਤ ਪੜ੍ਹਨ ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ।
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.20 |
ਘਰ ਦੇ ਸਥਾਨਕ ਯੰਤਰ ਆਪਣੇ 192.168.1.x ਪਤੇ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਇਹੀ ਇਸ ਅਭਿਆਸ ਦਾ ਮਕਸਦ ਹੈ। ਅਗਲੇ ਕਮਰੇ ਦਾ ਪ੍ਰਿੰਟਰ ਪਹੁੰਚ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦਫ਼ਤਰ ਅਜਿਹੀ ਰੇਂਜ ਹੇਠ ਦਿਸਦਾ ਹੈ ਜੋ ਟਕਰਾਉਂਦੀ ਨਹੀਂ।
ਆਰਗਿਊਮੈਂਟਾਂ ਦਾ ਕ੍ਰਮ ਹੀ ਪੂਰੀ ਚਾਲ ਹੈ
ਇਹ ਵਿਕਲਪ ਦਿਸ਼ਾ, ਨੈੱਟਵਰਕ ਅਤੇ ਮਾਸਕ, ਅਤੇ ਇੱਕ ਉਪਨਾਮ ਲੈਂਦਾ ਹੈ: ਪਹਿਲਾ ਨੈੱਟਵਰਕ ਉਹ ਹੈ ਜੋ ਕਲਾਇੰਟ ਦੇਖਦਾ ਹੈ, ਉਪਨਾਮ ਉਹ ਹੈ ਜੋ ਸਰਵਰ ਦੇਖਦਾ ਹੈ। ਦੂਰ ਦੇ ਗੇਟਵੇ ਪਿੱਛੇ ਰਹਿੰਦੇ ਸਰੋਤਾਂ ਲਈ ਦਿਸ਼ਾ ਮੰਜ਼ਿਲ ਦਾ ਰੂਪ ਹੁੰਦੀ ਹੈ। ਆਖਰੀ ਆਰਗਿਊਮੈਂਟ ਨੂੰ ਉਪਨਾਮ ਕਹਿਣ ਕਰਕੇ ਦੋਵੇਂ ਨੈੱਟਵਰਕ ਉਲਟ ਦੇਣਾ ਉਹ ਗਲਤੀ ਹੈ ਜੋ ਜੁੜਦਾ ਪਰ ਕੁਝ ਵੀ ਮੈਪ ਨਾ ਕਰਨ ਵਾਲਾ ਟਨਲ ਬਣਾਉਂਦੀ ਹੈ।
push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"
ਨਵੀਂ ਰੇਂਜ ਲਈ ਕਲਾਇੰਟ ਦੇ ਪੈਕਟ ਟਨਲ ਵਿੱਚ ਭੇਜਣ ਵਾਲਾ ਰੂਟ ਹੈ; ਅਨੁਵਾਦ ਰਾਹ ਵਿੱਚ ਮੰਜ਼ਿਲ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ। 192.168.1.20 ਤੋਂ ਜਵਾਬ 10.203.41.20 'ਤੇ ਵਾਪਸ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਦਾ ਸਾਕਟ ਸੁਸੰਗਤ ਰਹੇ। ਇੱਕੋ ਹੋਸਟ ਪੂਰੀ ਲੰਬਾਈ ਦੇ ਮਾਸਕ ਨਾਲ ਇਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿੰਨਾ ਚਿਰ ਰੂਟ ਅਤੇ ਮੈਪਿੰਗ ਇੱਕੋ ਪਤਾ ਦੱਸਦੇ ਹਨ।
ਇਹ ਪਤਾ ਮੈਪਿੰਗ ਹੈ, ਪੋਰਟ ਮੈਪਿੰਗ ਨਹੀਂ। ਇੱਕ ਹੋਸਟ 'ਤੇ ਦੋ ਸੇਵਾਵਾਂ ਇਸ ਨਾਲ ਵੱਖ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ, ਅਤੇ ਜੋ ਪ੍ਰੋਟੋਕਾਲ ਆਪਣੇ ਪੇਲੋਡ ਵਿੱਚ IP ਪਤੇ ਧਸਾਉਂਦਾ ਹੈ ਉਹ ਫਿਰ ਵੀ ਅਸਲੀ ਦੇਖੇਗਾ।
ਮੈਪਿੰਗ ਵਾਪਸੀ ਮਾਰਗ ਨਹੀਂ ਬਣਾਉਂਦੀ
ਅਨੁਵਾਦ ਕਲਾਇੰਟ 'ਤੇ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਰਵਰ ਨੂੰ ਅਜੇ ਵੀ ਜਵਾਬ ਟਨਲ ਵਿੱਚ ਰੂਟ ਕਰਨੇ ਪੈਂਦੇ ਹਨ ਅਤੇ ਇਸ ਦੇ ਫਾਇਰਵਾਲ ਨੂੰ ਅਜੇ ਵੀ ਉਨ੍ਹਾਂ ਦੀ ਆਗਿਆ ਦੇਣੀ ਪੈਂਦੀ ਹੈ। ਜੇ ਦੂਰ ਦੇ ਗੇਟਵੇ ਨੂੰ ਪਤਾ ਨਾ ਹੋਵੇ ਕਿ ਟਨਲ ਦੇ ਸਬਨੈੱਟ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਣਾ ਹੈ, ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ ਅਤੇ ਜਵਾਬ ਗਲਤ ਦਰਵਾਜ਼ੇ ਰਾਹੀਂ ਨਿਕਲ ਜਾਂਦਾ ਹੈ; ਮੈਪਿੰਗ ਸਿਰਫ਼ ਅਸਫਲਤਾ ਨੂੰ ਕਲਾਇੰਟ ਦੀ ਸਮੱਸਿਆ ਵਰਗਾ ਦਿਖਾਉਂਦੀ ਹੈ।
ਸਰਵਰ-ਪਾਸੇ ਨਿਯਮਾਂ ਨੂੰ ਅਨੁਵਾਦ ਤੋਂ ਬਾਅਦ ਸਰਵਰ 'ਤੇ ਮੌਜੂਦ ਪਤਿਆਂ ਦਾ ਵਰਣਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਲਾਇੰਟ ਨੂੰ ਦਿਸਦੀ ਰੇਂਜ ਦਾ ਨਹੀਂ। ਉਪਨਾਮ ਨੂੰ ਆਗਿਆ ਨਿਯਮ ਵਿੱਚ ਕਾਪੀ ਕਰਨਾ ਇੱਕ ਦੁਪਹਿਰ ਬਰਬਾਦ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਸ ਪਾਸੇ ਦਾ ਕੋਈ ਪੈਕਟ ਇਸਨੂੰ ਨਹੀਂ ਢੋਂਦਾ।
ਅਜਿਹੀ ਉਪਨਾਮ ਰੇਂਜ ਚੁਣੋ ਜੋ ਕਲਾਇੰਟ ਦੁਆਰਾ ਰੂਟ ਕੀਤੀ ਹੋਰ ਕਿਸੇ ਚੀਜ਼ ਨਾਲ ਨਾ ਟਕਰਾਏ: ਦੂਜਾ VPN, ਕੰਟੇਨਰ ਨੈੱਟਵਰਕ, ਦੂਜਾ ਦਫ਼ਤਰ। ਇੱਥੇ ਟਕਰਾਅ ਮੂਲ ਅਸਪਸ਼ਟਤਾ ਨੂੰ ਵੱਖਰੇ ਨੰਬਰ ਹੇਠ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ ਅਤੇ ਪਤੇ ਅਣਜਾਣ ਲੱਗਣ ਕਰਕੇ ਵੇਖਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ।
ਨਾਮ ਅਤੇ ਪੇਲੋਡ ਅਨੁਵਾਦ ਵਿੱਚੋਂ ਬਚ ਨਿਕਲਦੇ ਹਨ
ਅਸਲੀ 192.168.1.20 'ਤੇ ਰਿਜ਼ੌਲਵ ਹੁੰਦਾ ਹੋਸਟਨਾਮ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਦੂਰ ਵਾਲੇ ਦੀ ਥਾਂ ਸਥਾਨਕ ਯੰਤਰ 'ਤੇ ਭੇਜਦਾ ਹੈ, ਰੂਟਿੰਗ ਟੇਬਲ ਕੁਝ ਵੀ ਕਹੇ। ਨਿੱਜੀ DNS ਦਾ ਜਵਾਬ ਕਲਾਇੰਟ ਨੂੰ ਦਿਸਦੀ ਰੇਂਜ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਦੋਂ ਕਿ TLS ਸਰਟੀਫਿਕੇਟ ਅਜੇ ਵੀ ਉਹ ਨਾਮ ਰੱਖਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਉਮੀਦ ਹੈ। ਪਤੇ ਦੀ ਥਾਂ ਨਾਮ ਨਾਲ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਪਤਾ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਨਾਮ ਚੁੱਪਚਾਪ ਗਲਤ ਦਿਸ਼ਾ ਵਿੱਚ ਰਿਜ਼ੌਲਵ ਹੁੰਦਾ ਹੈ। ਜੇ ਦੂਰ ਦਾ ਗੇਟਵੇ ਉਸ ਜ਼ੋਨ ਦੀ ਸੇਵਾ ਵੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸ ਦੇ ਆਪਣੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਵੀ ਕਲਾਇੰਟ ਨੂੰ ਦਿਸਦੀ ਰੇਂਜ ਚਾਹੀਦੀ ਹੈ।
ਰੀਡਾਇਰੈਕਟ, ਐਂਬੈਡਡ URL ਅਤੇ ਆਪਣਾ ਪਤਾ ਪੇਲੋਡ ਵਿੱਚ ਦੇਣ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਜਿਹੇ ਤਰੀਕਿਆਂ ਨਾਲ ਟੁੱਟ ਸਕਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੋਈ ਪੈਕਟ ਮੈਪਿੰਗ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਇਨ੍ਹਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਮੰਨੋ ਅਤੇ ਦੁਬਾਰਾ ਨੰਬਰ ਕਰਨ ਦੀ ਲੋੜ ਨਾ ਹੋਣ ਦਾ ਵਾਅਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਯਤਨ ਉਸੇ ਤਰ੍ਹਾਂ ਮਾਪੋ।
ਪ੍ਰਤੀਬੱਧ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਜਾਂਚਾਂ
ਪਹਿਲਾਂ, ਕਲਾਇੰਟ ਦੇ ਅਮਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। Community OpenVPN ਇਸ ਵਿਕਲਪ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ; OpenVPN 3 ਕੋਡਬੇਸ ਇਸਨੂੰ ਅਸਮਰਥਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਗਿਣਦਾ ਹੈ, ਇਸ ਲਈ Connect ਸ਼ੈਲੀ ਦੇ ਕਲਾਇੰਟ ਵੱਲ ਧੱਕੀ ਪ੍ਰੋਫਾਈਲ ਇਸਨੂੰ ਬਸ ਅਣਡਿੱਠ ਕਰ ਸਕਦੀ ਹੈ। ਸਵੀਕਾਰਿਆ ਪਰ ਕਦੇ ਲਾਗੂ ਨਾ ਹੋਣ ਵਾਲਾ ਨਿਰਦੇਸ਼ ਗਲਤੀ ਤੋਂ ਵੀ ਮਾੜਾ ਹੈ, ਕਿਉਂਕਿ ਟਨਲ ਸਿਹਤਮੰਦ ਦਿਸਦਾ ਹੈ।
ਦੂਜਾ, ਉੱਚ ਤਫ਼ਸੀਲ 'ਤੇ ਛੋਟੀ ਡਾਇਗਨੋਸਟਿਕ ਵਿੰਡੋ ਨਾਲ ਰੂਟ ਅਤੇ ਅਨੁਵਾਦ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ, ਫਿਰ ping ਦੀ ਥਾਂ ਅਸਲ ਸੇਵਾ ਦੀ ਪਰਖ ਕਰੋ। ਤੀਜਾ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਥਾਨਕ ਰਾਊਟਰ ਅਤੇ ਦੂਰ ਦਾ ਸਰੋਤ ਕਲਾਇੰਟ ਤੋਂ ਵੱਖ ਪਛਾਣੇ ਜਾ ਸਕਦੇ ਰਹਿੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਹੀ ਮੂਲ ਟੀਚਾ ਸੀ।
ਜੇ ਕਲਾਇੰਟ ਅਨੁਵਾਦ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਗੇਟਵੇ ਪਾਸਿਓਂ ਮਦਦ ਮੰਗੋ ਜਾਂ ਦੁਬਾਰਾ ਨੰਬਰ ਕਰਨਾ ਸਵੀਕਾਰ ਕਰੋ। ਇੱਕੋ ਪਤੇ ਲਈ ਹੋਰ ਰੂਟ ਜੋੜਨਾ ਕੋਈ ਡਿਜ਼ਾਈਨ ਨਹੀਂ।