ਜਦੋਂ ਹੋਸਟ ਬਾਹਰ ਜਾਣ ਵਾਲਾ VPN ਚਲਾਉਂਦਾ ਹੈ ਤਾਂ ਸਥਾਨਕ SSH ਰੱਖੋ

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

ਹੇਠਾਂ ਦਿੱਤੇ ਕਦਮ ਮੰਨਦੇ ਹਨ ਕਿ ਪ੍ਰਸ਼ਾਸਕ ਉਸੇ LAN 'ਤੇ ਹੈ।ਦੂਰਸਥ ਪ੍ਰਸ਼ਾਸਨ ਵੱਖਰੇ ਜਵਾਬ ਵਾਲੀ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹੈ।

SSH ਨੂੰ ਉਸ ਪਤੇ 'ਤੇ ਬੰਨ੍ਹੋ ਜੋ ਪ੍ਰਸ਼ਾਸਕ ਵਰਤਦੇ ਹਨ

ਲਿਸਨਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ।ss -ltnp | grep :22 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ sshd ਕਿਸ ਨਾਲ ਬੱਝਾ ਹੈ, ਅਤੇ 0.0.0.0 'ਤੇ ਲਿਸਨਰ ਸੁਰੰਗ ਸਮੇਤ ਹਰ ਇੰਟਰਫੇਸ ਤੋਂ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। LAN ਪਤੇ 'ਤੇ ਬੰਨ੍ਹਣਾ ਵਧੇਰੇ ਸੰਕਟਣ ਹੈ ਅਤੇ ਮਨਸਾ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:ListenAddress 192.168.10.20 ਵਿੱਚ sshd_config, ਫਿਰ ਕਨਫਿਗਰੇਸ਼ਨ ਜਾਂਚ ਅਤੇ ਮੁੜ ਲੋਡ। ਉਸ ਪਤੇ ਵਿੱਚ ਟਾਈਪੋ ਵਾਈਲਡਕਾਰਡ ਤੋਂ ਵਧੇਰੇ ਦਿਸਦਾ ਹੈ, ਕਿਉਂਕਿ ਪਤਾ ਨਾ ਹੋਣ 'ਤੇ sshd ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ।

ਹੋਸਟ-ਕੁੰਜੀ ਜਾਂਚ ਅਤੇ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਬਿਲਕੁਲ ਜਿਵੇਂ ਹਨ ਤਿਵੇਂ ਰੱਖੋ। “ਇਹ ਸਿਰਫ਼ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਹੈ” ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ ਨਹੀਂ ਹੈ, ਅਤੇ ਮਾਰਗ ਛੋਟਾ ਹੋਣ ਕਰਕੇ ਕੁੰਜੀ ਜਾਂਚ ਛੱਡਣ ਵਾਲਾ ਪ੍ਰਬੰਧਨ ਚੈਨਲ ਦੁਰਵਰਤੋਂ ਦੀ ਉਡੀਕ ਕਰਨ ਵਾਲਾ ਚੈਨਲ ਹੈ। DHCP ਰਿਜ਼ਰਵੇਸ਼ਨ ਜਾਂ ਸਥਿਰ ਪਤਾ ਟਾਰਗਟ ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਇਸ ਨੂੰ ਸਰਵਰ ਦੀ ਜਨਤਕ ਪਛਾਣ ਬਣਾਏ ਬਿਨਾਂ।

LAN ਮਾਰਗ ਨੂੰ ਸੁਰੰਗ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

