Tailscale ਦਾ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸਬਨੈੱਟ ਰੂਟ ਫਿਰ ਵੀ ਸਮਾਂ-ਸੀਮਾ ਕਿਉਂ ਲੰਘਦਾ ਹੈ

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

ਚਾਰ ਪੜਾਅ, ਇੱਕ ਫੇਲ੍ਹ

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

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

Linux ਉੱਤੇ ਤੀਜੇ ਪੜਾਅ ਦਾ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਨ ਵਾਲਾ ਡਿਫ਼ਾਲਟ ਵੀ ਹੈ: ਸਬਨੈੱਟ ਰੂਟ ਸਵੀਕਾਰ ਕਰਨਾ ਲਾਜ਼ਮੀ ਨਹੀਂ। ਕਈ GUI ਕਲਾਇੰਟ ਐਲਾਨੇ ਰੂਟ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਮਿਲੀ-ਜੁਲੀ ਫਲੀਟ ਵਿੱਚ ਇੱਕ ਮਸ਼ੀਨ ਫੇਲ ਦਿਸ ਸਕਦੀ ਹੈ ਜਦੋਂ ਬਾਕੀ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹੋਣ।

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

ਰੂਟ ਉੱਥੇ ਜਾਂਚੋ ਜਿੱਥੇ ਕਲਾਇੰਟ ਚੱਲਦਾ ਹੈ

ਰਾਊਟਰ ’ਤੇ ਨਹੀਂ, ਫੇਲ ਹੋ ਰਹੇ ਕਲਾਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰੂਟ ਮੌਜੂਦ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਸੈਟਿੰਗ ਰੂਟ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ।

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

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

Linux ਉੱਤੇ ਰੂਟ ਸਵੀਕਾਰ ਕਰਨ ਲਈ, ਫਲੈਗ ਸੈੱਟ ਹੈ ਇੰਜ ਮੰਨਣ ਦੀ ਥਾਂ ਇਸਦੇ ਨਾਲ ਮੁੜ ਕਨੈਕਟ ਕਰੋ: tailscale up --accept-routes। ਵੱਖਰੇ ਫਲੈਗ ਨਾਲ ਜੁੜਿਆ ਕਲਾਇੰਟ ਉਹਨਾਂ ਨੂੰ ਬਦਲੇ ਜਾਣ ਤੱਕ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਹੋਰ ਇੱਕ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਸੈਟਿੰਗ ਜਾਂਚੋ। ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਪਹਿਲਾ ਕਮਾਂਡ ਮੁੜ ਚਲਾਉਣ ’ਤੇ ਰੂਟ ਸਾਰਣੀ ਵਿੱਚ ਦਿਸਣਾ ਚਾਹੀਦਾ ਹੈ।

ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਵਾਪਸੀ ਮਾਰਗ ਸਾਬਤ ਕਰੋ

ਮਨਜ਼ੂਰੀ ਰਾਊਟਰ ਨੂੰ ਪੈਕਟ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਸੈੱਟ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਜਵਾਬ ਦਾ ਪ੍ਰਬੰਧ ਨਹੀਂ ਕਰਦੀ। ਦੋਵੇਂ ਰਾਊਟਰ ਦੇ LAN ਪਾਸੇ ਹੋਸਟ-ਪੱਧਰ ਦੀਆਂ ਗੱਲਾਂ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਕਲਾਇੰਟ ’ਤੇ ਨਹੀਂ, ਰਾਊਟਰ ’ਤੇ ਪਰਖੋ।

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

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

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

ਸਰੋਤ ਲਈ ਪਹੁੰਚ ਨਿਯਮ ਪੜ੍ਹੋ

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

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

ਸਥਿਤੀ ਆਉਟਪੁੱਟ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਪਤਿਆਂ ਅਤੇ ਉਹਨਾਂ ਪੀਅਰਾਂ ਦੀ ਪਛਾਣ ਕਰਦੀ ਹੈ ਜੋ ਉਹ ਵੇਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਨੀਤੀ ਦੇ ਸਰੋਤ-ਚੋਣਕਾਰ ਨੂੰ ਇਹਨਾਂ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ। tailscale ping ਆਪ ਸਬਨੈੱਟ ਰਾਊਟਰ ਤੱਕ tailnet ਮਾਰਗ ਸਾਬਤ ਕਰਦਾ ਹੈ; ਇਹ ਪੀਅਰ ਨਾਂ ਅਤੇ tailnet ਪਤੇ ਹੱਲ ਕਰਦਾ ਹੈ, ਐਲਾਨੇ ਸਬਨੈੱਟ ਦੇ ਅੰਦਰਲੇ ਹੋਸਟ ਨਹੀਂ। ਤੀਜਾ ਕਮਾਂਡ ਸਬਨੈੱਟ ਰੂਟ ਰਾਹੀਂ ਆਮ ICMP ਗੂੰਜ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਦਾ ਨਤੀਜਾ ਰਾਊਟਰ ਦੀ ਥਾਂ ਮੰਜ਼ਿਲ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। tailnet-ਪੱਧਰ ਦਾ ਇਨਕਾਰ ਆਮ ਤੌਰ ’ਤੇ ਇਨਕਾਰ ਵਜੋਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਨਿਕਲ ਕੇ ਕਦੇ ਨਾ ਮੁੜਨ ਵਾਲਾ ਪੈਕਟ ਸਮਾਂ-ਸੀਮਾ ਲੰਘਦਾ ਹੈ।

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

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