ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਲਈ ਕੀ ਦਰਜ ਕਰਨਾ ਹੈ: ਸਿਲੈਕਟਰ ਅਤੇ ਦਾਇਰਾ

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

ਸੰਰਚਿਤ ਹੋਣਾ ਤੈਅ ਹੋਣਾ ਨਹੀਂ ਹੈ

ਨੀਤੀ-ਆਧਾਰਿਤ IPsec ਟਨਲ ਵਿੱਚ ਹਰ ਧਿਰ ਟ੍ਰੈਫਿਕ ਸਿਲੈਕਟਰ ਪੇਸ਼ ਕਰਦੀ ਹੈ: ਚਾਈਲਡ ਐਸੋਸੀਏਸ਼ਨ ਲਈ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਦੇ ਦਾਇਰੇ। ਜਵਾਬ ਦੇਣ ਵਾਲੀ ਧਿਰ ਨੂੰ ਉਹ ਪੇਸ਼ਕਸ਼ ਸੰਕੁਚਿਤ ਕਰਨ ਦਾ ਹੱਕ ਹੈ, ਇਸ ਲਈ ਸਥਾਪਿਤ ਐਸੋਸੀਏਸ਼ਨ ਸੰਰਚਨਾ ਵਿੱਚ ਦਰਜ ਨਾਲੋਂ ਘੱਟ ਕਵਰ ਕਰ ਸਕਦੀ ਹੈ। ਸੰਰਚਨਾ ਦੀ ਨਕਲ ਕਰਨ ਵਾਲਾ ਰਿਕਾਰਡ ਇੱਕ ਇਰਾਦੇ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਮੌਜੂਦਾ ਸੁਰੱਖਿਆ ਦਾਇਰੇ ਦਾ ਨਹੀਂ। ਦੋਵੇਂ ਚੁੱਪਚਾਪ ਵੱਖ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਟਨਲ ਸਥਿਤੀ ਪੰਨੇ ਉੱਤੇ ਇਹ ਦਰਸਾਉਣ ਵਾਲਾ ਕੁਝ ਨਹੀਂ ਹੈ।

ਤੁਸੀਂ ਜਿਸ ਤਾਰੀਖ਼ ਨੂੰ ਦੇਖਿਆ ਉਸ ਸਮੇਤ ਦੋਵੇਂ ਕਾਲਮ ਰੱਖੋ। ਸੰਰਚਿਤ ਸਿਲੈਕਟਰ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹਿਆ ਸੀ; ਤੈਅ ਹੋਇਆ ਉਹ ਹੈ ਜੋ ਕਰਨਲ ਹੁਣ ਲਾਗੂ ਕਰ ਰਿਹਾ ਹੈ। ਜਦੋਂ ਇਹ ਵੱਖ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਇਹ ਫ਼ਰਕ ਰਾਊਟਿੰਗ ਬੱਗ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਵਾਰ ਅਚਾਨਕ ਅਸਫ਼ਲਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।

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

ਰਾਊਟ-ਆਧਾਰਿਤ ਟਨਲ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਚੁਣਦੇ ਹਨ

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

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

ਅਨੁਵਾਦ ਉਸੇ ਟੇਬਲ ਵਿੱਚ ਆਉਂਦਾ ਹੈ

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

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

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

ਸੇਵਾ ਦੀ ਲੋੜ ਜੋੜੋ

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

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

ਰਿਕਾਰਡ ਨੂੰ ਟੈਸਟ ਯੋਜਨਾ ਬਣਾਓ

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

swanctl --list-sas

ਪੰਜ ਲਾਈਨਾਂ ਦਾ ਢਾਂਚਾ ਆਮ ਤੌਰ ਉੱਤੇ ਰਿਕਾਰਡ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਣ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ ਸੰਸਕਰਣ ਬਿਨਾਂ ਕੱਟੇ ਬਦਲਾਅ ਟਿਕਟ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

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