ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਬਨਾਮ ਰਿਮੋਟ ਐਕਸੈਸ VPN: ਦੋਵੇਂ ਕੀ ਜੋੜਦੇ ਹਨ
ਇੱਕ ਗੇਟਵੇ ਜੋੜਦਾ ਹੈ, ਦੂਜਾ ਡਿਵਾਈਸ ਜੋੜਦਾ ਹੈ। ਟ੍ਰੈਫਿਕ ਚੋਣਕਾਰਾਂ ਦੀ ਰੂਟ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਐਡਰੈਸਿੰਗ ਦੀ ਯੋਜਨਾ ਬਣਾਓ, ਫਿਰ ਅਸਲੀ ਹੋਸਟ ਤੋਂ ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਨੀਤੀ ਦੀ ਜਾਂਚ ਕਰੋ।
ਦੋਵੇਂ ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ VPN ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੇ ਹਨ। ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਟਨਲ ਦੋ ਗੇਟਵੇ ਜੋੜਦੀ ਹੈ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਪਿੱਛੇ ਦਾ ਹਰ ਹੋਸਟ ਕੁਝ ਵੀ ਇੰਸਟਾਲ ਕੀਤੇ ਬਿਨਾਂ ਦੂਜੇ ਪਾਸੇ ਦੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪਤਿਆਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਰਿਮੋਟ-ਐਕਸੈਸ ਟਨਲ ਵੱਖਰੇ ਡਿਵਾਈਸਾਂ ਨੂੰ ਇੱਕ ਨੈੱਟਵਰਕ ਨਾਲ ਜੋੜਦੀ ਹੈ, ਇੱਕ ਸਮੇਂ ਇੱਕ ਕਲਾਇੰਟ। ਇਹ ਤੁਲਨਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਤੈਨਾਤੀ ਗਲਤੀਆਂ ਇੱਕ ਨੂੰ ਕਨਫਿਗਰ ਕਰਕੇ ਦੂਜੇ ਦੇ ਵਿਵਹਾਰ ਦੀ ਉਮੀਦ ਕਰਨ ਨਾਲ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਲੱਛਣ ਆਮ ਤੌਰ ’ਤੇ ਉਸ ਸੇਵਾ ਵਿੱਚ ਸਮਾਂ ਖਤਮ ਹੋਣਾ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਟਨਲ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚੀ ਸੀ।
ਦੋ ਡਿਜ਼ਾਈਨ, ਦੋ ਸੀਮਾਵਾਂ
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
ਕੋਈ ਵੀ ਡਿਜ਼ਾਈਨ LAN ਬਰਾਡਕਾਸਟ ਡੋਮੇਨ ਨੂੰ ਨਹੀਂ ਵਧਾਉਂਦਾ। ਦੂਰ ਵਾਲੇ ਪਾਸੇ ਦੇ ਡਿਵਾਈਸ ਸਥਾਨਕ ਖੋਜ ਸੂਚੀ ਵਿੱਚ ਨਹੀਂ ਦਿਸਦੇ, ਅਤੇ ਅਜਿਹੀ ਉਮੀਦ ਕਰਨਾ ਪਹਿਲੀ ਧਾਰਨਾ ਹੈ ਜੋ ਛੱਡਣੀ ਚਾਹੀਦੀ ਹੈ। ਤੁਸੀਂ ਜਾਣਬੁੱਝ ਕੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਨਿੱਜੀ DNS ਨਾਮ ਕਿਸੇ ਵੀ ਖੋਜ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲੋਂ ਵੱਧ ਅਨੁਮਾਨਯੋਗ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਪਲਾਇਰ ਬਦਲਣ ’ਤੇ ਵੀ ਟਿਕਦੇ ਹਨ।
ਇੱਕ ਸਾਈਟ ’ਤੇ 10.10.0.0/24 ਅਤੇ ਦੂਜੀ ’ਤੇ 10.20.0.0/24 ਲਓ। ਗੇਟਵੇ A ਨੂੰ ਰੂਟ ਜਾਂ ਟ੍ਰੈਫਿਕ ਚੋਣਕਾਰ ਚਾਹੀਦਾ ਹੈ ਜੋ 10.20.0.0/24 ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਟਨਲ ਵਿੱਚ ਭੇਜੇ, ਅਤੇ ਗੇਟਵੇ B ਨੂੰ ਉਸਦਾ ਸ਼ੀਸ਼ਾ-ਰੂਪ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਦੋਵਾਂ ਪਾਸਿਆਂ ਦੇ ਹੋਸਟ ਆਮ IP ਕਨੈਕਟੀਵਿਟੀ ਵਰਤਦੇ ਹਨ ਅਤੇ ਕਦੇ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਟਨਲ ਮੌਜੂਦ ਹੈ। ਇਹ ਅਦ੍ਰਿਸ਼ਤਾ ਹੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਅਸਫਲਤਾਵਾਂ ਟਨਲ ਦੀਆਂ ਗਲਤੀਆਂ ਵਾਂਗ ਨਹੀਂ ਸਗੋਂ ਆਮ ਨੈੱਟਵਰਕ ਗਲਤੀਆਂ ਵਾਂਗ ਦਿਸਦੀਆਂ ਹਨ।
ਨੀਤੀ-ਆਧਾਰਿਤ ਅਤੇ ਰੂਟ-ਆਧਾਰਿਤ ਇੱਕੋ ਟਨਲ ਨਹੀਂ ਹਨ
ਨੀਤੀ-ਆਧਾਰਿਤ IPsec ਤੈਨਾਤੀ ਵਿੱਚ, ਗੱਲਬਾਤ ਕੀਤੇ ਟ੍ਰੈਫਿਕ ਚੋਣਕਾਰ ਠੀਕ-ਠੀਕ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜੇ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਜੋੜੇ ਸੁਰੱਖਿਅਤ ਹਨ। ਜੇ ਕਿਸੇ ਗੇਟਵੇ ਪਿੱਛੇ ਨਵਾਂ ਸਬਨੈੱਟ ਦਿਸੇ ਅਤੇ ਕੋਈ ਚੋਣਕਾਰ ਉਸਨੂੰ ਨਾ ਢਕੇ, ਤਾਂ ਟਨਲ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਨਵਾਂ ਸਬਨੈੱਟ ਬੱਸ ਨਹੀਂ ਢੋਇਆ ਜਾਂਦਾ। ਰੂਟ-ਆਧਾਰਿਤ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਇੰਟਰਫ਼ੇਸ ਟ੍ਰੈਫਿਕ ਲੈਂਦਾ ਹੈ ਅਤੇ ਰੂਟਿੰਗ ਸਾਰਣੀ ਫੈਸਲਾ ਕਰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਪ੍ਰੀਫਿਕਸ ਜੋੜਨਾ ਟਨਲ ਦੀ ਮੁੜ ਗੱਲਬਾਤ ਨਹੀਂ ਸਗੋਂ ਰੂਟ ਤਬਦੀਲੀ ਬਣ ਜਾਂਦਾ ਹੈ।
StrongSwan ਦੋਵੇਂ ਦ੍ਰਿਸ਼ ਸਿੱਧੇ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇਕੱਠੇ ਪੜ੍ਹਨਾ ਹੀ ਇਹ ਜਾਣਨ ਦਾ ਤਰੀਕਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਮਾਡਲ ਤੈਨਾਤ ਕੀਤਾ ਹੈ।
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'ਉਹ ਚੋਣਕਾਰ ਸੂਚੀ ਜਿਸ ਵਿੱਚ ਤੁਹਾਡਾ ਲੋੜੀਂਦਾ ਪ੍ਰੀਫਿਕਸ ਛੁੱਟ ਗਿਆ ਹੈ, ਬਿਨਾਂ ਕਿਸੇ ਪੈਕਟ ਕੈਪਚਰ ਦੇ ਅਸਫਲਤਾ ਸਮਝਾਉਂਦੀ ਹੈ, ਅਤੇ ਗਲਤ ਇੰਟਰਫ਼ੇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਰੂਟ ਵਾਪਸੀ ਰਾਹ ’ਤੇ ਸ਼ੀਸ਼ਾ-ਅਸਫਲਤਾ ਸਮਝਾਉਂਦਾ ਹੈ। ਕੁਝ ਵੀ ਮੁੜ ਗੱਲਬਾਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਕੁੰਜੀ ਨਵੀਨੀਕਰਨ ਉਹ ਚੋਣਕਾਰ ਨਹੀਂ ਜੋੜੇਗਾ ਜੋ ਤੁਸੀਂ ਕਦੇ ਕਨਫਿਗਰ ਨਹੀਂ ਕੀਤਾ।
ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਐਡਰੈਸਿੰਗ ਦੀ ਯੋਜਨਾ ਬਣਾਓ
ਓਵਰਲੈਪਿੰਗ ਰੇਂਜਾਂ ਉਹ ਡਿਜ਼ਾਈਨ ਗਲਤੀ ਹਨ ਜੋ ਕਨਫਿਗਰੇਸ਼ਨ ਨਾਲ ਠੀਕ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਜੇ ਦੋਵੇਂ ਸਾਈਟਾਂ 192.168.1.0/24 ਵਰਤਦੀਆਂ ਹਨ, ਤਾਂ 192.168.1.50 ਲੋੜੀਂਦੇ ਹੋਸਟ ਕੋਲ ਦੋ ਉਮੀਦਵਾਰ ਹੁੰਦੇ ਹਨ ਅਤੇ ਚੁਣਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ। ਟਨਲ ਪ੍ਰਮਾਣਿਤ ਹੋਵੇਗੀ, ਸੁਰੱਖਿਆ ਸਾਂਝੇਦਾਰੀਆਂ ਸਥਾਪਿਤ ਹੋਣਗੀਆਂ, ਅਤੇ ਰੂਟਿੰਗ ਫੈਸਲਾ ਫਿਰ ਵੀ ਗਲਤ ਜਾਂ ਅਸਪਸ਼ਟ ਰਹੇਗਾ।
ਤਿੰਨ ਇਮਾਨਦਾਰ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਇੱਕ ਚੁਣੋ: ਇੱਕ ਸਾਈਟ ਦਾ ਮੁੜ ਨੰਬਰਕਰਨ ਕਰੋ, ਗੇਟਵੇ ’ਤੇ ਓਵਰਲੈਪਿੰਗ ਰੇਂਜ ਦਾ ਅਨੁਵਾਦ ਕਰੋ ਤਾਂ ਜੋ ਹਰ ਪਾਸਾ ਵੱਖਰਾ ਪ੍ਰੀਫਿਕਸ ਦੇਖੇ, ਜਾਂ ਉਹਨਾਂ ਹੋਸਟਾਂ ਲਈ ਸਿੱਧੀ ਰੂਟਿੰਗ ਛੱਡ ਕੇ ਸੇਵਾ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ। ਹਰ ਇੱਕ ਦੀ ਲਾਗਤ ਹੈ, ਅਤੇ ਦੋ ਸਾਲਾਂ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵਿੱਚ ਪਹਿਲਾ ਆਮ ਤੌਰ ’ਤੇ ਸਭ ਤੋਂ ਸਸਤਾ ਹੁੰਦਾ ਹੈ। ਟਨਲ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਿੱਚ ਇਹ ਤਬਦੀਲੀ ਪੁਰਾਣੇ ਪਤੇ ਵਾਲੇ ਹਰ ਡਿਵਾਈਸ ਨੂੰ ਛੂਹਦੀ ਹੈ।
MTU ਦਾ ਸਵਾਲ ਵੀ ਜਲਦੀ ਹੱਲ ਕਰੋ। ਟਨਲ ਲਾਭਕਾਰੀ ਪੇਲੋਡ ਘਟਾਉਂਦੀ ਹੈ, ਅਤੇ ਫਰੈਗਮੈਂਟੇਸ਼ਨ ’ਤੇ ਨਿਰਭਰ ਡਿਜ਼ਾਈਨ ਗੇਟਵੇ ’ਤੇ MSS ਸਥਿਰ ਕਰਨ ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਨਾਲੋਂ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ।
ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਨੀਤੀ ਟਨਲ ਤੋਂ ਬਾਹਰ ਹੁੰਦੇ ਹਨ
ਗੇਟਵੇ ਨੂੰ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਅਤੇ LAN ਇੰਟਰਫ਼ੇਸ ਵਿਚਕਾਰ ਪੈਕਟ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਨੂੰ ਸੇਵਾ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੀ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ। Linux ਵਿੱਚ ਇਹ ਦੋ ਵੱਖਰੀਆਂ ਸੈਟਿੰਗਾਂ ਹਨ, ਨਾਲ ਹੀ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜੋ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਫਾਰਵਰਡ ਕੀਤਾ ਪ੍ਰਵਾਹ ਬਿਲਕੁਲ ਮਨਜ਼ੂਰ ਹੈ ਜਾਂ ਨਹੀਂ।
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਹੋਸਟ ਤੀਜੀ ਪਰਤ ਜੋੜਦਾ ਹੈ: ਉਸਦੇ ਆਪਣੇ ਫਾਇਰਵਾਲ ਨੂੰ ਅਜੇ ਵੀ ਦੂਰਲੇ ਸਬਨੈੱਟ ਤੋਂ ਕਲਾਇੰਟ ਸਵੀਕਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਸਿਰਫ਼ ਆਪਣੇ ਸਥਾਨਕ /24 ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲਾ ਫਾਇਲ ਸਰਵਰ ਟਨਲ ਕਿੰਨੀ ਵੀ ਤੰਦਰੁਸਤ ਦਿਸੇ, 10.20.0.7 ਤੋਂ ਫਾਰਵਰਡ ਕੀਤਾ ਟ੍ਰੈਫਿਕ ਅਸਵੀਕਾਰ ਕਰੇਗਾ, ਅਤੇ ਉਸ ਅਸਵੀਕਾਰ ਨੂੰ ਰੂਟਿੰਗ ਅਸਫਲਤਾ ਵਜੋਂ ਪੜ੍ਹਨਾ ਸੌਖਾ ਹੈ।
ਗੇਟਵੇ ਤੋਂ ਨਹੀਂ, ਹੋਸਟ ਤੋਂ ਜਾਂਚੋ
ਗੇਟਵੇ ਆਪ ਭੇਜਿਆ ping ਫਾਰਵਰਡ ਹੋਣ ਵਾਲੇ ਉਪਭੋਗਤਾ ਟ੍ਰੈਫਿਕ ਨਾਲੋਂ ਵੱਖਰਾ ਸਰੋਤ ਪਤਾ ਅਤੇ ਵੱਖਰੀ ਨੀਤੀ ਅਪਣਾ ਸਕਦਾ ਹੈ। ਇਸ ਨਾਲ ਇਹ ਕਮਜ਼ੋਰ ਜਾਂਚ ਬਣਦਾ ਹੈ ਅਤੇ ਕਦੇ-ਕਦੇ ਭਰਮਾਉਣ ਵਾਲਾ ਵੀ: ਐਪ ਅਸਫਲ ਹੋਣ ’ਤੇ ਇਹ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਐਪ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਇਹ ਅਸਫਲ ਹੁੰਦਾ ਹੈ।
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullਅਸਲੀ ਹੋਸਟ, ਅਸਲੀ ਸਰੋਤ ਪਤਾ ਅਤੇ ਉਹ ਅਸਲੀ ਪ੍ਰੋਟੋਕੋਲ ਵਰਤੋ ਜੋ ਐਪ ਵਰਤਦੀ ਹੈ। ਫਿਰ ਵਾਪਸੀ ਰਾਹ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਵਾਪਸੀ ਰੂਟ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਦੀ ਅੱਗੇ ਦੀ ਦਿਸ਼ਾ ਅਜਿਹਾ ਸਮਾਂ ਖਤਮ ਹੋਣਾ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜੋ ਰੋਕੀ ਗਈ ਸੇਵਾ ਵਰਗਾ ਹੀ ਦਿਸਦਾ ਹੈ।
ਡਿਜ਼ਾਈਨ ਉਸ ਸਵਾਲ ਅਨੁਸਾਰ ਚੁਣੋ ਜਿਸਦਾ ਤੁਸੀਂ ਜਵਾਬ ਦੇ ਰਹੇ ਹੋ: ਤੁਸੀਂ ਨੈੱਟਵਰਕ ਜੋੜ ਰਹੇ ਹੋ ਜਾਂ ਡਿਵਾਈਸ ਸਵੀਕਾਰ ਰਹੇ ਹੋ? ਬਾਕੀ ਸਭ ਕੁਝ, ਕਿਹੜਾ ਸਪਲਾਇਰ ਕਨਫਿਗਰ ਕਰਨਾ ਹੈ ਵੀ, ਉਸੇ ਜਵਾਬ ਤੋਂ ਆਉਂਦਾ ਹੈ।