OpenBSD VPN ਗੇਟਵੇ 'ਤੇ tun0 ਰਾਹੀਂ LAN ਦਾ NAT

ਇੱਕੋ OpenBSD ਗੇਟਵੇ ਵਾਲੇ ਦੋ ਇੰਜੀਨੀਅਰ ਦੂਰ ਦੇ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਤੁਹਾਨੂੰ ਅਕਸਰ ਦੋ ਵੱਖਰੇ ਨਿਯਮ-ਸਮੂਹ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਦੋਵਾਂ ਦਾ ਬਚਾਅ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸਰੋਤ ਅਨੁਵਾਦ ਅਤੇ ਵਾਪਸੀ ਰੂਟ ਵਿਚਕਾਰ ਚੋਣ ਬਿਲਕੁਲ ਵੀ ਵਾਕ-ਰਚਨਾ ਦਾ ਸਵਾਲ ਨਹੀਂ ਹੈ। ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਸਾਹਮਣੇ ਵਾਲਾ ਪਾਸਾ 192.168.88.0/24 ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਕੀ ਜਾਣਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਆਪਣੇ ਲੌਗਾਂ ਵਿੱਚ ਕੀ ਰੱਖਣਾ ਹੈ। ਇੱਥੇ ਗਲਤੀ ਕਰੋ ਤਾਂ nat-to ਲਾਈਨ ਬਿਲਕੁਲ ਸਹੀ ਦਿਸੇਗੀ ਜਦਕਿ ਜਵਾਬ ਦੂਰ ਦੇ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਵਿੱਚ ਗ਼ਾਇਬ ਹੋ ਜਾਣਗੇ।

ਰੂਟਿੰਗ ਅਤੇ ਮੁੜ-ਲਿਖਤ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ

ਰੂਟਿੰਗ ਟੇਬਲ ਫ਼ੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ 172.20.0.0/16 tun0 ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੈ, ਅਤੇ ਇਹ ਫ਼ੈਸਲਾ ਕਿਸੇ ਵੀ pf ਅਨੁਵਾਦ ਨਾਲ ਸਲਾਹ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ। ਫਿਰ ਸਰੋਤ ਅਨੁਵਾਦ ਪੈਕਟ ਹੈਡਰ ਬਦਲਦਾ ਹੈ ਤਾਂ ਜੋ ਦੂਰ ਵਾਲਾ ਸਿਰਾ LAN ਹੋਸਟ ਦੀ ਥਾਂ ਗੇਟਵੇ ਦਾ ਟਨਲ ਪਤਾ ਦੇਖੇ। ਕੋਈ ਵੀ ਕਾਰਜ-ਪ੍ਰਣਾਲੀ ਦੂਜੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੀ: nat ਨਿਯਮ ਰੂਟ ਨਹੀਂ ਬਣਾ ਸਕਦਾ, ਅਤੇ ਰੂਟ ਉਸ ਦੂਰ ਦੇ ਰਾਊਟਰ ਨੂੰ ਨਹੀਂ ਮਨਾ ਸਕਦਾ ਜਿਸਨੇ ਤੁਹਾਡੇ ਨਿੱਜੀ ਸਬਨੈੱਟ ਬਾਰੇ ਕਦੇ ਨਹੀਂ ਸੁਣਿਆ। ਜਦੋਂ ਸਾਹਮਣੇ ਵਾਲੇ ਪਾਸੇ ਵਾਪਸੀ ਦਾ ਰਾਹ ਨਹੀਂ ਹੁੰਦਾ, ਜਵਾਬ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ ਜਾਂ ਉਸਦੇ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਵੱਲ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਨਿਯਮਾਂ ਦੀ ਕਿੰਨੀ ਵੀ ਟਿਊਨਿੰਗ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦੀ।

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

ਫ਼ੈਸਲਾ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ

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

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

