ਹੋਰ NAT ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਈਵੇਟ LAN ਵਿਚਕਾਰ ਰੂਟ ਕਰੋ
ਓਵਰਲੈਪ ਕਰਦੀ ਪਤਾ ਥਾਂ, ਗੁੰਮ ਵਾਪਸੀ ਮਾਰਗ ਜਾਂ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲੀ ਟਰਾਂਜ਼ਿਟ ਰੂਟਿੰਗ, NAT ਅਤੇ ਟਨਲ ਵਿਚਕਾਰ ਚੋਣ ਤੈਅ ਕਰਦੀ ਹੈ। ਫਾਇਰਵਾਲ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਤਿੰਨੇ ਜਾਂਚੋ।
ਦੋ ਅੰਦਰੂਨੀ ਫਾਇਰਵਾਲ, ਇੱਕ ਪ੍ਰਾਈਵੇਟ ਟਰਾਂਜ਼ਿਟ ਖੰਡ, ਅਤੇ ਹਰ LAN ਦੇ ਕੁਝ ਹੋਸਟਾਂ ਨੂੰ ਦੂਜੇ ਨਾਲ ਗੱਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਦੀ ਬੇਨਤੀ। ਆਮ ਪ੍ਰਤੀਕਿਰਿਆ VPN ਖੜ੍ਹਾ ਕਰਨਾ ਜਾਂ ਦੂਜੀ NAT ਪਰਤ ਜੋੜਨਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ ਸਮੱਸਿਆ ਦੇ ਲਾਇਕ ਹੋਣ ਨਾਲੋਂ ਵੱਧ ਖਰਚ ਕਰਦੀਆਂ ਹਨ। ਸਾਧਾਰਨ ਰੂਟਿੰਗ ਕਾਫ਼ੀ ਹੈ ਜਦੋਂ ਤਿੰਨ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: ਪਤਾ ਰੇਂਜਾਂ ਓਵਰਲੈਪ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਦੋਵੇਂ ਧਿਰਾਂ ਦੂਜੇ LAN ਵਿੱਚ ਟ੍ਰੈਫ਼ਿਕ ਵਾਪਸ ਭੇਜ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਟਰਾਂਜ਼ਿਟ ਖੰਡ ਡੇਟਾ ਲਈ ਪਹਿਲਾਂ ਹੀ ਕਾਫ਼ੀ ਭਰੋਸੇਯੋਗ ਹੈ। ਕੁਝ ਵੀ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਤਿੰਨੇ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਜਵਾਬ ਬਦਲਦੀ ਹੈ।
ਡਿਜ਼ਾਈਨ ਤੈਅ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ
ਪਹਿਲੀ ਸ਼ਰਤ ਪਤਾ ਥਾਂ ਹੈ। ਜੇ ਦੋਵੇਂ LAN ਇੱਕੋ RFC 1918 ਬਲਾਕ ਵਰਤਦੇ ਹਨ, ਤਾਂ ਰੂਟਿੰਗ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦੀ ਅਤੇ ਅਨੁਵਾਦ ਚੋਣਵਾਂ ਨਾ ਰਹਿ ਕੇ ਲਾਜ਼ਮੀ ਹੋ ਜਾਂਦਾ ਹੈ। ਦੂਜੀ ਵਾਪਸੀ ਮਾਰਗ ਹੈ: A ਤੋਂ B ਤੱਕ ਦਾ ਮਾਰਗ ਉਦੋਂ ਤੱਕ ਬੇਕਾਰ ਹੈ ਜਦੋਂ ਤੱਕ B ਨੂੰ ਵੀ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ A ਦੇ LAN ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਣਾ ਹੈ, ਅਤੇ ਅਸਮਾਨ ਗਿਆਨ ਹੀ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ ਜਿਸ ਕਰਕੇ ਰੂਟਡ ਡਿਜ਼ਾਈਨ ਚੁੱਪਚਾਪ ਜਵਾਬ ਛੱਡ ਦਿੰਦਾ ਹੈ।
ਤੀਜੀ ਭਰੋਸਾ ਹੈ। ਰੂਟਿੰਗ ਪੈਕਟ ਲੈ ਜਾਂਦੀ ਹੈ; ਉਨ੍ਹਾਂ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰਦੀ। ਇੱਕ ਇਮਾਰਤ ਦੇ ਅੰਦਰ ਪ੍ਰਾਈਵੇਟ ਟਰਾਂਜ਼ਿਟ ਖੰਡ ਪ੍ਰਦਾਤਾ ਨੂੰ ਸੌਂਪਣ ਜਾਂ ਸਾਂਝੇ ਕੈਂਪਸ ਬੈਕਬੋਨ ਨੂੰ ਪਾਰ ਕਰਨ ਵਾਲੇ ਲਿੰਕ ਨਾਲੋਂ ਵੱਖਰੀ ਗੱਲ ਹੈ। ਜੇ ਖੰਡ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੈ, ਤਾਂ ਜਵਾਬ ਦੋ ਫਾਇਰਵਾਲ ਵਿਚਕਾਰ ਟਨਲ ਹੈ, ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੀ ਰੂਟਿੰਗ ਯੋਜਨਾ ਇਸਦੇ ਅੰਦਰ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।
ਤਿੰਨੇ ਇੱਕੋ ਦਿਸ਼ਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ’ਤੇ ਹੀ ਸਾਧਾਰਨ ਡਿਜ਼ਾਈਨ ਜਿੱਤਦਾ ਹੈ। ਜੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਅਨੁਵਾਦ ਨਾਲ ਢੱਕਣ ਦੀ ਥਾਂ ਉਸ ਸ਼ਰਤ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਠੀਕ ਕਰੋ, ਕਿਉਂਕਿ NAT ਅਸਫਲਤਾ ਲੁਕਾਉਂਦਾ ਹੈ, ਹੱਲ ਨਹੀਂ ਕਰਦਾ।
ਟਰਾਂਜ਼ਿਟ ਨੈੱਟਵਰਕ ’ਤੇ ਰੂਟ ਯੋਜਨਾ ਬਣਾਓ
ਹਰ ਫਾਇਰਵਾਲ ਨੂੰ ਸਾਂਝੇ ਖੰਡ ’ਤੇ ਇੱਕ ਪਤਾ ਦਿਓ ਅਤੇ ਹਰ ਦੂਰ ਦੇ LAN ਲਈ ਇੱਕ ਖਾਸ ਰੂਟ ਜੋੜੋ। ਮੌਜੂਦਾ ਸੰਰਚਨਾ ਵਿੱਚ ਹੋਰ ਕੁਝ ਵੀ ਹਿਲਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਅਤੇ ਖਾਸ ਤੌਰ ’ਤੇ ਇੰਟਰਨੈਟ ਡਿਫ਼ਾਲਟ ਰੂਟ ਉੱਥੇ ਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਹੈ। ਡਿਫ਼ਾਲਟ ਰੂਟ ਨੂੰ ਪੀਅਰ ਫਾਇਰਵਾਲ ਨਾਲ ਬਦਲਣਾ ਹਰ ਅਸੰਬੰਧਿਤ ਮੰਜ਼ਿਲ ਨੂੰ ਟਰਾਂਜ਼ਿਟ ਰਾਹੀਂ ਭੇਜੇਗਾ, ਜੋ ਮੰਗੇ ਗਏ ਬਦਲਾਅ ਨਾਲੋਂ ਕਿਤੇ ਵੱਡਾ ਹੈ। pfSense ਦਾ ਸਟੈਟਿਕ ਰੂਟਿੰਗ ਦਸਤਾਵੇਜ਼ ਉਸ ਪਲੇਟਫਾਰਮ ਲਈ ਉਹੀ ਰੂਟ-ਪਲਸ-ਗੇਟਵੇ ਮਾਡਲ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਜੋ ਵੀ ਫਾਇਰਵਾਲ ਚਲਾਉਂਦੇ ਹੋ ਉਸ ’ਤੇ ਬਰਾਬਰ ਦਾ ਨਿਯੰਤਰਣ ਮੌਜੂਦ ਹੈ।
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
ਫਾਇਰਵਾਲ A 10.30.0.0/24 ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ ਅਤੇ ਫਾਇਰਵਾਲ B 10.40.0.0/24 ਦੀ, ਜਦੋਂ ਕਿ ਦੋਵੇਂ ਟਰਾਂਜ਼ਿਟ ਪਤੇ 192.0.2.0/24 ’ਤੇ ਹਨ। ਹਰ LAN ਹੋਸਟ ਆਪਣੇ ਸਥਾਨਕ ਫਾਇਰਵਾਲ ਨੂੰ ਗੇਟਵੇ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕੋ ਨਵੀਂ ਹਾਲਤ ਹਰ ਪਾਸੇ ਇੱਕ ਰੂਟ ਹੈ। Linux ਆਧਾਰਿਤ ਫਾਇਰਵਾਲ ’ਤੇ ਉਹੀ ਯੋਜਨਾ ਇੰਝ ਦਿਸਦੀ ਹੈ, ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਸਮਰੱਥ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਹੀਂ ਤਾਂ ਰੂਟ ਹੱਲ ਹੋ ਜਾਵੇਗਾ ਪਰ ਪੈਕਟ ਸੁੱਟ ਦਿੱਤਾ ਜਾਵੇਗਾ।
sysctl -w net.ipv4.ip_forward=1 ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1 ip route get 10.40.0.15 traceroute -n 10.40.0.15
ਫਿਲਟਰਿੰਗ ਨੂੰ ਅਨੁਵਾਦ ਤੋਂ ਵੱਖ ਰੱਖੋ
ਰੂਟਿੰਗ ਅਤੇ ਨੀਤੀ ਵੱਖਰੇ ਨਿਯੰਤਰਣ ਹਨ, ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਹੀ ਜ਼ਿਆਦਾਤਰ ਰੂਟਡ ਡਿਜ਼ਾਈਨ ਅਸਲ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਜਿਸ ਇਨਗ੍ਰੈਸ ਸੀਮਾ ਨੂੰ ਪੈਕਟ ਅਸਲ ਵਿੱਚ ਪਾਰ ਕਰਦੇ ਹਨ ਉੱਥੇ ਖਾਸ ਸਰੋਤ, ਮੰਜ਼ਿਲਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, ਅਤੇ ਯਾਦ ਰੱਖੋ ਕਿ WAN ਵਰਗਾ ਇੰਟਰਫ਼ੇਸ ਲੇਬਲ ਨਾਮ ਹੈ, ਭਰੋਸੇ ਬਾਰੇ ਬਿਆਨ ਨਹੀਂ। ਪ੍ਰਾਈਵੇਟ ਟ੍ਰੈਫ਼ਿਕ ਢੋਣ ਵਾਲੇ ਟਰਾਂਜ਼ਿਟ ਪੋਰਟ ’ਤੇ ਪ੍ਰਾਈਵੇਟ ਪਤਾ ਬਲਾਕਿੰਗ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਸਰਗਰਮ ਹੋ ਸਕਦੀ ਹੈ।
ਫਿਰ NAT ਨਾ ਹੋਣ ਦਾ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਅਨੁਵਾਦ ਵੇਖੋ। ਸਵੈਚਾਲਿਤ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਨਿਯਮ ਅਜਿਹੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਮੁੜ ਲਿਖ ਸਕਦੇ ਹਨ ਜੋ ਕਦੇ ਅਨੁਵਾਦ ਲਈ ਨਹੀਂ ਸੀ, ਅਤੇ ਇਹ ਦੂਜੀ ਧਿਰ ਨੂੰ ਆਪਣੀ ਨੀਤੀ ਅਤੇ ਲਾਗ ਲਈ ਲੋੜੀਂਦੇ ਸਰੋਤ ਪਤਿਆਂ ਨੂੰ ਨਸ਼ਟ ਕਰ ਦਿੰਦਾ ਹੈ। ਪੱਕਾ ਕਰੋ ਕਿ ਚੁਣੇ ਗਏ ਫ਼ਲੋ ਆਪਣੇ ਮੂਲ ਪਤੇ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਜਿਸ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਅਜੇ ਲੋੜ ਹੈ ਉਸ ਲਈ ਇੰਟਰਨੈਟ ਅਨੁਵਾਦ ਨਿਯਮ ਅਛੂਤ ਛੱਡੋ।
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
ਜਦੋਂ NAT ਹੀ ਇਮਾਨਦਾਰ ਜਵਾਬ ਹੈ
ਅਨੁਵਾਦ ਆਪਣੀ ਥਾਂ ਉਦੋਂ ਕਮਾਉਂਦਾ ਹੈ ਜਦੋਂ ਪਤਾ ਰੇਂਜਾਂ ਸੱਚਮੁੱਚ ਓਵਰਲੈਪ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਮੁੜ-ਨੰਬਰੀਕਰਨ ਉਪਲਬਧ ਨਹੀਂ, ਜਾਂ ਜਦੋਂ ਨੀਤੀ ਮੰਗਦੀ ਹੈ ਕਿ ਇੱਕ ਧਿਰ ਸਬਨੈੱਟ ਦੀ ਥਾਂ ਇੱਕੋ ਪਤਾ ਵੇਖੇ। ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤੀ ਇੱਕ-ਤੋਂ-ਇੱਕ ਜਾਂ ਪੋਰਟ-ਸੀਮਤ ਮੈਪਿੰਗ ਜਾਣੇ ਨਤੀਜਿਆਂ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਾ ਹੈ, ਕੰਮ ਚਲਾਉਣ ਦਾ ਉਪਾਅ ਨਹੀਂ।
ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਕਹਿਣ ਵਾਲਾ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਦੂਜੀ ਧਿਰ ਹੁਣ ਵੱਖਰੇ ਸਰੋਤ ਨਾ ਵੇਖ ਸਕਦੀ ਹੈ ਨਾ ਫਿਲਟਰ ਕਰ ਸਕਦੀ ਹੈ। ਲਾਗ ਅਨੁਵਾਦ ਕਰਨ ਵਾਲੇ ਪਤੇ ’ਤੇ ਸਿਮਟ ਜਾਂਦੇ ਹਨ, ਪ੍ਰਤੀ-ਹੋਸਟ ਨੀਤੀ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਸਮੱਸਿਆ ਹੱਲ ਕਿਸੇ ਪਲ ਕਿਹੜੇ ਅੰਦਰੂਨੀ ਹੋਸਟ ਕੋਲ ਫ਼ਲੋ ਸੀ ਦੀ ਭਾਲ ਬਣ ਜਾਂਦਾ ਹੈ। ਜੇ ਪ੍ਰਸ਼ਨ ਵਾਲੇ ਟ੍ਰੈਫ਼ਿਕ ਲਈ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਮਾਅਨੇ ਨਹੀਂ ਰੱਖਦਾ, ਤਾਂ NAT ਠੀਕ ਹੈ।
ਜਦੋਂ ਟਰਾਂਜ਼ਿਟ ਆਪ ਹੀ ਗਲਤ ਧਾਰਨਾ ਹੋਵੇ
ਜੇ ਸਾਂਝਾ ਖੰਡ ਕਿਸੇ ਪ੍ਰਦਾਤਾ, ਸਾਂਝੇ ਸਵਿੱਚ ਫੈਬਰਿਕ, ਜਾਂ ਅਜਿਹੇ ਕਿਸੇ ਮਾਰਗ ਰਾਹੀਂ ਲੰਘਦਾ ਹੈ ਜਿੱਥੇ ਕੋਈ ਦੂਜੀ ਧਿਰ ਟ੍ਰੈਫ਼ਿਕ ਪੜ੍ਹ ਸਕਦੀ ਹੋਵੇ, ਤਾਂ ਸਿਰਫ਼ ਰੂਟਿੰਗ ਪੂਰਾ ਜਵਾਬ ਨਹੀਂ। ਦੋ ਫਾਇਰਵਾਲ ਵਿਚਕਾਰ ਟਨਲ ਤੁਹਾਨੂੰ ਗੁਪਤਤਾ ਅਤੇ ਪੀਅਰ ਪਰਮਾਣਿਕਤਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਅੰਦਰ ਦੀ ਰੂਟ ਸਾਰਣੀ ਉਹੀ ਸਾਰਣੀ ਹੈ ਜੋ ਤੁਸੀਂ ਟਰਾਂਜ਼ਿਟ ’ਤੇ ਲਿਖਦੇ।
ਇਹ ਪਹਿਲੇ ਭਾਗ ਦੇ ਭਰੋਸੇ ਵਾਲੇ ਪ੍ਰਸ਼ਨ ਤੋਂ ਤੈਅ ਕਰੋ, VPN ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਹੁੰਦੇ ਹਨ ਦੀ ਆਦਤ ਤੋਂ ਨਹੀਂ। ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਾਈਵੇਟ ਖੰਡ ’ਤੇ ਟਨਲ ਬਿਨਾਂ ਕਿਸੇ ਲਾਭ ਦੇ ਸੰਚਾਲਨ ਖਰਚ ਅਤੇ ਇੱਕ ਹੋਰ ਅਸਫਲਤਾ ਢੰਗ ਜੋੜਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲੇ ਖੰਡ ’ਤੇ ਰੂਟਿੰਗ ਗੁਪਤਤਾ ਨੂੰ ਅਜਿਹੀ ਸਾਦਗੀ ਨਾਲ ਬਦਲ ਦਿੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਝੱਲ ਨਹੀਂ ਸਕਦੇ। ਤਿੰਨ ਸ਼ਰਤਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਚੋਣ ਦਾ ਕਾਰਨ ਬਣੀ ਲਿਖ ਲਓ, ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਨੂੰ ਦੁਬਾਰਾ ਬਹਿਸ ਨਹੀਂ ਕਰਨੀ ਪਵੇਗੀ।