Pi 'ਤੇ ਹੌਟਸਪੌਟ ਕਲਾਇੰਟ TUN VPN ਰਾਹੀਂ ਘਰ ਦੇ LAN ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ

ਪਤਾ ਮਿਲਦਾ ਹੈ ਪਰ ਘਰ ਦੀ ਸਾਂਝ ਨਹੀਂ ਖੁੱਲ੍ਹਦੀ, ਅਜਿਹੇ ਹੌਟਸਪੌਟ ਕਲਾਇੰਟ ਨੂੰ ਪੁਲ ਨਹੀਂ, ਵਾਪਸੀ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ। TUN ਮਾਰਗ, ਪ੍ਰੀਫਿਕਸ ਮਾਲਕ ਅਤੇ NAT ਟਰੇਸ ਕਰੋ।

ਸਥਾਨਕ Wi-Fi ਅਤੇ Ethernet ਕਲਾਇੰਟ Pi ਦੇ ਹੌਟਸਪੌਟ ਨਾਲ ਜੁੜਦੇ ਹਨ, ਉਸ ਦੀ DHCP ਰੇਂਜ ਤੋਂ ਪਤਾ ਲੈਂਦੇ ਹਨ ਅਤੇ ਬਿਨਾਂ ਸ਼ਿਕਾਇਤ ਇੰਟਰਨੈੱਟ ਪੇਜ ਲੋਡ ਕਰਦੇ ਹਨ। ਫਿਰ ਉਹੀ ਕਲਾਇੰਟ ਘਰ ਦੇ LAN 'ਤੇ ਫਾਈਲ ਸਾਂਝ ਜਾਂ ਵੈੱਬ ਇੰਟਰਫੇਸ ਖੋਲ੍ਹਦੇ ਸਮੇਂ ਸਮਾਂ ਸਮਾਪਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਦਕਿ Pi ਆਪ ਸੁਰੰਗ ਰਾਹੀਂ ਉਸ LAN ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਵਾਇਰਲੈੱਸ ਪਰਤ ਵਿੱਚ ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ। ਜੋ ਘਟ ਹੈ ਉਹ ਰਾਊਟ ਕੀਤਾ ਇਕਰਾਰ ਹੈ: ਹੌਟਸਪੌਟ ਪ੍ਰੀਫਿਕਸ TUN ਇੰਟਰਫੇਸ ਵਿੱਚ ਲਿਜਾਣਾ ਪਵੇਗਾ, ਅਤੇ ਘਰ ਵਾਲੇ ਪਾਸੇ ਕਿਸੇ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜਵਾਬ ਉੱਥੇ ਵਾਪਸ ਕਿਵੇਂ ਭੇਜਣੇ ਹਨ। ਇੱਕ ਵੀ ਪੈਕੇਟ ਦਾ ਸਫ਼ਰ ਪੂਰਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਅੱਧੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਤਿੰਨ ਵੱਖਰੇ ਕੰਮਾਂ ਵਾਲੇ ਤਿੰਨ ਜੋੜ

Linux Ethernet ਪੁਲ ਟਾਰਗੇਟ MAC ਪਤੇ ਅਨੁਸਾਰ ਫਰੇਮ ਅੱਗੇ ਭੇਜਦਾ ਹੈ। OpenVPN TUN ਮੋਡ ਵਿੱਚ IP ਪੈਕੇਟ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ MAC ਪਰਤ ਬਿਲਕੁਲ ਨਹੀਂ, ਇਸ ਲਈ ਸਥਾਨਕ ਪੁਲ ਜੋੜਨ ਨਾਲ ਸੁਰੰਗ ਕਦੇ ਵੀ ਪੋਰਟ ਵਜੋਂ ਦਰਜ ਨਹੀਂ ਹੁੰਦੀ। ਕਰਨਲ TUN/TAP ਦਸਤਾਵੇਜ਼ ਉਸ ਵੰਡ ਦੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ: TAP ਡਿਵਾਈਸ Ethernet ਇੰਟਰਫੇਸ ਵਰਗੀ ਦਿਖਦੀ ਹੈ, TUN ਡਿਵਾਈਸ ਨਹੀਂ। ਦੋ ਸਥਾਨਕ ਪੋਰਟਾਂ ਨੂੰ ਪੁਲ ਕਰਕੇ ਫਿਰ ਰਾਊਟ ਕਰਨ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਇੰਟਰਫੇਸ ਦੇ ਨਾਮ ਚਾਹੇ ਕੁਝ ਵੀ ਕਹਿਣ, ਰਾਊਟਰ ਹੁੰਦਾ ਹੈ।

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

