ਸਰੋਤ-ਪੋਰਟ ਨਿਯਮ ਤੁਹਾਡੇ ਇੱਕ SSH ਰਾਹ ਨੂੰ ਕਿਉਂ ਤੋੜਦਾ ਹੈ

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

ਦੋ ਐਂਟਰੀਆਂ, ਇੱਕ ਸੇਵਾ ਪੋਰਟ

ਹੋਸਟ ਕੋਲ LAN ਪਾਸੇ ਦਾ ਪਤਾ ਅਤੇ VPN ਪਤਾ ਹੈ, ਅਤੇ sshd ਦੋਵਾਂ ਉੱਤੇ ਸੁਣਦਾ ਹੈ। ਇਸ ਲਈ ਸਿੱਧਾ ਸੈਸ਼ਨ ਅਤੇ ਸੁਰੰਗ ਸੈਸ਼ਨ ਸੇਵਾ ਪੋਰਟ ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਇਸ ਵਿੱਚ ਵੱਖਰੇ ਹਨ ਕਿ ਕਿਹੜਾ ਸਥਾਨਕ ਪਤਾ ਕਨੈਕਸ਼ਨ ਲੈਂਦਾ ਹੈ।

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

ਹਰ ਐਂਟਰੀ ਨੂੰ ਆਪਣਾ ਪੋਰਟ ਦੇਣਾ ਵੀ ਕੰਮ ਕਰੇਗਾ, ਅਤੇ ਇਸ ਨੂੰ ਲੋੜ ਮੰਨਣਾ SSH ਦਾ ਗੁਣ ਨਹੀਂ ਸਗੋਂ ਡਿਜ਼ਾਈਨ ਦੀ ਚੋਣ ਹੈ।

ਨਿਯਮ ਪੜ੍ਹੋ, ਫਿਰ ਸਾਰਣੀ

ਨੀਤੀ ਨਿਯਮ ਇੱਕ ਕ੍ਰਮਬੱਧ ਚੋਣਕਾਰ ਹੈ, ਅਤੇ ਵਰਤੋਂਯੋਗ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਪਹਿਲਾ ਨਿਯਮ ਖੋਜ ਖ਼ਤਮ ਕਰਦਾ ਹੈ। ਸੂਚੀ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ ਅਤੇ ਧਿਆਨ ਦਿਓ ਕਿ ਕਿਹੜਾ ਨਿਯਮ ਜਿੱਤ ਸਕਦਾ ਹੈ।

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

ip -4 rule show
ip route show table 100
ip route show table main

ਇਹ ਦੋਵੇਂ ਆਉਟਪੁੱਟ ਮਿਲ ਕੇ ਨਤੀਜਾ ਸਮਝਾਉਂਦੇ ਹਨ; ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਕੱਲਾ ਗਲਤ ਸਿੱਟੇ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ।

ਨਿਯਮ ਨੂੰ ਉਸੇ ਪ੍ਰਵਾਹ ਤੱਕ ਸੀਮਤ ਕਰੋ ਜਿਸ ਦਾ ਤੁਹਾਡਾ ਭਾਵ ਹੈ

ਦੋਵੇਂ ਐਂਟਰੀਆਂ ਨੂੰ ਵੱਖ ਕਰਨ ਵਾਲਾ ਗੁਣ ਸਥਾਨਕ ਸਰੋਤ ਪਤਾ ਹੈ। ਉਸ ਪਤੇ ਨਾਲ ਮੇਲ ਖਾਣ ਵਾਲਾ ਨਿਯਮ ਸਿਰਫ਼ ਸੁਰੰਗ ਸੈਸ਼ਨਾਂ ਨੂੰ ਨਿੱਜੀ ਸਾਰਣੀ ਵੱਲ ਭੇਜਦਾ ਹੈ ਅਤੇ ਸਿੱਧੇ ਸੈਸ਼ਨਾਂ ਨੂੰ ਮੁੱਖ ਸਾਰਣੀ ਉੱਤੇ ਛੱਡਦਾ ਹੈ।

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

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

ਸਰੋਤਾ, ਇਜਾਜ਼ਤ ਅਤੇ ਜਵਾਬ-ਚੋਣ ਵੱਖਰੇ ਰੱਖੋ

ਸੈਸ਼ਨ ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਸੱਚ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਪਤਾ ਮੌਜੂਦ ਹੈ, ਸੇਵਾ ਉਸ ਉੱਤੇ ਸੁਣਦੀ ਹੈ, ਅਤੇ ਜਵਾਬ ਵਾਪਸੀ ਦਾ ਰਾਹ ਲੱਭਦਾ ਹੈ। ਰੂਟ ਬਦਲਾਅ ਸਿਰਫ਼ ਤੀਜੀ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ।

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

ਉਹ ਰਿਕਵਰੀ ਚੈਨਲ ਰੱਖੋ ਜੋ ਤੁਹਾਡੇ ਬਦਲ ਰਹੇ ਰਾਹ ਉੱਤੇ ਨਿਰਭਰ ਨਾ ਹੋਵੇ, ਕਿਉਂਕਿ ਇੱਥੋਂ ਦੀ ਗਲਤੀ ਸੁਧਾਰ ਨੂੰ ਹੀ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ।

ਇਹ ਪੁਰਾਣੇ ਨਹੀਂ, ਨਵੇਂ ਸੈਸ਼ਨ ਨਾਲ ਸਾਬਤ ਕਰੋ

ਸਥਾਪਿਤ ਟਰਮੀਨਲ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਇਹ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸਵੀਕਾਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਹਰ ਇੱਛਤ ਐਂਟਰੀ ਰਾਹੀਂ ਨਵਾਂ ਸੈਸ਼ਨ ਖੋਲ੍ਹੋ।

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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