192.168.10.0/24 'ਤੇ ਪਤਾ ਵਾਲੇ ਹੋਸਟ ਕੋਲ ਉਸ ਪ੍ਰੀਫਿਕਸ ਲਈ ਜੁੜਿਆ ਮਾਰਗ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਸੇ ਟੇਬਲ ਵਿੱਚ ਵਧੇਰੇ ਖਾਸ ਮਾਰਗ VPN ਦੇ ਡਿਫਾਲਟ ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ। ਇਸੇ ਲਈ ਸੁਰੰਗ ਉੱਪਰ ਆਉਣ 'ਤੇ ਸਥਾਨਕ SSH ਅਕਸਰ ਆਪਣੇ ਆਪ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ। ਅਨੁਮਾਨ ਲਾਉਣ ਦੀ ਥਾਂ ਇਸ ਦੀ ਜਾਂਚ ਕਰੋ:ip route get 192.168.10.50 ਕਰਨਲ ਜੋ ਇੰਟਰਫੇਸ ਅਤੇ ਸਰੋਤ ਪਤਾ ਵਰਤੇਗਾ ਉਸ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਸੁਰੰਗ ਨਹੀਂ ਸਗੋਂ LAN ਡਿਵਾਈਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪ੍ਰਸ਼ਾਸਕ ਦੀ ਮਸ਼ੀਨ ਤੋਂ ਵੀ ਜਾਂਚ ਨੂੰ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਪੈਕਟ ਪਹੁੰਚਦੇ ਹਨ ਜਾਂ ਨਹੀਂ ਇਹ ਉਸ ਦੀ ਆਪਣੀ ਟੇਬਲ ਤੈਅ ਕਰਦੀ ਹੈ। ਇੱਕੋ ਤਾਰ 'ਤੇ ਦੋ ਹੋਸਟ ਕਿਹੜੀ ਦਿਸ਼ਾ ਪਹੁੰਚਯੋਗ ਹੈ ਇਸ 'ਤੇ ਅਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ।

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

ਰਾਊਟ ਕੀਤੇ ਪ੍ਰਬੰਧਨ VLAN ਦੂਜਾ ਮਾਮਲਾ ਹਨ। ਜੇ ਪ੍ਰਸ਼ਾਸਕ ਸਥਾਨਕ ਰਾਊਟਰ ਪਿੱਛੇ 192.168.50.0/24 'ਤੇ ਬੈਠਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਨੂੰ ਉਸ ਪ੍ਰੀਫਿਕਸ ਲਈ 192.168.10.1 ਰਾਹੀਂ ਸਪਸ਼ਟ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹ ਮਾਰਗ ਮੁੜ ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਟਿਕਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਪਵਾਦ ਨੂੰ ਪ੍ਰਬੰਧਨ ਪ੍ਰੀਫਿਕਸ ਤੱਕ ਹੀ ਖਾਸ ਰੱਖੋ; ਨਿੱਜੀ ਰੇਂਜਾਂ ਲਈ ਵਿਆਪਕ ਅਪਵਾਦ ਸੁਰੰਗ ਦਾ ਮਕਸਦ ਨਕਾਰ ਦਿੰਦਾ ਹੈ।

ਫਾਇਰਵਾਲ ਅਪਵਾਦ ਨੂੰ ਨਿਯਮ ਜਿੰਨਾ ਹੀ ਸੰਕਟਣ ਬਣਾਓ

ਜੇ ਹੋਸਟ 'ਤੇ ਫਾਇਰਵਾਲ ਚੱਲਦਾ ਹੈ, ਤਾਂ SSH ਨੂੰ ਸਿਰਫ਼ ਪ੍ਰਬੰਧਨ ਸਰੋਤ ਤੋਂ ਅਤੇ ਸਿਰਫ਼ LAN ਇੰਟਰਫੇਸ 'ਤੇ ਮਨਜ਼ੂਰੀ ਦਿਓ। ਜੋ ਨਿਯਮ 22 ਪੋਰਟ ਨੂੰ ਹਰ ਥਾਂ ਤੋਂ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ ਉਹ ਲੋੜ ਤੋਂ ਵਿਆਪਕ ਹੈ ਅਤੇ ਸਮੀਖਿਆ ਵਿੱਚ ਜਾਇਜ਼ ਠਹਿਰਾਉਣਾ ਔਖਾ ਹੈ। nftables ਹੋਸਟ 'ਤੇ ਨਿਯਮ ਇੰਟਰਫੇਸ ਅਤੇ ਸਰੋਤ ਮਿਲਾ ਕੇ ਇਨਪੁਟ ਚੇਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ; iptables ਹੋਸਟ 'ਤੇ ਬਰਾਬਰ -i ਅਤੇ-s 'ਤੇ ਦੋ ਮੇਲਾਂ ਦੀ ਜੋੜੀ ਹੈ। ਨਿਯਮ 'ਤੇ ਉਸ ਪ੍ਰਸ਼ਾਸਕ ਸਮੂਹ ਦੀ ਟਿੱਪਣੀ ਲਿਖੋ ਜਿਸ ਦੀ ਇਹ ਸੇਵਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਅਗਲੀ ਆਡਿਟ ਨੂੰ 22 ਪੋਰਟ ਕਿਉਂ ਖੁੱਲ੍ਹਾ ਹੈ ਦਾ ਅਨੁਮਾਨ ਨਾ ਲਾਉਣਾ ਪਵੇ।

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