ਮਾਡਮ ਨੂੰ ਵੀ ਕਲਾਇੰਟ ਪੁਲ ਤੋਂ ਬਾਹਰ ਰੱਖੋ। PPP ਜੋੜ Ethernet ਡਿਵਾਈਸ ਨਹੀਂ ਜਿਸ 'ਤੇ ਹੋਰ ਲੇਬਲ ਹੋਵੇ, ਅਤੇ pppd ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਡਿਫ਼ਾਲਟ-ਰਾਊਟ ਤਰਕ IPCP ਗੱਲਬਾਤ ਤੋਂ ਬਾਅਦ ਚੱਲਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਉਹ ਲਿੰਕ ਡਿੱਗਦਾ ਹੈ ਤਾਂ ਆਪਣਾ ਰਾਹ ਵਾਪਸ ਲੈ ਲੈਂਦਾ ਹੈ। DHCP ਟੈਂਪਲੇਟ ਕਾਪੀ ਕਰਕੇ ਹਰ usb0 ਦਾ ਨਾਮ ppp0 ਰੱਖਣਾ ਗੇਟਵੇ, ਮੈਟ੍ਰਿਕ ਜਾਂ ਜੀਵਨ-ਚੱਕਰ ਬਾਰੇ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।

ਕੋਈ ਵੀ ਕਨਫਿਗ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੀਫਿਕਸ ਚੁਣੋ

ਓਵਰਲੈਪਿੰਗ ਪ੍ਰੀਫਿਕਸ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਨਾਲੋਂ ਵੱਧ ਸ਼ਾਮਾਂ ਬਰਬਾਦ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਸੁਰੰਗ ਸਿਹਤਮੰਦ ਹੋਣ 'ਤੇ ਵੀ ਓਵਰਲੈਪ ਰਾਊਟ ਖੋਜ ਨੂੰ ਗਲਤ ਇੰਟਰਫੇਸ 'ਤੇ ਭੇਜਦਾ ਹੈ। Pi 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਕੀ ਹੈ ਦੀ ਸੂਚੀ ਬਣਾ ਕੇ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਨਤੀਜੇ ਨੂੰ ਚਾਰ ਵੱਖਰੇ ਤਾਲਾਬਾਂ ਵਜੋਂ ਪੜ੍ਹੋ।

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

ਪਹਿਲਾ ਤਾਲਾਬ ਉਹ underlay ਪਤਾ ਹੈ ਜੋ ਕੈਰੀਅਰ ਨੇ ਮਾਡਮ ਨੂੰ ਦਿੱਤਾ; ਇਹ ਕਲਾਇੰਟ ਵੱਲ ਦੇਖਣ ਵਾਲੀ ਹਰ ਯੋਜਨਾ ਤੋਂ ਬਾਹਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਦੂਜਾ ਸਰਵਰ ਵੱਲੋਂ ਚੁਣਿਆ ਸੁਰੰਗ ਸਬਨੈੱਟ ਹੈ, ਅਕਸਰ ਉਸ ਦਾ ਆਪਣਾ ਨਿੱਜੀ /24। ਤੀਜਾ ਹੌਟਸਪੌਟ ਪੁਲ ਹੈ, ਅਤੇ ਚੌਥਾ ਉਹ ਘਰ ਦਾ ਪ੍ਰੀਫਿਕਸ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਪਹੁੰਚਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਇਸ ਫੇਰੀ ਵਿੱਚ ਹੌਟਸਪੌਟ ਨੂੰ 172.28.90.0/24 ਮਿਲਦਾ ਹੈ, ਪੁਲ 172.28.90.1 'ਤੇ ਹੈ, ਅਤੇ ਘਰ ਦੀ ਸੇਵਾ LAN 192.168.77.0/24 ਰੱਖਦੀ ਹੈ, ਜੋ ਖਪਤਕਾਰ ਰਾਊਟਰਾਂ ਨਾਲ ਆਉਣ ਵਾਲੇ 192.168.1.0/24 ਅਤੇ 10.0.0.0/24 ਡਿਫ਼ਾਲਟ ਅਤੇ 100.64.0.0/10 ਕੈਰੀਅਰ ਰੇਂਜ ਤੋਂ ਬਚਦਾ ਹੈ।

ਹੌਟਸਪੌਟ ਦੀ DHCP ਰੇਂਜ ਵਿੱਚ ਸਿਰਫ਼ ਪੁਲ ਦਾ ਪਤਾ ਗੇਟਵੇ ਵਜੋਂ ਐਲਾਨੋ, ਹੋਰ ਕੁਝ ਨਹੀਂ। ਹੌਟਸਪੌਟ ਕਲਾਇੰਟਾਂ ਨੂੰ ਕਦੇ ਵੀ ਗੇਟਵੇ ਵਜੋਂ ਘਰ ਦਾ ਪਤਾ ਨਾ ਦਿਓ; ਉਨ੍ਹਾਂ ਕੋਲ ਉਸ ਸੈਗਮੈਂਟ ਤੱਕ ਲਿੰਕ-ਪਰਤ ਦਾ ਰਾਹ ਨਹੀਂ ਹੈ।

ਹਰ ਦਿਸ਼ਾ ਨੂੰ ਉਸੇ ਪਾਸੇ ਰਾਊਟ ਕਰੋ ਜੋ ਉਸ ਦਾ ਮਾਲਕ ਹੈ

Pi ਨੂੰ ਸੁਰੰਗ ਰਾਹੀਂ ਘਰ ਦੇ ਪ੍ਰੀਫਿਕਸ ਲਈ ਰਾਹ ਚਾਹੀਦਾ ਹੈ। ਸਰਵਰ ਮੋਡ ਵਾਲੇ ਸਰਵਰ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਰਾਹ ਧੱਕਦੇ ਹਨ, ਇਸ ਲਈ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ ਹੈ ਅਤੇ ਕਰਨਲ tun0 ਤੋਂ ਘਰ ਦਾ ਪਤਾ ਹੱਲ ਕਰਦਾ ਹੈ।

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

ਜੇ ip route get ਅਜੇ ਵੀ underlay ਇੰਟਰਫੇਸ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਉੱਥੇ ਹੀ ਰੁਕੋ; ਮਾਰਗ ਵਿੱਚ ਅੱਗੇ ਕੁਝ ਵੀ ਗਲਤ ਖੋਜ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਘਰ ਦੇ ਯੰਤਰਾਂ ਕੋਲ 172.28.90.0/24 ਤੱਕ ਰਾਹ ਨਹੀਂ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਦੇ ਜਵਾਬ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਦੀ ਪੈਰਵੀ ਕਰਦੇ ਹਨ ਅਤੇ ਰਾਊਟਰ 'ਤੇ ਮਰ ਜਾਂਦੇ ਹਨ। ਦੋ ਸਮਰਥਿਤ ਸੁਧਾਰ ਹਨ। ਜਾਂ ਤਾਂ ਘਰ ਦੇ ਰਾਊਟਰ 'ਤੇ ਸਥਿਰ ਰਾਹ ਜੋੜੋ ਜੋ ਹੌਟਸਪੌਟ ਪ੍ਰੀਫਿਕਸ ਨੂੰ VPN ਸਰਵਰ ਦੇ LAN ਪਤੇ ਵੱਲ ਸੇਧਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਸਰਵਰ ਆਪ ਗੇਟਵੇ ਹੋਵੇ, ਕਲਾਇੰਟ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਸਰਵਰ ਦੀ ਆਪਣੀ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਵਿੱਚ ਦਰਜ ਕਰੋ। OpenVPN ਦੇ ਮਲਟੀ-ਕਲਾਇੰਟ ਮੋਡ ਵਿੱਚ ਕਲਾਇੰਟ-ਖਾਸ ਡਾਇਰੈਕਟਰੀ ਉਹ ਸੰਬੰਧ ਲੈ ਕੇ ਚੱਲਦੀ ਹੈ: ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਦੇ ਆਮ ਨਾਮ 'ਤੇ ਨਾਮਿਤ ਫਾਈਲ, ਜਿਸ ਵਿੱਚ iroute 172.28.90.0 255.255.255.0 ਅਤੇ ਉਸ ਨੂੰ ਸਰਵਰ ਕਰਨਲ ਵਿੱਚ ਸਥਾਪਤ ਕਰਨ ਵਾਲੀ ਮੇਲ ਖਾਂਦੀ route ਲਾਈਨ ਹੁੰਦੀ ਹੈ। ਸਰਵਰ 'ਤੇ ਅੰਦਾਜ਼ਾ ਲਾਇਆ ਕਰਨਲ ਰਾਹ ਇਹ ਦੱਸਣ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਕਲਾਇੰਟ ਪ੍ਰੀਫਿਕਸ ਦਾ ਮਾਲਕ ਹੈ।