ਟੁਕੜੇ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਰੱਖੋ ਕਿ pf ਅਸਲ ਵਿੱਚ ਇਸਦਾ ਮੁਲਾਂਕਣ ਕਰੇ

ਹੇਠਾਂ ਦਿੱਤਾ ਟੁਕੜਾ ਮੰਨਦਾ ਹੈ ਕਿ LAN 192.168.88.0/24 ਹੈ, ਦੂਰ ਦਾ ਨੈੱਟਵਰਕ 172.20.0.0/16 ਹੈ ਅਤੇ ਟਨਲ ਇੰਟਰਫ਼ੇਸ tun0 ਹੈ। ਇਸ ਵਿੱਚ ਕੁਝ ਵੀ ਅਗਲਾ ਹੌਪ ਨਹੀਂ ਚੁਣਦਾ। ਇਹ ਸਿਰਫ਼ ਉਹਨਾਂ ਪੈਕਟਾਂ 'ਤੇ ਸਰੋਤ ਮੁੜ ਲਿਖਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾ ਰਹੇ ਹਨ।

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

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

ਕਰਨਲ ਪਾਸਾ ਨਾ ਭੁੱਲੋ। IPv4 ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਟਨਲ ਤੇ LAN ਲਈ ਸਟੇਟਯੁਕਤ pass ਨਿਯਮ ਇਸ ਸਭ ਦਾ ਅਰਥ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇੱਥੇ ਕੀਵਰਡ ਕ੍ਰਮ ਲਈ OpenBSD FAQ ਦਾ PF NAT ਭਾਗ ਸਹੀ ਹਵਾਲਾ ਹੈ।

ਟ੍ਰੈਫਿਕ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ-ਸਮੂਹ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਪਹਿਲਾਂ pfctl -nf /etc/pf.conf ਨਾਲ ਵਾਕ-ਰਚਨਾ ਜਾਂਚੋ, ਜੋ ਫ਼ਾਈਲ ਨੂੰ ਲੋਡ ਕੀਤੇ ਬਿਨਾਂ ਪਾਰਸ ਕਰਦਾ ਹੈ। ਫਿਰ ਨੀਤੀ ਲੋਡ ਕਰੋ ਅਤੇ ਪੜ੍ਹੋ ਕਿ ਕਰਨਲ ਅਸਲ ਵਿੱਚ ਕੀ ਰੱਖਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਾਫ਼ ਪਾਰਸ ਹੋਇਆ ਨਿਯਮ ਵੀ ਛਾਇਆ ਵਿੱਚ ਰਹਿ ਸਕਦਾ ਹੈ ਜਾਂ ਗਲਤ ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ। pfctl -sn ਅਨੁਵਾਦ ਨਿਯਮਾਂ ਨੂੰ ਲੋਡ ਹੋਏ ਰੂਪ ਵਿੱਚ ਛਾਪਦਾ ਹੈ, ਅਤੇ pfctl -sr ਫਿਲਟਰ ਨਿਯਮਾਂ ਨੂੰ ਮੁਲਾਂਕਣ ਕ੍ਰਮ ਵਿੱਚ ਛਾਪਦਾ ਹੈ।

ਅੱਗੇ ਤਾਰ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ। ਗੇਟਵੇ 'ਤੇ tcpdump -ni tun0 'host 172.20.0.10' ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਟਨਲ ਤੋਂ ਬਾਹਰ ਨਿਕਲਦਾ ਸਰੋਤ ਪਤਾ ਟਨਲ ਪਤਾ ਹੈ ਜਾਂ LAN ਹੋਸਟ। ਤੇਜ਼ netstat -rn -f inet ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਮੰਤਵ ਕਿਹੜੇ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ। ਟ੍ਰੈਫਿਕ ਵਹਿਣਾ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ pfctl -ss ਸਟੇਟ ਐਂਟਰੀਆਂ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ; ਜੇ ਕਿਸੇ ਪ੍ਰਵਾਹ ਨੇ ਸਟੇਟ ਨਹੀਂ ਬਣਾਇਆ, ਤਾਂ ਪੈਕਟ ਕਦੇ ਵੀ ਸਟੇਟ ਬਣਾਉਣ ਵਾਲੇ ਨਿਯਮ ਨਾਲ ਨਹੀਂ ਟਕਰਾਇਆ।

ਜੇ ਟਨਲ ਪਾਸਾ ਸਹੀ ਦਿਸਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਫਿਰ ਵੀ ਨਹੀਂ ਆਉਂਦੇ, ਤਾਂ pf ਸੋਧਣਾ ਬੰਦ ਕਰੋ। ਬਾਕੀ ਨੁਕਸ ਦੂਰ ਦੇ ਰਾਊਟਰ 'ਤੇ ਹੈ, ਜਿੱਥੇ ਜਵਾਬ ਉਸ ਨਿੱਜੀ ਪਤੇ ਵੱਲ ਭੇਜਿਆ ਜਾ ਰਿਹਾ ਹੈ ਜਿਸ ਤੱਕ ਉਹ ਪਾਸਾ ਪਹੁੰਚ ਨਹੀਂ ਸਕਦਾ।

ਜਦੋਂ ਅਨੁਵਾਦ ਬਚਤ ਤੋਂ ਵੱਧ ਖ਼ਰਚ ਕਰਦਾ ਹੈ

ਅਨੁਵਾਦ ਕਲਾਇੰਟ ਲੁਕਾਉਂਦਾ ਹੈ, ਅਤੇ ਕਈ ਵਾਰ ਇਹ ਬਿਲਕੁਲ ਗਲਤ ਸੌਦਾ ਹੁੰਦਾ ਹੈ। ਇੱਕ-ਦੂਜੇ 'ਤੇ ਚੜ੍ਹਦੇ ਸਬਨੈੱਟ ਇੱਕ ਮਾਮਲਾ ਹਨ: ਜੇ ਸਾਹਮਣੇ ਵਾਲਾ ਪਾਸਾ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ 192.168.88.0/24 ਵੀ ਵਰਤਦਾ ਹੈ, ਤਾਂ LAN ਹੋਸਟਾਂ ਨੂੰ ਗੇਟਵੇ ਵਜੋਂ ਪੇਸ਼ ਕਰਨਾ ਟਕਰਾਅ ਨੂੰ ਸੁਧਾਰਨ ਦੀ ਥਾਂ ਹੋਰ ਵਿਗਾੜਦਾ ਹੈ। ਪਤਾ-ਜੋੜੀ ਨਾਲ ਟ੍ਰੈਫਿਕ ਚੁਣਨ ਵਾਲੀਆਂ IPsec ਨੀਤੀਆਂ ਦੂਜਾ ਮਾਮਲਾ ਹਨ, ਕਿਉਂਕਿ ਸੁਰੱਖਿਆ ਨੀਤੀ ਡੇਟਾਬੇਸ ਦਾ ਮਿਲਾਨ ਅਨੁਵਾਦ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਹ ਤੁਹਾਡਾ ਮੁੜ-ਲਿਖਿਆ ਪੈਕਟ ਕਦੇ ਨਹੀਂ ਦੇਖਦਾ। ਹਰ ਤੈਨਾਤੀ ਜੋ ਪ੍ਰਤੀ ਵਰਤੋਂਕਾਰ ਬਿਲ ਕਰਦੀ, ਸੀਮਤ ਕਰਦੀ ਜਾਂ ਆਡਿਟ ਕਰਦੀ ਹੈ, ਉਹ ਵੀ ਉਸ ਪਛਾਣ ਨੂੰ ਗੁਆ ਦਿੰਦੀ ਹੈ ਜਿਸਦੀ ਉਸਨੂੰ ਉਸ ਪਲ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਸਰੋਤ ਇੱਕ ਹੀ ਪਤੇ 'ਤੇ ਸਿਮਟ ਜਾਂਦਾ ਹੈ।

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

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