ਜਾਣ ਵਾਲਾ ESP ਬਿਨਾਂ ਜਵਾਬ ਦੇ ਹੋਣ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ VPN ਮਰ ਗਿਆ ਹੈ
ESP ਹਰ ਸੰਗਠਨ ਲਈ ਇੱਕ ਦਿਸ਼ਾ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਵੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰਦਾ। ਸਰਵਰ ਨੂੰ ਬਿਨਾਂ ਜਵਾਬ ਵਾਲਾ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਅੰਦਰੂਨੀ ਗੱਲਬਾਤ ਅਤੇ ਇਨਬਾਊਂਡ SA ਨੂੰ ਮਿਲਾਓ।
ਤੁਸੀਂ IPsec ਹੋਸਟ 'ਤੇ ਟ੍ਰੈਫਿਕ ਕੈਪਚਰ ਕੀਤਾ, ESP ਪੈਕਟ ਬਾਹਰ ਜਾਂਦੇ ਦੇਖੇ, ਵਾਪਸ ਕੁਝ ਨਹੀਂ ਆਉਂਦਾ ਦੇਖਿਆ ਅਤੇ ਸਿੱਟਾ ਕੱਢਿਆ ਕਿ ਦੂਰ ਵਾਲਾ ਪਾਸਾ ਖਰਾਬ ਹੈ। ਕੈਪਚਰ ਇਸ ਸਿੱਟੇ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ। ESP ਗੱਲਬਾਤ ਦੀ ਇੱਕ ਦਿਸ਼ਾ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਅਤੇ IP ਪੱਧਰ 'ਤੇ ਕੁਝ ਵੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਵਾਪਸੀ ਵਾਲਾ ESP ਨਾ ਹੋਣਾ ਇਹ ਵੀ ਦਰਸਾ ਸਕਦਾ ਹੈ ਕਿ ਐਪ ਕੋਲ ਕਹਿਣ ਲਈ ਕੁਝ ਨਹੀਂ ਸੀ, ਜਿੰਨਾ ਹੀ ਇਹ ਕਿ ਟਨਲ ਮਰ ਗਿਆ ਹੈ। ਕਿਸੇ ਵੀ ਸਿਰੇ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਅੰਦਰੂਨੀ ਅਦਲ-ਬਦਲ ਅਤੇ ਪ੍ਰਾਪਤੀ ਵਾਲੇ ਪਾਸੇ ਦੀ ਸਥਿਤੀ ਪੜ੍ਹੋ।
ਭਰਮ: ਹਰ ਸੁਰੱਖਿਅਤ ਪੈਕਟ ਨੂੰ ਜਵਾਬ ਮਿਲਦਾ ਹੈ
ESP ਬੇਨਤੀ-ਜਵਾਬ ਪ੍ਰੋਟੋਕੋਲ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਸਭ ਐਨਕ੍ਰਿਪਟ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਜੋ ਨੀਤੀ ਚੁਣਦੀ ਹੈ, ਅਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਆਪਣਾ ਪੈਕਟ ਬਣਾਏ ਬਿਨਾਂ ਉਸ ਅੰਦਰੂਨੀ ਪੈਕਟ ਨੂੰ ਪਰਖ ਕੇ, ਡੀਕ੍ਰਿਪਟ ਕਰਕੇ ਅਤੇ ਪਹੁੰਚਾਉਂਦਾ ਹੈ। ਇੱਕ UDP ਪੁੱਛਗਿੱਛ ਜਿਸਨੂੰ ਮੰਜ਼ਿਲ ਅਣਡਿੱਠ ਕਰਦੀ ਹੈ, ਜਾਂ ਇੱਕ ICMP ਗੂੰਜ ਜਿਸਨੂੰ ਇਨਬਾਊਂਡ ਨੀਤੀ ਰੱਦ ਕਰਦੀ ਹੈ, ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਚੁੱਪ ਨੂੰ ਹੀ ਸਹੀ ਨਤੀਜਾ ਬਣਾਉਂਦੀ ਹੈ। ਉਸ ਚੁੱਪ ਨੂੰ ਆਵਾਜਾਈ ਦੀ ਖਰਾਬੀ ਮੰਨਣਾ ਤੁਹਾਨੂੰ ਅਜਿਹੀ ਨੈੱਟਵਰਕ ਖਰਾਬੀ ਲੱਭਣ ਭੇਜਦਾ ਹੈ ਜੋ ਕਦੇ ਸੀ ਹੀ ਨਹੀਂ।
ਇੱਕ-ਦਿਸ਼ਾ ਕੈਪਚਰ ਅਸਲ ਵਿੱਚ ਇਹੀ ਸਿੱਧ ਕਰਦਾ ਹੈ ਕਿ ਭੇਜਣ ਵਾਲੇ ਦੇ ਸਟੈਕ ਨੇ ਉਸ ਨਿਰੀਖਣ ਬਿੰਦੂ 'ਤੇ ਕੁਝ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ। ਪਹੁੰਚਣ ਬਾਰੇ ਕੁਝ ਨਹੀਂ, ਅਤੇ ਜਵਾਬ ਦੇਣ ਦੇ ਇਰਾਦੇ ਬਾਰੇ ਵੀ ਕੁਝ ਨਹੀਂ। ਕੰਮ ਦਾ ਸਵਾਲ „ਜਵਾਬ ਕਿਉਂ ਨਹੀਂ“ ਨਹੀਂ ਹੈ, ਸਗੋਂ „ਅੰਦਰੂਨੀ ਗੱਲਬਾਤ ਨੇ ਕੀ ਪੈਦਾ ਕਰਨਾ ਚਾਹੀਦਾ ਸੀ“ ਹੈ।
ਦੋ SA, ਦੋ SPI, ਇੱਕ ਗੱਲਬਾਤ
IPsec ਸੁਰੱਖਿਆ ਸੰਗਠਨ ਇੱਕ-ਦਿਸ਼ਾ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਆਮ ਸੁਰੱਖਿਅਤ ਅਦਲ-ਬਦਲ ਵੱਖਰੀਆਂ ਪਛਾਣਾਂ ਅਤੇ ਸੁਤੰਤਰ ਸਥਿਤੀ ਵਾਲਾ ਇੱਕ ਇਨਬਾਊਂਡ ਸੰਗਠਨ ਅਤੇ ਇੱਕ ਆਊਟਬਾਊਂਡ ਸੰਗਠਨ ਚਲਾਉਂਦਾ ਹੈ। ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਪੈਕਟ ਦੇ SPI ਲਈ ਵਾਪਸੀ ਦੀ ਆਵਾਜਾਈ ਲੱਭਣਾ ਸ਼੍ਰੇਣੀ ਦੀ ਗਲਤੀ ਹੈ, ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਜਵਾਬ ਸਾਥੀ ਦੇ ਆਪਣੇ ਆਊਟਬਾਊਂਡ SA ਹੇਠ ਆਪਣੇ SPI ਨਾਲ ਸਫ਼ਰ ਕਰਦਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ ਆਵਾਜਾਈ ਚੋਣਕਾਰਾਂ ਅਤੇ ਸਾਥੀ ਦੇ ਪਤਿਆਂ ਨਾਲ ਜੋੜੀ ਮਿਲਾਓ।
ਕੀ ਅਦਲ-ਬਦਲ ਕੁਝ ਸਕਿੰਟਾਂ ਲਈ ਤਸਵੀਰ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਪੁਰਾਣੀ ਅਤੇ ਬਦਲਵੀਂ ਸਥਿਤੀ ਇੱਕ ਦੂਜੇ ਉੱਤੇ ਆ ਸਕਦੀ ਹੈ। ਜੇ ਲੱਛਣ ਕੀ ਬਦਲਾਅ ਦੇ ਆਸ-ਪਾਸ ਸ਼ੁਰੂ ਹੋਇਆ, ਤਾਂ ਸਿਰਫ਼ ਕਨੈਕਸ਼ਨ ਦਾ ਨਾਮ ਨਹੀਂ, ਸਗੋਂ ਸੰਗਠਨ ਪਛਾਣਾਂ ਅਤੇ ਸਮਾਂ-ਛਾਪ ਇਕੱਠੇ ਇਕੱਠੇ ਕਰੋ।
ਕੁਝ ਵੀ ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਕੀ ਕਰਨਾ ਹੈ
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
ਹਰ ਕਤਾਰ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਫੇਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਹਰ ਖਰਾਬੀ ਦਾ ਵੱਖਰਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਕੈਪਚਰ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਨਬਾਊਂਡ ਕਾਊਂਟਰ ਹੀ ਪਹੁੰਚਣ ਦਾ ਇੱਕੋ ਇੱਕ ਸਿੱਧਾ ਸਬੂਤ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਦੁਹਰਾਓ ਜਾਂਚ ਵਿੱਚ ਫੇਲ ਹੋਣ ਵਾਲਾ ਪੈਕਟ ਕਿਸੇ ਵੀ ਜਵਾਬ ਤੋਂ ਬਿਨਾਂ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ ਜਿਸ ਸਾਥੀ ਦਾ ਇਨਬਾਊਂਡ ਕਾਊਂਟਰ ਨਹੀਂ ਹਿਲਿਆ, ਉਹ ਤੁਹਾਨੂੰ ਆਪਣੀ ਨੀਤੀ ਬਾਰੇ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦਿੰਦਾ।
ਪਹੁੰਚਾਉਣਾ ਡੀਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਵੱਖਰਾ ਕਦਮ ਹੈ। ਸਥਿਤੀ ਵੈਧ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਪੈਕਟ ਫਿਰ ਵੀ ਬਾਅਦ ਵਿੱਚ ਇਨਬਾਊਂਡ ਨੀਤੀ ਜਾਂ ਅਜਿਹੇ ਰਸਤੇ ਦੁਆਰਾ ਰੱਦ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਅੰਦਰੂਨੀ ਮੰਜ਼ਿਲ ਸ਼ਾਮਲ ਨਹੀਂ, ਇਸ ਲਈ ਇਹ ਮੰਨਣ ਦੀ ਬਜਾਏ ਕਿ ਸਾਫ਼ ਕਾਊਂਟਰ ਦਾ ਮਤਲਬ ਪੈਕਟ ਤੁਹਾਡੀ ਲੋੜ ਵਾਲੀ ਥਾਂ ਗਿਆ, ਇਹ ਜਾਂਚੋ ਕਿ ਟਾਰਗੇਟ ਹੋਸਟ ਨੇ ਸਾਫ਼ ਟੈਕਸਟ ਦੇਖਿਆ ਸੀ ਜਾਂ ਨਹੀਂ।
ਮੂਲ ESP UDP ਨਹੀਂ ਹੈ
ਮੂਲ ESP IP ਪ੍ਰੋਟੋਕੋਲ 50 ਹੈ, ਜੋ ਨਾ TCP ਹੈ ਨਾ UDP ਅਤੇ ਇਸਦੇ ਕੋਈ ਪੋਰਟ ਹੀ ਨਹੀਂ। ਇਸ ਲਈ UDP 500 'ਤੇ IKE ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਡੇਟਾ ਮਾਰਗ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਅਤੇ ਪੋਰਟਾਂ ਦੁਆਲੇ ਲਿਖਿਆ ਫਿਲਟਰ ਟਨਲ ਨੂੰ ਗੱਲਬਾਤ ਕਰਨ ਦੇ ਕੇ ਫਿਰ ਉਸ ਵਿੱਚ ਲਿਜਾਈ ਜਾਂਦੀ ਹਰ ਚੀਜ਼ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ। ਡੇਟਾ ਮਾਰਗ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਉਸੇ ਮੋਡ ਵਿੱਚ ਪਰਖੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਦੇਖਿਆ ਸੀ।
NAT ਦੇ ਪਿੱਛੇ ਤਸਵੀਰ ਬਦਲਦੀ ਹੈ: ਸੁਰੱਖਿਅਤ ਪੇਲੋਡ UDP ਦੇ ਅੰਦਰ ਸਫ਼ਰ ਕਰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਪੋਰਟ 4500 'ਤੇ, ਜਿਵੇਂ RFC 3948 ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਕੋਈ ਵੀ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਗਰਮ ਮੋਡ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ ਮਾਰਗ 'ਤੇ ਮੌਜੂਦ ਡਿਵਾਈਸ ਮੂਲ ESP ਅਤੇ UDP ਵਿੱਚ ਲਪੇਟੇ ESP ਨਾਲ ਬਿਲਕੁਲ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਕੁਝ ਵਿਚਕਾਰਲੇ ਡਿਵਾਈਸ ਇੱਕ ਦੀ ਆਗਿਆ ਦੇ ਕੇ ਦੂਜਾ ਰੱਦ ਕਰਦੇ ਹਨ।
ਇਸ ਘਟਨਾ ਨਾਲ ਸਬੰਧਤ ਕਾਊਂਟਰ ਪੜ੍ਹੋ
strongSwan ਹੋਸਟ 'ਤੇ swanctl --list-sas ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਹਰ ਸੰਗਠਨ ਦੇ ਪੈਕਟ ਅਤੇ ਬਾਈਟ ਕਾਊਂਟਰ ਦੱਸਦਾ ਹੈ, ਜੋ „ਕਦੇ ਨਹੀਂ ਆਇਆ“ ਨੂੰ „ਆਇਆ ਪਰ ਜਵਾਬ ਨਹੀਂ ਦਿੱਤਾ“ ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ। Linux 'ਤੇ /proc/net/xfrm_stat ਗੁੰਮ ਸਥਿਤੀ, ਗੁੰਮ ਨੀਤੀ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਗਲਤੀਆਂ ਵਰਗੀਆਂ ਸਮੁੱਚੀਆਂ ਖਰਾਬੀਆਂ ਗਿਣਦਾ ਹੈ। ਉਹ ਕੁੱਲ ਬੂਟ ਤੋਂ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਨੈੱਟਵਰਕ ਨਾਮ-ਥਾਂ ਨਾਲ ਸਬੰਧਤ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਵੱਡਾ ਅੰਕ ਕੋਈ ਦੋਸ਼ ਨਹੀਂ ਹੈ।
ਸਹੀ ਨਾਮ-ਥਾਂ ਵਿੱਚ ਘਟਨਾ ਦੀ ਵਿੰਡੋ ਦੁਆਲੇ ਦੋ ਰੀਡਿੰਗ ਲਓ ਅਤੇ ਫ਼ਰਕ ਤੁਲਨਾ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਪਿਛਲੇ ਹਫ਼ਤੇ ਦੀਆਂ ਗਲਤੀਆਂ ਅੱਜ ਦੁਪਹਿਰ ਦੀ ਟਿਕਟ ਨਾਲ ਜੋੜੋਗੇ। ਨਾਮ-ਥਾਂ ਅਤੇ ਦੋਵੇਂ ਸਮਾਂ-ਛਾਪ ਟਿਕਟ ਵਿੱਚ ਲਿਖੋ ਤਾਂ ਜੋ ਅਗਲਾ ਪਾਠਕ ਕੁੱਲ ਅੰਕ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ ਤੁਲਨਾ ਦੁਹਰਾ ਸਕੇ।
ਪੜਾਅ ਦਾ ਨਾਮ ਦਿਓ, ਸ਼ੱਕੀ ਦਾ ਨਹੀਂ
ਕੰਮ ਵਾਲਾ ਸਿੱਟਾ ਦੱਸਦਾ ਹੈ ਕਿ ਪੈਕਟ ਕਿੱਥੇ ਰੁਕਿਆ: ਕਦੇ ਨਹੀਂ ਮਿਲਿਆ, ਮਿਲਿਆ ਅਤੇ ਰੱਦ ਹੋਇਆ, ਪਹੁੰਚਾਇਆ ਪਰ ਜਵਾਬ ਨਹੀਂ, ਜਾਂ ਜਵਾਬ ਦਿੱਤਾ ਅਤੇ ਵਾਪਸੀ ਦੇ ਰਸਤੇ ਗੁੰਮ ਹੋਇਆ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰੇ ਮਾਲਕ ਅਤੇ ਵੱਖਰੇ ਅਗਲੇ ਕਮਾਂਡ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। „VPN ਸਰਵਰ ਤੋਂ ਕੋਈ ਜਵਾਬ ਨਹੀਂ“ ਚਾਰ ਵੱਖਰੀਆਂ ਖਰਾਬੀਆਂ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਕੈਪਚਰ ਨੇ ਕਦੇ ਜਾਇਜ਼ ਨਹੀਂ ਠਹਿਰਾਇਆ।
ਕੈਪਚਰ ਤੰਗ ਰੱਖੋ, ਅਤੇ ਕਰਨਲ ਦੀ ਕੱਚੀ ਸਥਿਤੀ ਟਿਕਟਾਂ ਵਿੱਚ ਨਾ ਰੱਖੋ, ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਕੀ ਸਮੱਗਰੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਹੋਸਟ ਛੱਡਣੀ ਨਹੀਂ ਚਾਹੀਦੀ। ਕਾਊਂਟਰਾਂ ਦੇ ਫ਼ਰਕ ਅਤੇ ਸਮਾਂ-ਛਾਪ ਹੀ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਦੇਣ ਯੋਗ ਹਿੱਸੇ ਹਨ।