ਇੱਕ OpenVPN ਕਲਾਇੰਟ ’ਤੇ ਦੋ ਸੇਵਾ ਪਤੇ: iroute ਅਤੇ lo

ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੇ ਟਨਲ ਪਤੇ ’ਤੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਇਸ ਲਈ ਜੋ ਪਤਾ ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਹੈ ਉਹ ਕਿਤੇ ਨਹੀਂ ਜਾਂਦਾ। OpenVPN ਲਾਗ ਵਿੱਚ ਕੁਝ ਵੀ ਸ਼ਿਕਾਇਤ ਨਹੀਂ ਕਰਦਾ, ਪੀਅਰ ਜੁੜਿਆ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਹੱਬ ਠੀਕ ਇੱਕ ਕਲਾਇੰਟ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ। ਖਾਲੀ ਥਾਂ ਇਹ ਹੈ ਕਿ ਕਲਾਇੰਟ ’ਤੇ ਦੂਜਾ ਪਤਾ ਦੋ ਵੱਖਰੇ ਤੱਥ ਹਨ: ਹੋਸਟ ਨੂੰ ਇਸਦਾ ਮਾਲਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਹੱਬ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪੀਅਰ ਇਸਦਾ ਮਾਲਕ ਹੈ। ਇੱਕ ਨੂੰ ਦੂਜੇ ਤੋਂ ਬਿਨਾਂ ਸੰਭਾਲੋ ਤਾਂ ਟ੍ਰੈਫਿਕ ਜਾਂ ਤਾਂ ਹੱਬ ’ਤੇ ਮਰ ਜਾਂਦਾ ਹੈ ਜਾਂ ਘਰ ਦੇ ਮਾਰਗ ਤੋਂ ਬਿਨਾਂ ਪਹੁੰਚਦਾ ਹੈ।

ਉਪਨਾਮ ਸਥਾਨਕ ਹੈ, ਮਾਲਕੀ ਦੂਰ ਦੀ ਹੈ

ਟਨਲ ਪਤੇ ’ਤੇ ਗੱਲਬਾਤ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ ਦੋਵੇਂ ਸਿਰੇ ਇਸਨੂੰ ਸਿੱਖਦੇ ਹਨ। ਵਾਧੂ ਸੇਵਾ ਪਤੇ ’ਤੇ ਬਿਲਕੁਲ ਗੱਲਬਾਤ ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਲਈ ਇਸਨੂੰ ਜੋੜਨ ਨਾਲ ਹੱਬ ’ਤੇ ਆਪਣੇ ਆਪ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ। ਕਲਾਇੰਟ ਤੁਰੰਤ ਪਤੇ ਦਾ ਮਾਲਕ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਉਹ ਟ੍ਰੈਫਿਕ ਫਿਰ ਵੀ ਆਪਣੇ ਡਿਫਾਲਟ ਮਾਰਗ ’ਤੇ ਭੇਜੇਗਾ ਜਾਂ ਇਸਨੂੰ ਸੁੱਟ ਦੇਵੇਗਾ। ਦੋ ਰਿਕਾਰਡ, ਦੋ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ’ਤੇ ਬਣਾਉਣੇ ਪੈਣਗੇ।

ਕਲਾਇੰਟ ’ਤੇ ਪਤਾ ਹੋਸਟ ਦਾ ਹੈ, ਅਤੇ ਲੂਪਬੈਕ ਉਸ ਸੇਵਾ ਪਛਾਣ ਲਈ ਕੁਦਰਤੀ ਘਰ ਹੈ ਜੋ ਕਦੇ ਵੀ ਭੌਤਿਕ ਲਿੰਕ ’ਤੇ ਨਹੀਂ ਦਿਸਣੀ ਚਾਹੀਦੀ। ਹੱਬ ’ਤੇ ਪੀਅਰ-ਤੋਂ-ਪ੍ਰੀਫਿਕਸ ਮੈਪਿੰਗ ਇੱਕ ਵੱਖਰੀ ਘੋਸ਼ਣਾ ਹੈ ਜੋ ਸਿਰਫ ਸਰਵਰ ਪੜ੍ਹਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਰਿਕਾਰਡ ਦੂਜੇ ਨੂੰ ਨਹੀਂ ਦਰਸਾਉਂਦਾ।

ਆਪਣੇ ਨੋਟਸ ਵਿੱਚ ਵੀ ਦੋਵੇਂ ਰੇਂਜਾਂ ਵੱਖਰੀਆਂ ਰੱਖੋ। ਉਦਾਹਰਨ ਦੇ ਪਤੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਮੁੱਲ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਅਸਲ LAN ਨਾਲ ਓਵਰਲੈਪ ਕਰਨਾ ਕੰਮ ਕਰਦੇ ਸੈਟਅਪ ਨੂੰ ਟੁੱਟਿਆ ਦਿਖਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ।

ਕਲਾਇੰਟ ’ਤੇ ਪਤਾ ਸਥਾਈ ਤੌਰ ’ਤੇ ਜੋੜੋ

ਸੇਵਾ ਪਤੇ ਨੂੰ ਹੋਸਟ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਲੂਪਬੈਕ ’ਤੇ ਰੱਖੋ, ਤਾਂ ਜੋ ਹੋਸਟ ਇਸਨੂੰ ਪਹੁੰਚਣ ਵਾਲੇ ਸਬਨੈਟ ਵਜੋਂ ਨਹੀਂ ਬਲਕਿ ਸਥਾਨਕ ਇਨਪੁਟ ਵਜੋਂ ਲਵੇ। ip address add 10.66.0.10/32 dev lo ਇੱਕ ਪਤੇ ਲਈ ਇਹ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੂਜੇ ਪਤੇ ਲਈ ਕਮਾਂਡ ਦੁਹਰਾਉਣਾ ਦੋ ਸੇਵਾਵਾਂ ਨੂੰ ਮਾਡਲ ਕਰਦਾ ਹੈ।

ਇਸਨੂੰ ਇੱਕ ਵਾਰੀ ਪਰੀਖਿਆ ਵਜੋਂ ਚਲਾਓ, ਫਿਰ ਇਸਨੂੰ ਉਸ ਵਿੱਚ ਲੈ ਜਾਓ ਜੋ ਹੋਸਟ ਦੀ ਨੈੱਟਵਰਕ ਕਨਫਿਗਰੇਸ਼ਨ ਦਾ ਮਾਲਕ ਹੈ, ਕਿਉਂਕਿ ਰਨਟਾਈਮ ਜੋੜ ਰੀਬੂਟ ’ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮੁੜ ਜੁੜਨ ਦਰਮਿਆਨ ਨਕਲਾਂ ਇਕੱਠੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਅਦ ਕ੍ਰਮਬੱਧ systemd ਯੂਨਿਟ ਇੱਕ ਵਿਕਲਪ ਹੈ, ਅਤੇ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਦੂਜਾ। ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਬਾਈਂਡ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਸੇਵਾ ਗਲਤ ਸਾਕਟ ’ਤੇ ਉੱਠਦੀ ਹੈ। ਮੈਨੁਅਲ ਕਮਾਂਡ ਤੋਂ ਬਾਅਦ ਨਹੀਂ, ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ip address show dev lo ਨਾਲ ਜਾਂਚੋ।

ਬਾਈਂਡਿੰਗ ਐਡਰੈਸਿੰਗ ਤੋਂ ਵੱਖਰਾ ਫੈਸਲਾ ਹੈ। ਹਰ ਪਤੇ ’ਤੇ ਸੁਣਨ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਉਨ੍ਹਾਂ ਇੰਟਰਫੇਸਾਂ ’ਤੇ ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਤੁਸੀਂ ਕਦੇ ਇਰਾਦਾ ਨਹੀਂ ਸੀ, ਇਸ ਲਈ ਇਸਨੂੰ ਖਾਸ ਸੇਵਾ ਪਤੇ ਵੱਲ ਨਿਰਦੇਸ਼ਿਤ ਕਰੋ। ਫਿਰ ਸਥਾਨਕ ਇਨਪੁਟ ਨੀਤੀ ਕੋਲ ਠੀਕ ਮਿਲਾਉਣ ਲਈ ਕੁਝ ਹੁੰਦਾ ਹੈ।

ਹੱਬ ਜੋ CCD ਫਾਈਲ ਅਸਲ ਵਿੱਚ ਪੜ੍ਹਦਾ ਹੈ ਉਸ ਵਿੱਚ ਇਸਦਾ ਦਾਅਵਾ ਕਰੋ

ਸਰਵਰ ’ਤੇ ਮਾਲਕੀ ਦੀ ਘੋਸ਼ਣਾ ਪ੍ਰਮਾਣਿਤ ਆਮ ਨਾਮ ਦੁਆਰਾ ਚੁਣੀ ਗਈ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਫਾਈਲ ਵਿੱਚ ਜਾਂਦੀ ਹੈ, client-config-dir ਦੁਆਰਾ ਨਾਮਿਤ ਡਾਇਰੈਕਟਰੀ ਦੇ ਅੰਦਰ। ਲਾਈਨ iroute 10.66.0.10 255.255.255.255 ਹੈ, ਪ੍ਰਤੀ ਪਤਾ ਇੱਕ, ਅਤੇ ਇਹ ਸਰਵਰ ਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਉਸ ਮੰਜ਼ਿਲ ਲਈ ਕਿਹੜਾ ਪੀਅਰ ਟ੍ਰੈਫਿਕ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ।

ਦੋ ਵੇਰਵੇ ਇਸਨੂੰ ਚੁੱਪਚਾਪ ਤੋੜਦੇ ਹਨ। ਫਾਈਲ ਦਾ ਨਾਮ ਸਰਵਰ ਦੁਆਰਾ ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਨਾਮ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ username-as-common-name ਦੇ ਖੇਡ ਵਿੱਚ ਹੋਣ ’ਤੇ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ। ਅਤੇ iroute ਸਿਰਫ TUN ਮੋਡ ਵਿੱਚ ਕਲਾਇੰਟ ਕਨਫਿਗਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਕਨਫਿਗਰ ਹੋਣ ’ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਬ੍ਰਿਜਡ ਤੈਨਾਤੀ ਵਿੱਚ ਉਹੀ ਲਾਈਨ ਕੁਝ ਨਹੀਂ ਕਰਦੀ। ਮੌਜੂਦਾ ਫਾਈਲ ਵਿੱਚ ਲਾਈਨਾਂ ਜੋੜੋ, ਇਸਨੂੰ ਬਦਲੋ ਨਹੀਂ, ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਸਥਿਰ ਪਤਾ ਜਾਂ push ਵਿਕਲਪ ਹੋ ਸਕਦੇ ਹਨ। OpenVPN 2.6 ਸੰਦਰਭ ਡਾਇਰੈਕਟਰੀ ਅਤੇ ਮਾਲਕੀ ਨਿਰਦੇਸ਼ ਦੋਵਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ।

ਹੱਬ ਦੇ ਆਪਣੇ ਕਰਨਲ ਨੂੰ ਵੀ ਉਨ੍ਹਾਂ ਮੰਜ਼ਿਲਾਂ ਤੱਕ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਜੋ ਸਥਾਨਕ ਰੂਪ ਵਿੱਚ ਪੈਦਾ ਹੋਇਆ ਟ੍ਰੈਫਿਕ ਟਨਲ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਦਾਖਲ ਹੋਵੇ। ਸਰਵਰ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ route 10.66.0.10 255.255.255.255 ਸਰਵਰ ਦੁਆਰਾ ਖੁਦ ਪੈਦਾ ਕੀਤਾ ਟ੍ਰੈਫਿਕ ਕਵਰ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਹੋਰ ਕਲਾਇੰਟਾਂ ਨੂੰ ਮੰਜ਼ਿਲ ਖੁਦ ਸਿੱਖਣ ਲਈ push "route 10.66.0.10 255.255.255.255" ਚਾਹੀਦਾ ਹੈ।

ਰਾਊਟਿੰਗ ਅਤੇ ਅਧਿਕਾਰ ਵੱਖਰੇ ਰਹਿੰਦੇ ਹਨ। ਧੱਕਿਆ ਮਾਰਗ ਕਲਾਇੰਟ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਪੈਕੇਟ ਕਿੱਥੇ ਭੇਜਣੇ ਹਨ ਅਤੇ ਕੁਝ ਨਹੀਂ ਦਿੰਦਾ; ਸੇਵਾ ਨੂੰ ਅਜੇ ਵੀ ਕਾਲਰ ਨੂੰ ਆਪਣੀਆਂ ਸ਼ਰਤਾਂ ’ਤੇ ਸਵੀਕਾਰ ਕਰਨਾ ਹੈ।

ਇਨਪੁਟ ਨੀਤੀ ਅਤੇ ਜਵਾਬ ਮਾਰਗ ਦੀ ਜਾਂਚ ਕਰੋ

ਉਪਨਾਮ ਨੂੰ ਸੰਬੋਧਿਤ ਪੈਕੇਟ ਮਾਲਕ ਹੋਸਟ ’ਤੇ ਸਥਾਨਕ ਇਨਪੁਟ ਵਜੋਂ ਪਹੁੰਚਦਾ ਹੈ, ਇਸ ਲਈ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਸਥਾਨਕ ਫਾਇਰਵਾਲ ਉਸ ਸਰੋਤ ਅਤੇ ਪੋਰਟ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਪੂਰਾ ਪਤਾ ਖੋਲ੍ਹਣ ਦੀ ਬਜਾਏ VPN ਸਰੋਤ ਰੇਂਜ ਤੋਂ ਖਾਸ ਸੇਵਾ ਪੋਰਟ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿਓ।

ਜਵਾਬਾਂ ਨੂੰ ਕਾਲਰ ਤੱਕ ਵਾਪਸੀ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ। ਆਮ ਟਨਲ ਪੂਲ ਦੇ ਅੰਦਰਲੇ ਕਾਲਰ ਲਈ ਉਹ ਮਾਰਗ ਪਹਿਲਾਂ ਹੀ ਹੈ, ਕਿਉਂਕਿ ਟਨਲ ਡਿਵਾਈਸ ਇਸਨੂੰ ਚੁੱਕਦੀ ਹੈ। ਕਿਸੇ ਹੋਰ ਰਾਊਟ ਕੀਤੇ ਨੈੱਟਵਰਕ ਪਿੱਛੇ ਦੇ ਕਾਲਰ ਨੂੰ ਉਸ ਨੈੱਟਵਰਕ ਦਾ ਵਾਪਸੀ ਮਾਰਗ ਵੀ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇੱਥੇ ਹੀ ਅਸਮਮਿਤ ਸੈਟਅਪ ਪੈਕੇਟ ਗੁਆਉਂਦੇ ਹਨ।

ਉਸੇ ਪੋਰਟ ’ਤੇ ਕਿਸੇ ਹੋਰ ਪਤੇ ਨਾਲ ਬੱਝੇ ਦੂਜੇ ਸਰੋਤੇ ਵੱਲ ਧਿਆਨ ਦਿਓ, ਕਿਉਂਕਿ ਕਰਨਲ ਜੋ ਸਾਕਟ ਮੇਲ ਖਾਂਦਾ ਹੈ ਉਸਨੂੰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਨਤੀਜੇ ਬੇਤਰਤੀਬ ਦਿਸਦੇ ਹਨ। ss -lntp ਨਾਲ ਜਾਂਚੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਬੱਝਿਆ ਪਤਾ ਸੇਵਾ ਉਪਨਾਮ ਹੈ। ਇੱਥੇ ਸਰੋਤ NAT ਦੀ ਲੋੜ ਨਹੀਂ, ਅਤੇ ਇਸਨੂੰ ਜੋੜਨ ਨਾਲ ਤੁਹਾਡੇ ਲਾਗ ਜਿਸ ਕਾਲਰ ਪਛਾਣ ’ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਉਹ ਲੁਕ ਜਾਂਦੀ ਹੈ।

ਪਤੇ ਅਤੇ ਮਾਲਕੀ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਜਾਂਚੋ

ਦੋ ਪੜਾਵਾਂ ਵਿੱਚ ਜਾਂਚੋ। ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਮਾਲਕ ਹੋਸਟ ਆਪਣੇ ਉਪਨਾਮ ’ਤੇ ਸੇਵਾ ਤੱਕ ਖੁਦ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਜੋ ਬਾਈਂਡ ਅਤੇ ਫਾਇਰਵਾਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰਾਊਟਿੰਗ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਫਿਰ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਪਣੀ ਪ੍ਰਮਾਣਿਕਤਾ ਵਰਤ ਕੇ ਅਸਲ VPN ਕਾਲਰ ਤੋਂ ਜਾਂਚੋ। ਜਦੋਂ ਪਹਿਲਾ ਪਾਸ ਹੋਵੇ ਅਤੇ ਦੂਜਾ ਫੇਲ ਹੋਵੇ, ਤਾਂ ਗੁੰਮ ਹਿੱਸਾ ਹੱਬ ਵੱਲ ਹੁੰਦਾ ਹੈ।

ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਵੀ ਰਹਿਣ ਵਾਲੇ ਫੇਲ ਹੋਣ ਦੇ ਢੰਗ ਵੀ ਜਾਂਚੋ: ਟਨਲ ਬੰਦ ਹੋਣ ’ਤੇ ਵੀ ਉਪਨਾਮ ਨਿਰਧਾਰਿਤ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਪੀਅਰ ਗੈਰਹਾਜ਼ਰ ਹੋਣ ’ਤੇ ਵੀ ਹੱਬ ਆਪਣਾ ਮਾਰਗ ਰੱਖਦਾ ਹੈ। ਕੋਈ ਵੀ ਵਸਤੂ ਇਕੱਲੀ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਸੇਵਾ ਪਹੁੰਚਯੋਗ ਹੈ, ਇਸ ਲਈ ਦੋ-ਪੜਾਅ ਪਰੀਖਿਆ ਲੈਪਟਾਪ ਤੋਂ ਇੱਕ ਪਿੰਗ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।