ਰੂਟ ਕੀਤੇ OpenVPN ਟਨਲ ਉੱਤੇ ਨਾਮ ਦੀ ਖੋਜ ਕਿਉਂ ਅਸਫਲ ਹੁੰਦੀ ਹੈ

ਹੋਸਟ ਐਡਰੈੱਸ ਨਾਲ ping ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਨਾਮ ਨਾਲ ਹਰ ਖੋਜ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦਾ ਹੈ। ਟਨਲ ਚਾਲੂ ਹੈ ਅਤੇ ਰੂਟ ਮੌਜੂਦ ਹੈ, ਇਸ ਲਈ ਸੁਭਾਵਿਕ ਸਿੱਟਾ ਇਹ ਹੈ ਕਿ VPN ਗਲਤ ਕਨਫਿਗਰ ਹੈ। ਵਧੇਰੇ ਲਾਹੇਵੰਦ ਸਿੱਟਾ ਇਹ ਹੈ ਕਿ ਉਹ ਖੋਜ ਕਦੇ ਰੂਟ ਹੋਣਯੋਗ ਨਹੀਂ ਸੀ: ਰੂਟ ਕੀਤਾ ਟਨਲ unicast IP ਲੈ ਜਾਂਦਾ ਹੈ, ਜਦਕਿ ਉਹ ਕਵੈਰੀ ਬ੍ਰੌਡਕਾਸਟ ਸੀ ਜੋ ਦੂਜੇ ਪਾਸੇ ਨਾ ਹੋਣ ਵਾਲੇ ਸੈਗਮੈਂਟ ਦੀ ਭਾਲ ਕਰ ਰਹੀ ਸੀ। ਪਰਤਾਂ ਦੀ ਬੇਮੇਲ ਦਿਸਦਿਆਂ ਹੀ ਹੱਲ ਆਪਣੇ ਆਪ ਲਾਗਤ ਅਨੁਸਾਰ ਲੱਗ ਜਾਂਦੇ ਹਨ।

ਭਰਮ: ਨਾਮ ਅਸਫਲ ਹੁੰਦੇ ਹਨ ਇਸ ਲਈ ਟਨਲ ਟੁੱਟੀ ਹੈ

ਲੱਛਣ ਭਰੋਸੇਯੋਗ ਹੈ ਕਿਉਂਕਿ ਨਾਮ ਦੀ ਪਰਤ ਤੋਂ ਉੱਪਰ ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ। ਐਡਰੈੱਸ ਰੂਟ ਹੁੰਦੇ ਹਨ, ਇੰਟਰਫੇਸ ਚਾਲੂ ਹੈ, ਅਤੇ ਸਾਥੀ ping ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਅਸਫਲ ਉਹ ਖੋਜ-ਪ੍ਰਣਾਲੀ ਹੋਈ ਜਿਸ ਕੋਲ ਪੁਆਇੰਟ-ਤੋਂ-ਪੁਆਇੰਟ ਲਿੰਕ ਰਾਹੀਂ ਕਦੇ ਰਾਹ ਨਹੀਂ ਸੀ, ਅਤੇ ਇਹ ਟੁੱਟੀ ਟਨਲ ਤੋਂ ਵੱਖਰਾ ਬਿਆਨ ਹੈ। ਇਹਨਾਂ ਦੋ ਬਿਆਨਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਹੀ ਨਿਦਾਨ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹੈ।

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

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

TUN ਕੀ ਲੈ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

TUN ਡਿਵਾਈਸ ਇੱਕ IP ਇੰਟਰਫੇਸ ਹੈ, ਅਤੇ ਇਹੀ ਇਸਨੂੰ ਰੂਟ ਹੋਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। OpenVPN ਕਲਾਇੰਟ ਨੂੰ ਐਡਰੈੱਸ ਅਤੇ ਰੂਟਾਂ ਦਾ ਸਮੂਹ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ ਸਾਥੀ ਨੂੰ ਡੇਟਾਗ੍ਰਾਮ ਭੇਜਦਾ ਹੈ। ਉਸ ਮਾਡਲ ਵਿੱਚ ਕੁਝ ਵੀ ਅਜਿਹਾ ਸਾਂਝਾ ਲਿੰਕ ਨਹੀਂ ਬਣਾਉਂਦਾ ਜਿੱਥੇ ਹਰ ਹੋਸਟ ਹਰ ਫਰੇਮ ਸੁਣੇ।

ਖੋਜ ਦਾ ਟ੍ਰੈਫਿਕ ਉਸ ਮਾਡਲ ਵਿੱਚ ਬਿਲਕੁਲ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ। ਪੁਰਾਣੀਆਂ Windows ਨਾਮ-ਕਵੈਰੀਆਂ, SSDP ਐਲਾਨ ਅਤੇ mDNS ਬੇਨਤੀਆਂ ਇੱਕ ਗੰਤਵਿਅ ਦੀ ਥਾਂ ਸੈਗਮੈਂਟ ਦੇ ਸਭ ਨੂੰ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਰੂਟ ਕੀਤੇ ਲਿੰਕ ਕੋਲ ਭੇਜਣ ਲਈ ਕੋਈ «ਸਭ» ਨਹੀਂ ਹੁੰਦਾ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਪ੍ਰਣਾਲੀ ਸਾਂਝੇ ਮਾਧਿਅਮ ਨੂੰ ਮੰਨ ਲੈਂਦੀ ਹੈ।

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

