VPN ਰਾਹੀਂ 169.254: ਇਹ ਪਤਾ ਕਦੇ ਵੀ ਰੂਟ ਹੋਣ ਯੋਗ ਨਹੀਂ ਸੀ
ਲਿੰਕ-ਲੋਕਲ ਮੰਤਵ ਟਨਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸੁੱਟਿਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਰੂਟ ਜੋੜਨਾ ਸਿਰਫ਼ ਨਾਕਾਮੀ ਨੂੰ ਚੌੜਾ ਕਰਦਾ ਹੈ। ਸਬਨੈੱਟ ਠੀਕ ਕਰਨ ਜਾਂ ਪੁਲ ਬਣਾਉਣ ਵਿੱਚੋਂ ਚੁਣੋ।
ਤੁਸੀਂ ਰੂਟ ਜੋੜਦੇ ਹੋ, ਟਨਲ ਉੱਪਰ ਆਉਂਦੀ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਦੂਜੇ ਪਾਸੇ ਦਾ ping «network unreachable» ਦੀ ਥਾਂ ਪੂਰੇ ਨੁਕਸਾਨ ਨਾਲ ਮਰਦਾ ਹੈ। ਇਹ ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਧਿਆਨ ਰੂਟ ਟੇਬਲ ਤੋਂ ਪਤੇ ਵੱਲ ਮੋੜਦਾ ਹੈ। 169.254 ਮੰਤਵ ਲਿੰਕ-ਲੋਕਲ ਹੈ ਅਤੇ ਇਸ ਦਾ ਘੇਰਾ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਪਹਿਲੇ hop ’ਤੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ।
ਅਗਲਾ ਫ਼ੈਸਲਾ ਤੰਗ ਹੈ: ਸਰਵਰ ਵਾਲੇ ਪਾਸੇ ਦਾ ਸਬਨੈੱਟ ਠੀਕ ਕਰੋ ਜਾਂ ਪਰਤ 2 ਦਾ ਹਿੱਸਾ ਵਧਾਓ। ਵਧੇਰੇ ਚੌੜਾ ਰੂਟ ਵੀ ਉਹੀ ਨਾਕਾਮੀ ਹੋਰ ਮੰਤਵਾਂ ਤੱਕ ਫੈਲਾਉਂਦਾ ਹੈ।
ਪਤੇ ਨੂੰ ਰੂਟ ਨਹੀਂ, ਇਹ ਰੂਟ ਹੋਣ ਯੋਗ ਨਹੀਂ
IPv4 ਲਿੰਕ-ਲੋਕਲ ਪਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਤਦ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਕੋਈ ਵਧੀਆ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ; Windows ਵਿੱਚ ਸਵੈਚਾਲਿਤ ਨਿੱਜੀ ਪਤਾ-ਨਿਰਧਾਰਨ ਇੱਥੋਂ ਆਉਂਦਾ ਹੈ। ਇਹ ਘੇਰਾ ਹਰ ਲਿੰਕ ’ਤੇ ਇੱਕੋ ਸਮੇਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸੇ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ: ਇੱਕੋ ਹਿੱਸੇ ਦੇ ਦੋ ਹੋਸਟ ਬਿਨਾਂ ਕਿਸੇ ਤਾਲਮੇਲ ਦੇ ਗੱਲ ਕਰ ਸਕਦੇ ਹਨ।
ਇਸੇ ਗੁਣ ਕਰਕੇ ਰਾਊਟਰ ਨੂੰ ਇਹ ਪੈਕਟ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਨਹੀਂ ਭੇਜਣੇ ਚਾਹੀਦੇ। ਲਿੰਕ-ਲੋਕਲ ਮੰਤਵ ਲਈ ਭੇਜਿਆ ਪੈਕਟ ਲੈ ਕੇ ਦੂਜੇ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਬਾਹਰ ਭੇਜਣ ਨਾਲ ਅਸਪਸ਼ਟਤਾ ਬਣਦੀ ਹੈ, ਕਿਉਂਕਿ ਭੇਜਣ ਵਾਲੇ ਦਾ «ਸਥਾਨਕ» ਅਤੇ ਲੈਣ ਵਾਲੇ ਦਾ «ਸਥਾਨਕ» ਵੱਖਰੀਆਂ ਥਾਵਾਂ ਹਨ। ਕੋਈ ਖੋਜ ਇਹ ਤੈਅ ਨਹੀਂ ਕਰ ਸਕਦੀ ਕਿ ਕਿਹੜਾ ਮਤਲਬ ਸੀ। ਇੱਥੇ ਭੇਜਣਾ ਪ੍ਰਬੰਧਕ ਵੱਲੋਂ ਚਾਲੂ ਕੀਤਾ ਜਾ ਸਕਣ ਵਾਲਾ ਨੀਤੀ ਵਿਕਲਪ ਨਹੀਂ।
ਇਸ ਲਈ 169.254.1.10 ਨੂੰ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਦੱਸਣ ਵਾਲਾ ਗੇਟਵੇ ਕਰਨਲ ਤੋਂ ਉਹ ਮੰਗਦਾ ਹੈ ਜੋ ਪਤੇ ਦਾ ਰੂਪ ਮਨਾਹੀ ਕਰਦਾ ਹੈ। ਪੈਕਟ ਦੂਰ ਦੇ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਸੁੱਟਿਆ ਜਾਂਦਾ ਹੈ।
ਟਨਲ ਘੇਰੇ ਦੀ ਸਮੱਸਿਆ ਕਿਉਂ ਦਿਖਾਉਂਦੀ ਹੈ
TUN ਇੰਟਰਫ਼ੇਸ ਦੋ ਧਿਰਾਂ ਵਿਚਕਾਰ IP ਪੈਕਟ ਢੋਂਦਾ ਹੈ ਅਤੇ ਇਸ ਦੇ ਪਿੱਛੇ ਕੋਈ ਸਾਂਝਾ ਹਿੱਸਾ ਨਹੀਂ। ਕੋਈ ਪ੍ਰਸਾਰਣ ਨਹੀਂ, ਦੂਜੇ ਪਾਸੇ ਲਈ ARP ਨਹੀਂ ਅਤੇ ਗੁਆਂਢੀ ਖੋਜ ਵੀ ਨਹੀਂ।
ਲੱਛਣ ਬਿਲਕੁਲ ਮਿਲਦੇ ਹਨ। ਰੂਟ ਟੇਬਲ ਵਿੱਚ ਹੈ, ping ਪੂਰਾ ਨੁਕਸਾਨ ਦੱਸਦਾ ਹੈ, ਗੁਆਂਢੀ ਟੇਬਲ ਅਧੂਰੀ ਐਂਟਰੀ ਦਿਖਾਉਂਦਾ ਹੈ। ਟਨਲ ’ਤੇ ਰਿਕਾਰਡ ਪੈਕਟ ਨੂੰ ਬਾਹਰ ਜਾਂਦਿਆਂ ਦਿਖਾਉਂਦਾ ਹੈ, ਜੋ ਲੋਕਾਂ ਨੂੰ ਪਤਾ ਸ਼੍ਰੇਣੀ ਦੀ ਥਾਂ ਦੂਰ ਦੇ ਸਿਰੇ ਵੱਲ ਵੇਖਣ ਲਈ ਭੇਜਦਾ ਹੈ।
Windows ਵਿੱਚ ਉਸੇ ਜੜ੍ਹ ਦਾ ਦੂਜਾ ਲੱਛਣ ਹੈ: ਸਿਰਫ਼ ਲਿੰਕ-ਲੋਕਲ ਪਤਾ ਬਚੇ ਐਡੈਪਟਰ ਕੋਲ ਵਰਤੋਂ ਯੋਗ ਗੇਟਵੇ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਫਾਇਰਵਾਲ ਪ੍ਰੋਫ਼ਾਈਲ public ’ਤੇ ਡਿੱਗਦੀ ਹੈ। ਟਨਲ ਕਾਰਨ ਨਹੀਂ; ਪਤਾ ਕਾਰਨ ਹੈ।
ਤਿੰਨ ਸਵਾਲਾਂ ਨਾਲ ਫ਼ੈਸਲਾ ਕਰੋ
ਸਬਨੈੱਟ ਠੀਕ ਕਰਨ ਅਤੇ ਪੁਲ ਬਣਾਉਣ ਵਿਚਕਾਰ ਚੋਣ ਤਿੰਨ ਸ਼ਰਤਾਂ ’ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
ਬਹੁਤੇ ਕੇਸ ਪਹਿਲੇ ਸਵਾਲ ’ਤੇ ਰੁਕਦੇ ਹਨ। ਲਿੰਕ-ਲੋਕਲ ਪਤਾ ਦਿਖਾਉਣ ਵਾਲਾ ਹੋਸਟ ਆਮ ਤੌਰ ’ਤੇ ਦੱਸਦਾ ਹੈ ਕਿ DHCP ਨੇ ਜਵਾਬ ਨਹੀਂ ਦਿੱਤਾ, ਕੇਬਲ ਜਾਂ VLAN ਗਲਤ ਹੈ, ਜਾਂ ਕਿਸੇ ਨੇ ਪਤਾ ਹੱਥ ਨਾਲ ਲਿਖਿਆ। ਇਸ ਨੂੰ ਠੀਕ ਕਰਨਾ ਕਿਸੇ ਵੀ ਟਨਲ ਕੰਮ ਨਾਲੋਂ ਸਸਤਾ ਹੈ ਅਤੇ ਆਉਣ ਵਾਲੇ ਹਰ ਗਾਹਕ ਤੋਂ ਸਮੱਸਿਆ ਹਟਾਉਂਦਾ ਹੈ।
ਕੁਝ ਵੀ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਵਾਲਾ ਪਾਸਾ ਵੇਖੋ। ਹੋਸਟ ’ਤੇ ip addr show ਅਤੇ ip route, ਗਾਹਕ ’ਤੇ arp -n ਜਾਂ route print -4 ਚਲਾਓ।
ਪੁਲ ਸਹੀ ਜਵਾਬ ਹੋਣ ’ਤੇ ਇਸ ਦੀ ਕੀਮਤ
ਭੌਤਿਕ ਐਡੈਪਟਰ ਨੂੰ TAP ਐਡੈਪਟਰ ਨਾਲ ਜੋੜ ਕੇ ਪੁਲ ਬਣਾਉਣ ਨਾਲ ਦੂਰ ਦਾ ਗਾਹਕ ਸਥਾਨਕ ਪ੍ਰਸਾਰਣ ਡੋਮੇਨ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਕੀਮਤ ਅਸਲੀ ਹੈ ਅਤੇ ਕਿਸੇ ਦੇ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਦੱਸਣੀ ਚਾਹੀਦੀ ਹੈ। ਪ੍ਰਸਾਰਣ ਟ੍ਰੈਫ਼ਿਕ ਟਨਲ ਪਾਰ ਕਰਦਾ ਹੈ, ਗਾਹਕ ਸਥਾਨਕ ਹਿੱਸੇ ਸਾਹਮਣੇ ਹਰ ਮਕਸਦ ਲਈ ਖੁੱਲ੍ਹਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਹੁਣ ਪੈਕਟ ਰੂਟ ਕਰਨ ਦੀ ਥਾਂ ਫ਼ਰੇਮ ਭੇਜਦਾ ਹੈ। ਲੈਬ ਲਈ ਢੁੱਕਵਾਂ, ਦੂਰੋਂ ਪਹੁੰਚ ਲਈ ਮਾੜਾ ਡਿਫ਼ਾਲਟ।
ਪੁਲ ਬਣਾਉਂਦਿਆਂ ਦੋਵੇਂ ਅੱਧੇ ਲੋੜੀਂਦੇ ਹਨ: ਸਰਵਰ ’ਤੇ ਪੁਲ ਅਤੇ ਗਾਹਕ ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਰੂਟ। ਸਿਰਫ਼ ਪੁਲ ਗਾਹਕ ਨੂੰ ਅੰਦਾਜ਼ੇ ਵਿੱਚ ਛੱਡਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਰੂਟ ਪਤਾ ਸ਼੍ਰੇਣੀ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ।