Tailscale ਸਬਨੈੱਟ SNAT ਬੰਦ ਕਰਨ ਤੋਂ ਬਾਅਦ ਇੱਕ-ਦਿਸ਼ਾਵੀ ਟ੍ਰੈਫਿਕ
Tailscale ਸਬਨੈੱਟ ਰਾਊਟਰ 'ਤੇ SNAT ਬੰਦ ਕਰੋ ਅਤੇ ਜਵਾਬ ਆਉਣੇ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ। ਅਸਲ ਸਰੋਤ ਪਤਾ ਕਾਇਮ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ LAN ਨੂੰ 100.64.0.0/10 ਵੱਲ ਵਾਪਸੀ ਮਾਰਗ ਦੀ ਲੋੜ ਹੈ।
Tailscale ਸਬਨੈੱਟ ਰਾਊਟਰ 'ਤੇ ਸਰੋਤ NAT ਬੰਦ ਕਰੋ, ਸੁਰੰਗ ਕੰਮ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ ਪਰ ਇਸ ਵਿੱਚੋਂ ਲੰਘਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਰੁਕ ਜਾਂਦੇ ਹਨ। ਬੇਨਤੀਆਂ ਮੰਜ਼ਿਲ 'ਤੇ ਦੂਰ ਦੇ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਓਵਰਲੇ ਪਤੇ ਨਾਲ ਪਹੁੰਚਦੀਆਂ ਹਨ, ਜੋ ਇਸ ਬਦਲਾਅ ਦਾ ਮਕਸਦ ਹੀ ਹੈ, ਅਤੇ ਜਵਾਬਾਂ ਨੂੰ ਹੁਣ ਅਜਿਹਾ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ ਜੋ LAN ਨੂੰ ਕਦੇ ਨਹੀਂ ਸੀ ਜਾਣਨਾ। ਉਸ ਮਾਰਗ ਤੋਂ ਬਿਨਾਂ ਪੈਕਟ ਉਤਰਦੇ ਹਨ, ਜਵਾਬ ਆਮ ਗੇਟਵੇ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਨਾਕਾਮੀ ਅਜਿਹੀ ਫਾਇਰਵਾਲ ਸਮੱਸਿਆ ਵਾਂਗ ਦਿਸਦੀ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਫਾਇਰਵਾਲ ਨਿਯਮ ਸਮਝਾਉਂਦਾ ਨਹੀਂ। ਸੁਰੰਗ ਤੰਦਰੁਸਤ ਹੈ; ਵਾਪਸੀ ਵਾਲਾ ਹਿੱਸਾ ਗੁੰਮ ਹੈ।
SNAT ਕੀ ਲੁਕਾ ਰਿਹਾ ਸੀ
SNAT ਚਾਲੂ ਹੋਣ 'ਤੇ ਰਾਊਟਰ ਸਬਨੈੱਟ ਵਿੱਚ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤ ਪਤੇ ਨੂੰ ਆਪਣੇ LAN ਪਤੇ ਵਿੱਚ ਮੁੜ ਲਿਖਦਾ ਹੈ, ਇਸ ਲਈ ਮੰਜ਼ਿਲ ਉਸ ਹੋਸਟ ਨੂੰ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜਿਸਨੂੰ ਉੱਥੇ ਪਹੁੰਚਣਾ ਪਹਿਲਾਂ ਹੀ ਆਉਂਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਸਨੂੰ ਬੰਦ ਕਰਨ ਨਾਲ ਮੂਲ ਸਰੋਤ ਕਾਇਮ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਮੰਜ਼ਿਲ ਫਿਰ ਆਪਣੇ ਤਾਰ 'ਤੇ ਪਏ ਗੁਆਂਢੀ ਦੀ ਥਾਂ ਓਵਰਲੇ ਰੇਂਜ ਅੰਦਰਲਾ ਪਤਾ ਦੇਖਦੀ ਹੈ। ਉਹ ਪਤਾ ਅਸਲੀ ਹੈ ਅਤੇ tailnet ਭਰ ਰੂਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਡਿਫਾਲਟ ਗੇਟਵੇ ਰਾਹੀਂ LAN ਤੋਂ ਉੱਥੇ ਪਹੁੰਚਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ। ਦਸਤਾਵੇਜ਼ੀ ਸਵਿੱਚ --snat-subnet-routes=false ਹੈ, ਜੋ Linux ਸਬਨੈੱਟ ਰਾਊਟਰ 'ਤੇ ਹੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।
ਇਹ ਹਰ ਪੈਕਟ ਦਾ ਟੌਗਲ ਨਹੀਂ ਸਗੋਂ ਪੱਕੀ ਸੈਟਿੰਗ ਹੈ, ਇਸ ਲਈ ਉਹ ਰਾਊਟਰ ਜਿਸ ਵੀ ਮੰਜ਼ਿਲ ਨੈੱਟਵਰਕ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ ਉਸ ਲਈ ਵਾਪਸੀ ਮਾਰਗ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹੀ ਬਦਲਾਅ ਨੂੰ ਚੈੱਕਬਾਕਸ ਦੀ ਥਾਂ ਤੈਨਾਤੀ ਦਾ ਫ਼ੈਸਲਾ ਬਣਾਉਂਦਾ ਹੈ। ਉਸ ਰਾਊਟਰ ਦੀ ਹਰ ਸੇਵਾ ਨੂੰ ਇਹ ਲੋੜ ਉਸੇ ਪਲ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦੀ ਹੈ।
ਵਾਪਸੀ ਮਾਰਗ ਕਿੱਥੇ ਹੋ ਸਕਦਾ ਹੈ
ਤਿੰਨ ਥਾਵਾਂ ਆਮ ਹਨ, ਅਤੇ ਉਹ ਸ਼ੁੱਧਤਾ ਵਿੱਚ ਨਹੀਂ ਸਗੋਂ ਪਹੁੰਚ ਵਿੱਚ ਵੱਖਰੀਆਂ ਹਨ। ਮੰਜ਼ਿਲ ਹੋਸਟ 'ਤੇ ਸਥਿਰ ਮਾਰਗ ਸਭ ਤੋਂ ਸਿੱਧਾ ਅਤੇ ਸਭ ਤੋਂ ਘੱਟ ਵਧਣਯੋਗ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਡਿਵਾਈਸ ਨੂੰ ਆਪਣੀ ਕਾਪੀ ਚਾਹੀਦੀ ਹੈ। VPC ਜਾਂ ਸਾਈਟ ਰਾਊਟਰ ਵਿੱਚ ਮਾਰਗ ਸਾਰਣੀ ਪੂਰੇ ਨੈੱਟਵਰਕ ਨੂੰ ਇਕੱਠੇ ਢਕ ਲੈਂਦੀ ਹੈ, ਅਤੇ ਵਰਗ-ਰਹਿਤ ਸਥਿਰ ਮਾਰਗ ਲੈ ਜਾਣ ਵਾਲਾ DHCP ਵਿਕਲਪ ਕਲਾਇੰਟਾਂ ਤੱਕ ਆਪਣੇ ਆਪ ਪਹੁੰਚਦਾ ਹੈ ਪਰ ਉਹਨਾਂ ਡਿਵਾਈਸਾਂ 'ਤੇ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਅਣਡਿੱਠ ਕਰਦੇ ਹਨ।
ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5
ਤੁਸੀਂ ਕੋਈ ਵੀ ਥਾਂ ਚੁਣੋ, ਅਗਲਾ ਹੌਪ ਰਾਊਟਰ ਦਾ LAN ਪਤਾ ਹੈ ਅਤੇ ਕਦੇ ਵੀ ਉਸਦਾ tailnet ਪਤਾ ਨਹੀਂ। LAN ਹੋਸਟ ਇਹ ਮਾਰਗ ਤੋਂ ਬਿਨਾਂ ਓਵਰਲੇ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ, ਇਸ ਲਈ ਓਵਰਲੇ ਅੰਦਰ ਅਗਲਾ ਹੌਪ ਗੋਲ ਹੈ ਅਤੇ ਪੈਕਟ ਨੂੰ ਕਿਤੇ ਨਹੀਂ ਭੇਜਦਾ। ਇਹੀ ਇੱਕ ਗਲਤੀ ਸਹੀ ਦਿਸਣ ਵਾਲੀਆਂ ਅਤੇ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀਆਂ ਜ਼ਿਆਦਾਤਰ ਸੰਰਚਨਾਵਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਸਿਰਫ਼ ਰਾਊਟਰ ਦੀ ਆਪਣੀ ਸਾਰਣੀ ਪੜ੍ਹਨ ਵਾਲੀ ਹਰ ਜਾਂਚ ਵਿੱਚੋਂ ਲੰਘ ਜਾਂਦੀ ਹੈ। ਤੁਸੀਂ ਕਿਹੜੀ ਥਾਂ ਵਰਤੀ ਲਿਖ ਲਓ, ਨਹੀਂ ਤਾਂ ਅਗਲਾ ਵਿਅਕਤੀ ਗਲਤ ਵਾਲੀ ਦੀ ਜਾਂਚ ਕਰੇਗਾ।
ਨਾਕਾਮੀ ਨੂੰ ਇੱਕ-ਦਿਸ਼ਾਵੀ ਟ੍ਰੈਫਿਕ ਵਜੋਂ ਪੜ੍ਹਨਾ
ਲੱਛਣ ਕਾਰਨ ਨਾਲੋਂ ਪਛਾਣਨਾ ਸੌਖਾ ਹੈ: ਸੇਵਾ ਰਾਊਟਰ 'ਤੇ ਹੀ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਅਤੇ ਦੂਰ ਦੇ ਕਲਾਇੰਟ ਤੋਂ ਚੁੱਪ ਰਹਿੰਦੀ ਹੈ। ਮੰਜ਼ਿਲ 'ਤੇ ਕੈਪਚਰ ਬੇਨਤੀਆਂ ਆਉਂਦੀਆਂ ਅਤੇ ਜਵਾਬ ਜਾਂਦੇ ਦਿਖਾਉਂਦਾ ਹੈ, ਜੋ ਸਫਲਤਾ ਵਾਂਗ ਲੱਗਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਨਾ ਵੇਖੋ ਕਿ ਉਹ ਜਵਾਬ ਕਿੱਥੇ ਜਾ ਰਹੇ ਹਨ। ਉਹ ਡਿਫਾਲਟ ਗੇਟਵੇ ਵੱਲ ਜਾ ਰਹੇ ਹਨ, ਭਾਵ ਆਉਣ ਵਾਲਾ ਹਿੱਸਾ ਕੰਮ ਕਰ ਗਿਆ ਅਤੇ ਵਾਪਸੀ ਵਾਲਾ ਨਹੀਂ।
ਇਸਦੀ ਥਾਂ ਰਾਊਟਰ 'ਤੇ ਕੈਪਚਰ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਅਦਲਾ-ਬਦਲੀ ਦੀਆਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਦੇਖਦਾ ਹੈ ਅਤੇ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਜਵਾਬ ਕਦੇ ਆਇਆ ਜਾਂ ਨਹੀਂ। ਜੇ ਜਵਾਬ ਮੰਜ਼ਿਲ 'ਤੇ ਦਿਸੇ ਪਰ ਰਾਊਟਰ 'ਤੇ ਕਦੇ ਨਾ ਦਿਸੇ, ਤਾਂ ਮਾਰਗ ਮੰਜ਼ਿਲ ਵੱਲ ਗੁੰਮ ਜਾਂ ਗਲਤ ਹੈ। ਜੇ ਇਹ ਰਾਊਟਰ 'ਤੇ ਦਿਸੇ ਅਤੇ ਉੱਥੇ ਹੀ ਰੁਕ ਜਾਵੇ, ਤਾਂ ਸਮੱਸਿਆ ਅੱਗੇ ਹੈ ਅਤੇ ਕਿਸੇ ਹੋਰ ਜਾਂਚ ਦੀ ਹੈ।
sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5
ਕੀ ਅਸਲ ਪਤਾ ਮਾਰਗ ਦੇ ਲਾਇਕ ਹੈ
ਜਦੋਂ ਵੀ ਮੰਜ਼ਿਲ ਨੈੱਟਵਰਕ ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, SNAT ਰੱਖਣਾ ਸੌਖਾ ਜਵਾਬ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਹਰ ਕਲਾਇੰਟ ਮੰਜ਼ਿਲ ਦੇ ਲੌਗ ਅਤੇ ਨੀਤੀ ਵਿੱਚ ਰਾਊਟਰ ਵਾਂਗ ਦਿਸਦਾ ਹੈ। ਇਸਨੂੰ ਬੰਦ ਕਰਨਾ ਤਦ ਜਾਇਜ਼ ਹੈ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਸਲ ਸਰੋਤ ਪਤਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਜਦੋਂ ਨੈੱਟਵਰਕ ਨੀਤੀ ਨੂੰ ਇੱਕੋ ਰਾਊਟਰ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਵਿੱਚ ਫ਼ਰਕ ਕਰਨਾ ਪਵੇ। ਦੋਵੇਂ ਵੈਧ ਕਾਰਨ ਹਨ ਅਤੇ ਕੋਈ ਵੀ ਮੁਫ਼ਤ ਨਹੀਂ। ਲਾਭ ਹਰ ਮੰਜ਼ਿਲ ਨੈੱਟਵਰਕ 'ਤੇ ਮਾਰਗ ਕਾਇਮ ਰੱਖਣ ਅਤੇ ਹੇਠਾਂ ਦੱਸੀ ਫਾਇਰਵਾਲ ਸਮੀਖਿਆ ਦੇ ਲਾਇਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਛੋਟੇ LAN ਲਈ ਇਹ ਅਦਲਾ-ਬਦਲੀ ਆਮ ਤੌਰ 'ਤੇ ਲਾਹੇਵੰਦ ਹੁੰਦੀ ਹੈ, ਪਰ ਸਥਿਰ ਮਾਰਗ ਨਾ ਲੈ ਸਕਣ ਵਾਲੇ ਡਿਵਾਈਸਾਂ ਦੇ ਫੈਲਾਅ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਨਹੀਂ। ਫ਼ੈਸਲਾ ਅਤੇ ਕਾਰਨ ਰਾਊਟਰ ਸੰਰਚਨਾ ਦੇ ਕੋਲ ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਅਗਲੇ ਪ੍ਰਬੰਧਕ ਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਕਿਹੜਾ ਵਿਵਹਾਰ ਜਾਣਬੁੱਝ ਕੇ ਹੈ। ਜਿਸ ਡਿਫਾਲਟ ਨੂੰ ਕਿਸੇ ਨੇ ਨਹੀਂ ਲਿਖਿਆ, ਉਸਨੂੰ ਲਾਪਰਵਾਹੀ ਤੋਂ ਵੱਖ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।
ਫਾਇਰਵਾਲ, ਲੌਗਿੰਗ ਅਤੇ ਦੋਹਰੀ ਭੂਮਿਕਾ
ਰਾਊਟਰ ਦੇ LAN ਪਤੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹਰ ਨਿਯਮ ਹੁਣ ਵੱਖਰੇ ਸਰੋਤ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਇਜਾਜ਼ਤ ਨਿਯਮ ਅਤੇ ਉਹ ਹਰ ਲੌਗ ਖੇਤਰ ਸ਼ਾਮਲ ਹੈ ਜੋ ਰਾਊਟਰ ਨੂੰ ਕਲਾਇੰਟ ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਸੀ। ਉਹ ਨਿਯਮ ਪਹਿਲੀ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਪੜ੍ਹੋ, ਪਹਿਲੀ ਨਾਕਾਮੀ ਤੋਂ ਬਾਅਦ ਨਹੀਂ, ਕਿਉਂਕਿ ਸਿਰਫ਼ ਰਾਊਟਰ ਦੇ ਪਤੇ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਨਵੇਂ ਸਰੋਤ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੋਕਦਾ ਹੈ। ਬਦਲੀ ਨੂੰ ਲੋੜੀਂਦੇ ਕਲਾਇੰਟ ਅਤੇ ਪੋਰਟਾਂ ਤੱਕ ਸੀਮਤ ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਚੁੱਪਚਾਪ ਪੂਰਾ tailnet ਸਵੀਕਾਰ ਨਹੀਂ ਕਰ ਰਿਹਾ।
sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'
ਇੱਕ ਨੋਡ ਦਾ ਇੱਕੋ ਸਮੇਂ ਐਗਜ਼ਿਟ ਨੋਡ ਅਤੇ ਸਬਨੈੱਟ ਰਾਊਟਰ ਹੋਣਾ ਦਸਤਾਵੇਜ਼ੀ ਸੁਮੇਲ ਹੈ ਜੋ ਸਬਨੈੱਟ SNAT ਬੰਦ ਹੋਣ 'ਤੇ ਅੱਪਸਟ੍ਰੀਮ ਟ੍ਰੈਫਿਕ ਡੇਗ ਸਕਦਾ ਹੈ। ਉਹ ਭੂਮਿਕਾਵਾਂ ਵੱਖਰੇ ਨੋਡਾਂ 'ਤੇ ਵੰਡਣ ਨਾਲ ਇਹ ਚੇਤਾਵਨੀ ਹਟ ਜਾਂਦੀ ਹੈ ਅਤੇ ਹਰ ਮਾਰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਨੀਤੀ ਨੂੰ ਇੱਕ ਮਾਲਕ ਮਿਲਦਾ ਹੈ। ਜੇ ਭੂਮਿਕਾਵਾਂ ਇਕੱਠੀਆਂ ਹੀ ਰਹਿਣੀਆਂ ਹੋਣ, ਤਾਂ ਇਸ ਵਿਵਹਾਰ ਦੀ ਉਮੀਦ ਰੱਖੋ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਜਾਂਚ ਕਰੋ। ਮਾਰਗ, ਸਵਿੱਚ ਸੈਟਿੰਗ ਅਤੇ ਭੂਮਿਕਾ ਵੰਡ ਇੱਕ ਹੀ ਨੋਟ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਅਗਲਾ ਕਨੈਕਸ਼ਨ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਉਹ ਇਕੱਠੇ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ।