ਇੱਕ OpenVPN ਪੋਰਟ, ਤਿੰਨ ਸੇਵਾਵਾਂ: ਅੰਦਰੂਨੀ ਪੋਰਟ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ

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

ਬਾਹਰੀ ਪ੍ਰਵਾਹ ਕੀ ਢੋਂਦਾ ਹੈ, ਅਤੇ ਕੀ ਲੁਕਾਉਂਦਾ ਹੈ

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

ਇਸ ਲਈ WAN ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਕੈਪਚਰ ਤਿੰਨ ਨਹੀਂ, ਇੱਕ ਗੱਲਬਾਤ ਦਿਖਾਉਂਦਾ ਹੈ। ਅੰਦਰੂਨੀ ਪੋਰਟ ਸਿਰਫ਼ ਡੀਕੈਪਸੂਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਦਿਸਦੇ ਹਨ। ਇਸੇ ਲਈ ਇੱਕ ਫਾਇਰਵਾਲ ਖੁੱਲ੍ਹ SSH, HTTPS ਅਤੇ DNS ਇੱਕੋ ਸਮੇਂ ਢੋ ਸਕਦੀ ਹੈ।

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP ਦਸਤਾਵੇਜ਼ ਉਸ ਹੈਂਡਓਫ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਰੂਟ ਕੀਤਾ TUN ਡਿਵਾਈਸ ਕਰਨਲ ਅਤੇ ਵਰਤੋਂਕਾਰ ਸਪੇਸ ਪ੍ਰਕਿਰਿਆ ਵਿਚਕਾਰ IP ਪੈਕੇਟ ਦਿੰਦਾ ਹੈ। ਉਹੀ ਹੈਂਡਓਫ ਅੰਦਰੂਨੀ ਹੈਡਰ ਨੂੰ ਗੇਟਵੇ ਦੇ ਰੂਟਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਕੋਡ ਲਈ ਦਿਸਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਇਹ ਵੀ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ ਬਾਹਰੀ ਪੋਰਟ ਕਿਹੜੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਇਜਾਜ਼ਤ ਹੈ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

NAT ਫਾਰਵਰਡ ਸਰੋਤੇ ਦਾ ਹੈ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਦਾ ਨਹੀਂ

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

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

ਪਹੁੰਚ ਅਸਲ ਵਿੱਚ ਅੰਦਰੂਨੀ ਨੀਤੀ ਵਿੱਚ ਤੈਅ ਹੁੰਦੀ ਹੈ

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

ਟਨਲ ਰਾਹੀਂ ਹਰ ਸੇਵਾ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ਤੇ ਜਾਂਚੋ। ਸਫਲ ਖੋਜ ਵੈੱਬ ਪੋਰਟ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ, ਅਤੇ ਸਫਲ ਵੈੱਬ ਬੇਨਤੀ SSH ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ।

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

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

WireGuard ਉਹੀ ਰੇਖਾ ਖਿੱਚਦਾ ਹੈ

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

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

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