ਇਹ ਕੰਮ ਕਰੇ ਇਸ ਲਈ ਘਰ ਦੇ ਨੈੱਟਵਰਕ ਦੀ DHCP ਸੇਵਾ VPN ਸਰਵਰ 'ਤੇ ਨਾ ਲਿਜਾਓ। ਪੂਰੇ ਘਰ ਲਈ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਬਦਲਣਾ ਇੱਕ ਨਿੱਜੀ ਵਾਪਸੀ ਰਾਹ ਜੋੜਨ ਨਾਲੋਂ ਕਿਤੇ ਵੱਡਾ ਬਦਲਾਅ ਹੈ, ਅਤੇ ਇਹ DNS, ਪਤਾ ਰਿਜ਼ਰਵੇਸ਼ਨ ਅਤੇ ਨਵੀਂ ਲੀਜ਼ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਵਾਲੇ ਹਰ ਯੰਤਰ ਨੂੰ ਫੇਲ੍ਹ ਹੋਣ ਵੱਲ ਖਿੱਚਦਾ ਹੈ।

ਫਾਇਰਵਾਲ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਏ ਬਿਨਾਂ ਫਾਰਵਰਡਿੰਗ ਖੋਲ੍ਹੋ

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 ਤੋਂ tun0 ਤੱਕ ਸਵੀਕ੍ਰਿਤੀ ਨਿਯਮ ਅਤੇ ਮੇਲ ਖਾਂਦੀ ਜਵਾਬ ਦਿਸ਼ਾ, ਅਤੇ ਸਰੋਤ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਸਕਣ ਵਾਲਾ postrouting ਨਿਯਮ ਲੱਭੋ। ਜੇ ਚੇਨ ਨੀਤੀ drop ਹੈ ਅਤੇ ਕੋਈ ਨਿਯਮ ਨਹੀਂ ਮਿਲਦਾ, ਤਾਂ ਨੀਤੀ ਨੂੰ accept ਵੱਲ ਪਲਟਣ ਦੀ ਬਜਾਏ ਤੰਗ ਸਵੀਕ੍ਰਿਤੀਆਂ ਜੋੜੋ ਅਤੇ ਦੁਬਾਰਾ ਜਾਂਚੋ।

ਅਨੁਵਾਦ ਲੋੜ ਨਹੀਂ, ਨੀਤੀ ਦੀ ਚੋਣ ਹੈ। ਘਰ ਦੇ LAN ਵੱਲ ਸਰੋਤ NAT ਹਰ ਹੌਟਸਪੌਟ ਕਲਾਇੰਟ ਨੂੰ Pi ਦੇ ਸੁਰੰਗ ਪਤੇ ਵਾਂਗ ਦਿਖਾਉਂਦਾ ਹੈ, ਜੋ ਘਰ ਦੇ ਲੌਗਾਂ ਵਿੱਚ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਲੇਖਾ ਗੁਆ ਦਿੰਦਾ ਹੈ ਅਤੇ ਮੂਲ ਸਰੋਤ ਦੀ ਉਮੀਦ ਕਰਨ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਤੋੜਦਾ ਹੈ। NAT ਤੋਂ ਬਿਨਾਂ ਰਾਊਟਿੰਗ ਕਲਾਇੰਟ ਪਤੇ ਦਿੱਖਦੇ ਰੱਖਦੀ ਹੈ ਪਰ ਉੱਪਰਲੇ ਵਾਪਸੀ ਰਾਹ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਇੱਕ ਚੁਣੋ ਅਤੇ DNS ਤੇ IPv6 ਨਾਲ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਨਿਪਟੋ, ਕਿਉਂਕਿ ਟੁੱਟੇ IPv6 ਮਾਰਗ ਦੇ ਨਾਲ ਚੱਲਦਾ IPv4 ਮਾਰਗ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਅਜੇ ਵੀ ਅੱਧਾ ਟੁੱਟਿਆ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ।

ਆਉਣ-ਜਾਣ ਦਾ ਸਫ਼ਰ ਜਾਂਚੋ, ਫਿਰ ਇਸ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਤੋੜੋ

ਹੌਟਸਪੌਟ ਕਲਾਇੰਟ ਤੋਂ ਜਾਂਚ ਕਰੋ, ਕਦੇ ਵੀ Pi ਤੋਂ ਨਹੀਂ, ਕਿਉਂਕਿ Pi ਦਾ ਆਪਣਾ ਟ੍ਰੈਫਿਕ ਅੱਗੇ ਅਤੇ ਵਾਪਸੀ ਦੋਵੇਂ ਮਾਰਗ ਟਾਲਦਾ ਹੈ। ਇੱਕ ਕਲਾਇੰਟ ਘਰ ਦੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਿਆਂ ਦੋਵੇਂ ਇੰਟਰਫੇਸ ਵੇਖੋ।

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