ਬ੍ਰਿਜਿੰਗ ਸੀਮਾ ਹਟਾ ਕੇ ਕੰਮ ਕਰਦੀ ਹੈ

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

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

ਛੋਟੀ ਲੈਬ ਲਈ ਇਹ ਨਿਆਂਪੂਰਨ ਵਟਾਂਦਰਾ ਹੈ। ਖਿੰਡੇ ਹੋਏ ਕਰਮਚਾਰੀਆਂ ਲਈ ਇਹ ਘੱਟ ਹੀ ਹੁੰਦਾ ਹੈ।

DNS ਅਤੇ WINS ਪੁਸ਼ ਕਰਨਾ ਸੰਕੁਚਿਤ ਸੁਧਾਰ ਹੈ

ਕਲਾਇੰਟ ਨੂੰ ਪੁੱਛਣ ਲਈ ਨਿਸ਼ਚਿਤ ਥਾਂ ਦਿਓ। dhcp-option DNS ਅਤੇ dhcp-option DOMAIN ਅੰਦਰੂਨੀ ਨਾਮਾਂ ਨੂੰ ਜ਼ੋਨ ਜਾਣਨ ਵਾਲੇ ਸਰਵਰ ਵੱਲ ਭੇਜਦੇ ਹਨ, ਅਤੇ ਅਜੇ ਵੀ NetBIOS ਉੱਤੇ ਨਿਰਭਰ Windows ਕਲਾਇੰਟ ਉਸੇ ਤਰ੍ਹਾਂ WINS ਸਰਵਰ ਲੈ ਸਕਦਾ ਹੈ। ਟਨਲ ਰੂਟ ਕੀਤੀ ਹੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਸੈਗਮੈਂਟ ਆਪਣੀ ਥਾਂ ਉੱਤੇ ਰਹਿੰਦਾ ਹੈ।

ਦੋ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਇਹ ਕੰਮ ਕਰੇਗਾ ਜਾਂ ਨਹੀਂ। ਦੱਸਿਆ ਸਰਵਰ ਜ਼ੋਨ ਲਈ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਵੈਰੀ ਨੂੰ ਟਨਲ ਰਾਹੀਂ ਆਗਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਰਿਜ਼ੌਲਵਰ ਕਲਾਇੰਟ ਤੋਂ ਜਾਂਚੋ, ਸਰਵਰ ਦੀ ਆਪਣੀ ਸ਼ੈੱਲ ਤੋਂ ਨਹੀਂ। ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰਿਜ਼ੌਲਵਰ ਟਨਲ ਕੀ ਲੈ ਜਾਂਦੀ ਹੈ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

ਕਿਹੜੀ ਪਰਤ ਅਸਫਲ ਹੋਈ ਲੱਭੋ

ਪਹਿਲਾਂ ਐਡਰੈੱਸ ਨੂੰ ping ਕਰੋ, ਫਿਰ ਨਾਮ ਰਿਜ਼ੌਲਵ ਕਰੋ ਅਤੇ ਪੜ੍ਹੋ ਕਿ ਕਿਹੜੇ ਸਰਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ। ਜ਼ੋਨ ਹੋਸਟ ਨਾ ਕਰਨ ਵਾਲੇ ਸਰਵਰ ਦਾ ਨਕਾਰਾਤਮਕ ਜਵਾਬ, ਮਸ਼ੀਨ ਤੋਂ ਕਦੇ ਨਾ ਨਿਕਲੀ ਕਵੈਰੀ ਨਾਲੋਂ ਵੱਖਰਾ ਦਿਸਦਾ ਹੈ। ਜੋ ਨਾਮ ਰਿਜ਼ੌਲਵ ਹੁੰਦਾ ਹੈ ਪਰ ਕਨੈਕਸ਼ਨ ਨਾਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਉਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੀਜੀ ਸਮੱਸਿਆ ਹੈ।

ਮਲਟੀਕਾਸਟ ਉਸੇ ਕੰਧ ਪਿੱਛੇ ਹੈ। 224.0.0.251 ਵਰਗਾ ਸਮੂਹ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਰੂਟ ਕੀਤੀ ਟਨਲ ਰਾਹੀਂ ਅੱਗੇ ਨਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ, ਅਤੇ ਮਲਟੀਕਾਸਟ-ਸਮਝਦਾਰ ਰਾਹ ਜਾਂ LAN ਉੱਤੇ ਪਰਾਵਰਤਕ ਤੋਂ ਬਿਨਾਂ ਸਮੂਹ ਲਈ ਰੂਟ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ।