ਇੱਕ ਡਿਵਾਈਸ ਲਈ ਰਿਵਰਸ SSH: ਲੂਪਬੈਕ ਸਰੋਤਾ ਜਾਂ ਰਾਊਟਡ VPN?
ਉਸ ਡਿਵਾਈਸ ਲਈ ਇੱਕ ਹੀ ਪ੍ਰਬੰਧਨ ਪੋਰਟ ਜੋ ਸਿਰਫ਼ ਬਾਹਰ ਡਾਇਲ ਕਰ ਸਕਦਾ ਹੈ। ਤਿੰਨ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਰਿਵਰਸ ਟਨਲ ਕਾਫ਼ੀ ਹੈ ਜਾਂ ਤੁਹਾਨੂੰ ਅਸਲ ਰਾਊਟਡ ਰਾਹ ਚਾਹੀਦਾ ਹੈ।
ਤੁਹਾਡਾ ਡਿਵਾਈਸ ਕੈਰੀਅਰ NAT ਪਿੱਛੇ ਹੈ, ਇਹ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੱਕ SSH ਸਰਵਰ ਚਲਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਕੋਈ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ। ਜੋ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ ਉਹ ਆਮ ਤੌਰ 'ਤੇ "ਇਸਨੂੰ VPN ਦਿਓ" ਵਜੋਂ ਕਹੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਕਈ ਜਵਾਬਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ ਇੱਕ ਪ੍ਰਬੰਧਕੀ TCP ਪੋਰਟ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਪੂਰੇ ਸਬਨੈੱਟ ਤੱਕ ਰਾਊਟਡ ਰਾਹ, ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੇ ਐਕਸਪੋਜ਼ਰ ਵਾਲੇ ਵੱਖਰੇ ਪ੍ਰੋਜੈਕਟ ਹਨ।
ਰਿਵਰਸ ਟਨਲ ਤੰਗ ਸੰਸਕਰਣ ਦਾ ਚੰਗਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਡਿਵਾਈਸ ਤੁਹਾਡੇ ਹਬ 'ਤੇ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਹਬ ਨੂੰ ਲੂਪਬੈਕ ਪੋਰਟ 'ਤੇ ਸੁਣਨ ਲਈ ਕਹਿੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਪੋਰਟ ਆਪਣੀ ਹੀ SSH ਸੇਵਾ ਵੱਲ ਵਾਪਸ ਭੇਜਦਾ ਹੈ। ਫਿਰ ਪ੍ਰਬੰਧਕ ਜਨਤਕ ਇੰਟਰਨੈੱਟ ਰਾਹੀਂ ਨਹੀਂ, ਹਬ ਰਾਹੀਂ ਸਰੋਤੇ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ।
ਚੋਣ ਤੈਅ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ
ਕਿਸੇ ਵੀ ਸੰਰਚਨਾ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਲਿਖ ਲਓ। ਇਹ ਸੀਮਤ ਪ੍ਰਬੰਧਨ ਪ੍ਰਵੇਸ਼ ਅਤੇ ਨੈੱਟਵਰਕ ਵਿਸਤਾਰ ਵਿਚਕਾਰਲੀ ਸੀਮਾ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਪੰਜ ਲਾਈਨਾਂ ਵਾਲਾ ਟਨਲ ਮਾਲਕ ਰਹਿਤ ਸਮਤਲ ਨੈੱਟਵਰਕ ਬਣ ਜਾਂਦਾ ਹੈ।
| Condition | Reverse tunnel fits | Something else is needed |
|---|---|---|
| How many services must be reachable? | One, or a small fixed set on loopback | Anything that needs many ports or dynamic discovery |
| Who connects, and how are they authenticated? | Named administrators with their own hub accounts | Third parties, or anything needing per-flow audit you do not control |
| Does the device's own LAN need to be reachable? | No | Yes, so a routed VPN or a managed platform is the honest answer |
ਤੀਜੀ ਕਤਾਰ ਉਹੀ ਹੈ ਜਿਸ ਬਾਰੇ ਲੋਕ ਬਹਿਸ ਕਰਦੇ ਹਨ। ਡਿਵਾਈਸ ਦੇ SSH ਪੋਰਟ ਤੱਕ ਟਨਲ ਇਸਦੇ ਗੁਆਂਢੀਆਂ ਨੂੰ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ 'ਤੇ ਨਹੀਂ ਲਿਆਉਂਦਾ, ਅਤੇ ਹੋਰ ਫਾਰਵਰਡਾਂ ਦੀ ਲੜੀ ਰਾਹੀਂ ਇਸਨੂੰ ਅਜਿਹਾ ਦਿਖਣਾ ਨਹੀਂ ਚਾਹੀਦਾ। ਜੇ ਲੋੜ ਸੱਚਮੁੱਚ LAN ਹੈ, ਤਾਂ ਇਹ ਕਹੋ ਅਤੇ ਇਸਦੀ ਥਾਂ ਉਹੀ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਹਬ ਪਾਸਾ: ਸੀਮਤ ਰੀਲੇ ਖਾਤਾ
ਹਰ ਡਿਵਾਈਸ ਨੂੰ ਜਨਤਕ ਕੁੰਜੀ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਨਾਲ ਅਤੇ ਕਿਸੇ ਵੀ ਸੰਵਾਦਾਤਮਕ ਸੈਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਆਪਣਾ ਰੀਲੇ ਖਾਤਾ ਦਿਓ। Match ਬਲਾਕ ਉਸ ਖਾਤੇ ਤੱਕ ਸੀਮਤ ਹੋਣ ਕਰਕੇ ਇਜਾਜ਼ਤ ਛੋਟੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਨਿੱਜੀ ਕੁੰਜੀ ਉਸੇ ਡਿਵਾਈਸ 'ਤੇ ਰਹਿੰਦੀ ਹੈ ਜਿੱਥੇ ਇਸਦੀ ਥਾਂ ਹੈ।
Match User relay-dev-7
AuthenticationMethods publickey
PubkeyAuthentication yes
AllowTcpForwarding remote
PermitListen 127.0.0.1:21022
GatewayPorts no
MaxSessions 0
PermitTTY no
X11Forwarding no
AllowAgentForwarding no
MaxSessions 0 ਦਿਲਚਸਪ ਕਤਾਰ ਹੈ। ਇਹ ਸ਼ੈੱਲ ਅਤੇ ਸਬਸਿਸਟਮ ਸੈਸ਼ਨਾਂ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ ਪਰ ਡਿਵਾਈਸ ਨੂੰ ਲੋੜੀਂਦੀ ਫਾਰਵਰਡਿੰਗ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਚੋਰੀ ਹੋਈ ਕੁੰਜੀ ਨੂੰ ਸੰਵਾਦਾਤਮਕ ਲੌਗਇਨ ਵਿੱਚ ਨਹੀਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ। PermitListen ਹਬ ਪਾਸੇ ਦੇ ਸਰੋਤੇ ਦਾ ਪਤਾ ਅਤੇ ਪੋਰਟ ਪਿੰਨ ਕਰਦਾ ਹੈ, ਅਤੇ GatewayPorts no ਇਸਨੂੰ ਹਬ ਵਾਲੇ ਨੈੱਟਵਰਕ ਲਈ ਖੋਲ੍ਹਣ ਦੀ ਥਾਂ ਲੂਪਬੈਕ 'ਤੇ ਰੱਖਦਾ ਹੈ।
ਮੁੜ ਲੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਭਾਵੀ ਸੰਰਚਨਾ ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਅਜਿਹਾ ਕਰਦਿਆਂ ਦੂਜਾ ਸੈਸ਼ਨ ਖੁੱਲ੍ਹਾ ਰੱਖੋ। Match ਬਲਾਕ ਗਲਤੀ ਨਾਲ ਸਾਰਿਆਂ 'ਤੇ ਲਾਗੂ ਹੋ ਜਾਵੇ, ਜਾਂ ਕਿਸੇ ਵਿਕਲਪ ਦੇ ਨਾਂ ਵਿੱਚ ਟਾਈਪੋ ਹੋਵੇ, ਤਾਂ ਇਹ ਉਸੇ ਬਾਕਸ ਤੋਂ ਆਪਣੇ ਆਪ ਨੂੰ ਬਾਹਰ ਤਾਲਾ ਲਗਾਉਣ ਦਾ ਰਵਾਇਤੀ ਤਰੀਕਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸਖ਼ਤ ਕਰ ਰਹੇ ਹੋ। ਚੱਲ ਰਹੀ ਸੰਰਚਨਾ ਡੰਪ ਕਰੋ ਅਤੇ ਹੁਣੇ ਲਿਖੀ ਫਾਈਲ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਵਿਕਲਪ ਦੁਬਾਰਾ ਪੜ੍ਹੋ। ਧਿਆਨ ਦਿਓ ਕਿ ਵਿਕਲਪ ਸਹਾਇਤਾ ਬਿਲਡਾਂ ਵਿਚਕਾਰ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਨਵੇਂ ਸਰਵਰ ਵਿੱਚ ਸਵੀਕਾਰੀ ਗਈ ਲਾਈਨ ਪੁਰਾਣੇ ਵੱਲੋਂ ਸਿੱਧਾ ਅਣਗੌਲੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
ਡਿਵਾਈਸ ਪਾਸਾ: ਜ਼ੋਰ ਨਾਲ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਫਾਰਵਰਡਿੰਗ
ਡਿਵਾਈਸ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਸਰੋਤੇ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ। ਆਰਗਿਊਮੈਂਟ ਵਿੱਚ ਦੋ ਪਤੇ -R ਵੱਖਰੇ ਅਰਥ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਖੱਬੇ ਤੋਂ ਸੱਜੇ ਪੜ੍ਹਨਾ ਇਹ ਯਾਦ ਰੱਖਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਕਿ ਕਿਹੜਾ ਕਿਹੜਾ ਹੈ।
ssh -NT \
-o ExitOnForwardFailure=yes \
-o ServerAliveInterval=30 \
-o ServerAliveCountMax=3 \
-R 127.0.0.1:21022:127.0.0.1:22 \
[email protected]
ਖੱਬੀ ਜੋੜੀ ਉਹ ਹੈ ਜਿੱਥੇ ਹਬ ਨੂੰ ਸੁਣਨਾ ਚਾਹੀਦਾ ਹੈ। ਸੱਜੀ ਜੋੜੀ ਉਹ ਹੈ ਜਿਸ ਨਾਲ ਡਿਵਾਈਸ ਜੁੜਦਾ ਹੈ ਜਦੋਂ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ, ਜੋ ਡਿਵਾਈਸ ਦੇ ਆਪਣੇ ਪਾਸਿਓਂ ਹੱਲ ਹੁੰਦੀ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਬਦਲਣ ਨਾਲ ਇੱਕ ਅਜਿਹਾ ਟਨਲ ਬਣਦਾ ਹੈ ਜੋ ਸਾਫ਼ ਉੱਪਰ ਆਉਂਦਾ ਹੈ ਅਤੇ ਗਲਤ ਥਾਂ ਭੇਜਦਾ ਹੈ, ਜੋ ਫੇਲ੍ਹ ਹੋਣ ਤੋਂ ਵੀ ਮਾੜਾ ਹੈ।
ExitOnForwardFailure=yes ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤੇ ਨੂੰ ਸਥਾਪਿਤ ਨਾ ਕਰ ਸਕਣ 'ਤੇ ਕਮਾਂਡ ਨੂੰ ਬਾਹਰ ਨਿਕਲਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਰੀਸਟਾਰਟ ਲੂਪ ਅੱਧਾ ਚੱਲਦਾ ਸੈਸ਼ਨ ਛੱਡਣ ਦੀ ਥਾਂ ਤੁਹਾਨੂੰ ਸੱਚ ਦੱਸਦਾ ਹੈ। ਸਥਾਨਕ SSH ਸੇਵਾ ਬਾਅਦ ਵਿੱਚ ਸਿਹਤਮੰਦ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਸ ਬਾਰੇ ਇਹ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਇਸ ਲਈ ਇਸਨੂੰ ਪ੍ਰੋਸੈਸ ਮੈਨੇਜਰ ਅਤੇ ਕਦੇ-ਕਦੇ ਅਸਲ ਕਨੈਕਸ਼ਨ ਜਾਂਚ ਨਾਲ ਜੋੜੋ।
ਵਾਧੂ ਹੌਪ ਤੋਂ ਬਚਣ ਲਈ ਲੂਪਬੈਕ ਸੁਣਨ ਵਾਲੇ ਪਤੇ ਨੂੰ ਕਦੇ ਵੀ ਵਾਈਲਡਕਾਰਡ ਨਾਲ ਨਾ ਬਦਲੋ। ਉਹ ਇੱਕੋ ਬਦਲਾਅ ਪ੍ਰਬੰਧਨ ਰਾਹ ਅਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਪਹੁੰਚਯੋਗ ਪੋਰਟ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੈ, ਅਤੇ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਡੀਬੱਗ ਕਰਦਿਆਂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਰਹਿ ਜਾਂਦਾ ਹੈ। ਜੇ ਸਹਿਕਰਮੀ ਹਬ ਰਾਹੀਂ ਪੋਰਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ, ਤਾਂ ਬਾਈਂਡ ਚੌੜਾ ਕਰਨ ਦੀ ਥਾਂ ਜੰਪ ਸੰਰਚਨਾ ਠੀਕ ਕਰੋ। ਇਸ ਡਿਜ਼ਾਈਨ ਦਾ ਪੂਰਾ ਸੁਰੱਖਿਆ ਤਰਕ ਲੂਪਬੈਕ ਹੈ।
ਹਬ ਰਾਹੀਂ ਪ੍ਰਬੰਧਕ ਪਹੁੰਚ
ਹਬ 'ਤੇ ਆਮ ਖਾਤਾ ਰੱਖਣ ਵਾਲਾ ਪ੍ਰਬੰਧਕ ਇਸ ਰਾਹੀਂ ਫਾਰਵਰਡ ਕੀਤੇ ਪੋਰਟ ਤੱਕ ਛਲਾਂਗ ਲਾ ਸਕਦਾ ਹੈ। ਰੀਲੇ ਖਾਤਾ ਇਸ ਲਈ ਵਰਤਿਆ ਨਹੀਂ ਜਾਂਦਾ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣ ਦਾ ਅਰਥ ਇਹੀ ਹੈ।
ssh -J [email protected] -o HostKeyAlias=device-7 \
-p 21022 [email protected]
ਤੁਹਾਡੇ ਚੁਣੇ ਹੋਏ ਉਪਨਾਮ ਹੇਠ ਡਿਵਾਈਸ ਦੀ ਹੋਸਟ ਕੁੰਜੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਉਹੀ ਕੁੰਜੀ ਲੜੀ ਦੇ ਅੰਤ ਵਿੱਚ ਡਿਵਾਈਸ ਦੀ ਪਛਾਣ ਕਰਦੀ ਹੈ ਅਤੇ ਟਨਲ ਸਿਰਫ਼ ਆਵਾਜਾਈ ਹੈ। ਸਿਰੇ ਤੋਂ ਸਿਰੇ ਤੱਕ ਲੌਗਇਨ ਅਜੇ ਵੀ ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ; ਸਾਂਝੇ ਹਬ 'ਤੇ ਖ਼ਤਮ ਹੋਣ ਵਾਲਾ ਟਨਲ ਆਪਣੇ ਆਪ ਇਸਨੂੰ ਭਰੋਸੇਯੋਗ ਰਾਹ ਨਹੀਂ ਬਣਾਉਂਦਾ।
ਜੀਵਨ ਚੱਕਰ ਦੀ ਮਾਲਕੀ ਲਓ
ਡਿਵਾਈਸ ਕਮਾਂਡ ਨੂੰ ਪ੍ਰੋਸੈਸ ਮੈਨੇਜਰ ਹੇਠ ਠੀਕ ਇੱਕ ਸਰਗਰਮ ਇੰਸਟੈਂਸ ਅਤੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣੀ ਰੀਸਟਾਰਟ ਨੀਤੀ ਨਾਲ ਚਲਾਓ। ਕੀਪਅਲਾਈਵ ਵਿਕਲਪ ਮਰੇ ਹੋਏ ਸਾਥੀ ਦੀ ਪਛਾਣ ਕਰਦੇ ਹਨ; ਉਹ ਬਾਹਰ ਨਿਕਲੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦੁਬਾਰਾ ਜੀਵਤ ਨਹੀਂ ਕਰਦੇ।
ਫਿਰ ਰਿਟਾਇਰਮੈਂਟ ਪ੍ਰਕਿਰਿਆ ਲਿਖੋ। ਹਰ ਡਿਵਾਈਸ ਨੂੰ ਆਪਣਾ ਸਰੋਤਾ ਅਤੇ ਆਪਣੀ ਕੁੰਜੀ ਮਿਲਦੀ ਹੈ, ਇਸ ਲਈ ਡਿਕਮਿਸ਼ਨ ਦਾ ਅਰਥ ਉਹ ਖਾਤਾ ਰੱਦ ਕਰਨਾ ਅਤੇ ਉਹ ਕੁੰਜੀ ਹਟਾਉਣਾ ਹੈ, ਪੂਰੇ ਬੇੜੇ ਵਿੱਚ ਸਾਂਝਾ ਭੇਤ ਘੁੰਮਾਉਣਾ ਨਹੀਂ।
ਆਖ਼ਰ ਵਿੱਚ ਯਾਦ ਰੱਖੋ ਕਿ ਲੂਪਬੈਕ ਤੁਹਾਨੂੰ ਕੀ ਦਿੰਦਾ ਹੈ। ਇਹ ਨੈੱਟਵਰਕ ਐਕਸਪੋਜ਼ਰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਸਾਂਝੇ ਹਬ 'ਤੇ ਹੋਰ ਸਥਾਨਕ ਵਰਤੋਂਕਾਰਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਹਬ ਦੀ ਆਪਣੀ ਪਹੁੰਚ ਨੀਤੀ ਅਜੇ ਵੀ ਸਹੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। sshd_config ਸੰਦਰਭ ਉੱਪਰ ਵਰਤੇ ਗਏ ਹਰ ਵਿਕਲਪ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਣ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਵੀ ਚੌੜਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫਾਰਵਰਡਿੰਗ ਹਿੱਸੇ ਪੂਰੇ ਪੜ੍ਹਨੇ ਚਾਹੀਦੇ ਹਨ।