ਦੋਵੇਂ ਕੈਪਚਰ ਇਕੱਠੇ ਪੜ੍ਹੋ। br0 'ਤੇ ਦਿਖ ਕੇ tun0 'ਤੇ ਕਦੇ ਨਾ ਦਿਖਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਮਤਲਬ Pi ਫਾਰਵਰਡ ਨਹੀਂ ਕਰ ਰਿਹਾ ਜਾਂ ਮਾਰਗ ਕਿਤੇ ਹੋਰ ਸੇਧਦਾ ਹੈ। tun0 'ਤੇ ਜਵਾਬ ਤੋਂ ਬਿਨਾਂ ਬੇਨਤੀਆਂ ਦਾ ਮਤਲਬ ਘਰ ਵਾਲੇ ਪਾਸੇ ਵਾਪਸੀ ਮਾਰਗ ਨਹੀਂ ਜਾਂ ਸਰਵਰ ਨੇ ਪੈਕੇਟ ਫਿਲਟਰ ਕੀਤਾ। tun0 'ਤੇ ਦਿਖ ਕੇ br0 'ਤੇ ਦੁਬਾਰਾ ਨਾ ਦਿਖਣ ਵਾਲੇ ਜਵਾਬਾਂ ਦਾ ਮਤਲਬ ਉਲਟਾ ਫਿਲਟਰ ਨਿਯਮ ਗੁੰਮ ਹੈ, ਜਿੱਥੇ ਸੁਰੰਗ ਪੂਰਨ ਦਿਖਦੀ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਕੁਝ ਨਹੀਂ ਵੇਖਦਾ।

ਫਿਰ ਮਾਰਗ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਤੋੜੋ। ਮਾਡਮ ਕਨੈਕਸ਼ਨ ਹੇਠਾਂ ਅਤੇ ਦੁਬਾਰਾ ਉੱਪਰ ਕਰੋ ਅਤੇ ਮਾਰਗ ਤੇ ਕੈਪਚਰ ਜਾਂਚਾਂ ਦੁਬਾਰਾ ਚਲਾਓ; ਸੁਰੰਗ ਤੋਂ ਬਚਣ ਵਾਲਾ ਪਰ ਦੁਬਾਰਾ ਜੁੜਨ 'ਤੇ ਗਾਇਬ ਹੋਣ ਵਾਲਾ ਮਾਰਗ ਇੱਕ-ਵਾਰ ਦੇ ਆਦੇਸ਼ ਵਿੱਚ ਨਹੀਂ, ਕਨੈਕਸ਼ਨ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੁਰੰਗ ਦੀ ਢੋਆ-ਢੁਆਈ ਅਜੇ ਵੀ underlay ਰਾਹੀਂ ਨਿਕਲਦੀ ਹੈ, ਆਪਣੇ ਆਪ ਰਾਹੀਂ ਨਹੀਂ, ਇਹ ਪੀਅਰ ਤੱਕ ਹੋਸਟ ਮਾਰਗ ਤੋਂ ਬਿਨਾਂ ਧੱਕੇ ਗਏ ਡਿਫ਼ਾਲਟ ਮਾਰਗ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਵੇਲੇ ਦਾ ਕਲਾਸਿਕ ਲੂਪ ਹੈ।

ਹੌਟਸਪੌਟ ਕਲਾਇੰਟ ਘਰ ਦਾ ਨਾਮ ਹੱਲ ਕਰ ਸਕੇ, TCP ਸੇਵਾ ਖੋਲ੍ਹ ਸਕੇ ਅਤੇ ਇੱਕ ਮਾਡਮ ਮੁੜ-ਜੁੜਾਈ ਭਰ ਸੈਸ਼ਨ ਜੀਵਤ ਰੱਖ ਸਕੇ ਤਾਂ ਹੀ ਡਿਜ਼ਾਈਨ ਸਵੀਕਾਰੋ। ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਘਰ ਦੇ ਸੈਗਮੈਂਟ ਵਿੱਚ ਸੱਚਮੁੱਚ Ethernet-ਪੱਧਰੀ ਖੋਜ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਸਥਾਨਕ ਪੁਲ ਨੂੰ ਪੁਲ ਕੀਤਾ ਕਹਿ ਕੇ ਪ੍ਰਸਾਰਣ ਆਉਣ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ ਸਮਰਥਿਤ Layer 2 ਡਿਜ਼ਾਈਨ ਚੁਣੋ।

ਸੰਬੰਧਿਤ ਲੇਖ