ਦੋਵੇਂ ਹਾਲਤਾਂ ਦੀ ਜਾਂਚ ਕਰੋ

ਜਾਂਚ ਦੋ ਵਾਰ ਚਲਾਓ: ਇੱਕ ਵਾਰ ਸੁਰੰਗ ਜੁੜੀ ਹੋਣ 'ਤੇ ਅਤੇ ਇੱਕ ਵਾਰ ਕੱਟੀ ਹੋਣ 'ਤੇ। ਹਰ ਹਾਲਤ ਵਿੱਚ ਲਿਸਨਰ, ਮਾਰਗ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕ ਦੀ ਮਸ਼ੀਨ ਤੋਂ ਅਸਲ SSH ਲੌਗਇਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਜੋ ਮਾਰਗ ਸਿਰਫ਼ ਸੁਰੰਗ ਉੱਪਰ ਹੋਣ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ ਸਥਾਨਕ ਪ੍ਰਬੰਧਨ ਮਾਰਗ ਨਹੀਂ; ਉਹ ਸੰਜੋਗ ਹੈ।

ਫਿਰ SSH ਸੈਸ਼ਨ ਖੁੱਲ੍ਹਾ ਹੋਣ ਦੌਰਾਨ ਸੁਰੰਗ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ। ਜੋ ਸੈਸ਼ਨ ਟਿਕਦਾ ਹੈ ਉਹ ਰਾਊਟਿੰਗ ਸਥਿਰ ਹੋਣ ਦਾ ਸਬੂਤ ਹੈ; ਜੋ ਸੈਸ਼ਨ ਡਿੱਗਦਾ ਹੈ ਉਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਮੁੜ ਕਨੈਕਸ਼ਨ 'ਤੇ ਮਾਰਗ ਜਾਂ ਫਿਲਟਰ ਮੁੜ ਲਿਖ ਰਿਹਾ ਹੈ, ਜੋ ਘਟਨਾ ਵੇਲੇ ਨਹੀਂ ਸਗੋਂ ਪਹਿਲਾਂ ਜਾਣਨਾ ਚਾਹੀਦਾ ਹੈ।

ਤੁਸੀਂ ਜਿਸ ਸਰੋਤ ਪਤੇ ਤੋਂ ਜਾਂਚ ਕੀਤੀ ਉਸ ਨੂੰ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ 192.168.10.50 ਲਈ ਲਿਖਿਆ ਨਿਯਮ ਪ੍ਰਸ਼ਾਸਕ ਦਾ ਲੈਪਟਾਪ ਦੂਜੇ ਸਬਨੈੱਟ ਵਿੱਚ ਜਾਣ 'ਤੇ ਚੁੱਪਚਾਪ ਅਸਫਲ ਹੁੰਦਾ ਹੈ।

ਰਿਕਵਰੀ ਮਾਰਗ runbook ਵਿੱਚ ਲਿਖੋ

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

ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਦੋਵੇਂ ਭੂਮਿਕਾਵਾਂ ਵੱਖਰੀਆਂ ਰੱਖੋ: ਨੇੜਲੇ ਪ੍ਰਸ਼ਾਸਕ ਲਈ ਸਥਾਨਕ SSH, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਟ੍ਰੈਫਿਕ ਲਈ ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਸੁਰੰਗ। ਜਦੋਂ ਇਹ ਭੂਮਿਕਾਵਾਂ ਲਿਖੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਭਵਿੱਖ ਵਿੱਚ ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਦੀ ਜਾਂਚ ਲਈ ਸਪਸ਼ਟ ਥਾਂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ VPN ਵਾਲਾ ਸਰਵਰ ਅਜੇ ਵੀ ਆਪਣੇ LAN ਪਤੇ 'ਤੇ ਕਿਉਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਇਹ ਮੁੜ ਲੱਭਣਾ ਨਹੀਂ ਪੈਂਦਾ।