IPsec ਉੱਤੇ ਡੇਟਾਬੇਸ ਕਵੈਰੀ ਅਟਕਦੀ ਹੈ: UDP ਮੁੜ-ਕ੍ਰਮ ਜਾਂ TCP?
ਸਾਫ਼ ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਬਾਅਦ ਅਟਕਣ ਵਾਲੀ ਕਵੈਰੀ ਟਨਲ ਦੇ ਰਾਹ ਦੇ ਅੰਦਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ। ਤਿੰਨ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਰਾਹ ਸੁਧਾਰਨਾ ਹੈ ਜਾਂ 443 ਉੱਤੇ TCP ਵੱਲ ਵਾਪਸ ਜਾਣਾ ਹੈ।
TCP ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਬਾਅਦ ਅਟਕਣ ਵਾਲੀ ਕਵੈਰੀ ਰਾਊਟਿੰਗ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਰਾਹ ਦੀਆਂ ਗਲਤੀਆਂ ਹੈਂਡਸ਼ੇਕ ਫੇਲ੍ਹ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਬਣਨ ਤੋਂ ਬਾਅਦ ਚੁੱਪ ਹੋ ਜਾਣ ਵਾਲਾ ਸੈਸ਼ਨ ਰਾਹ ਦੇ ਅੰਦਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ: ਨਿਰੀਖਣ, MTU, ਜਾਂ ਟਨਲ ਦੇ UDP ਪੈਕਟ ਆਉਣ ਦਾ ਤਰੀਕਾ। ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਫੈਸਲਾ ਇਹ ਹੈ ਕਿ ਉਹ ਰਾਹ ਸੁਧਾਰਨਾ ਹੈ ਜਾਂ ਟਨਲ ਨੂੰ TCP ਉੱਤੇ ਲਿਜਾਣਾ ਹੈ। ਤਿੰਨ ਸ਼ਰਤਾਂ ਇਹ ਤੈਅ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਡੇਟਾਬੇਸ ਬਾਰੇ ਨਹੀਂ ਹੈ।
ਟਨਲ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਅਟਕਣ ਦਾ ਵਰਗੀਕਰਨ ਕਰੋ
ਚਾਰ ਨਤੀਜੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਇੱਕੋ ਜਿਹੇ ਲੱਗਦੇ ਹਨ ਅਤੇ ਇੰਜੀਨੀਅਰ ਲਈ ਬਿਲਕੁਲ ਵੱਖਰੇ ਅਰਥ ਰੱਖਦੇ ਹਨ।
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
ਸਿਰਫ਼ ਆਖ਼ਰੀ ਦੋ ਕਤਾਰਾਂ ਹੀ ਟਨਲ ਉੱਤੇ ਸਮਾਂ ਲਾਉਣ ਦਾ ਹੱਕ ਦਿੰਦੀਆਂ ਹਨ। VPN ਰਾਹੀਂ ਰੱਦ ਕੀਤਾ ਕਨੈਕਸ਼ਨ ਆਮ ਤੌਰ ਉੱਤੇ ਡੇਟਾਬੇਸ ਦਾ ਸਿਰਫ਼ loopback ਉੱਤੇ ਸੁਣਨਾ ਹੁੰਦਾ ਹੈ, ਜੋ ਸਰੋਤੇ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਸਮਾਂ-ਸਮਾਪਤੀ ਫਿਲਟਰ ਜਾਂ ਰਾਹ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਬਦਲਣ ਨਾਲ ਸੁਧਰਦਾ ਨਹੀਂ।
ਵਰਗੀਕਰਨ ਪਹਿਲਾਂ ਟਿਕਟ ਵਿੱਚ ਲਿਖੋ। ਇਹ ਸਭ ਤੋਂ ਸਸਤਾ ਕਦਮ ਹੈ ਅਤੇ ਖੋਜ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹਟਾ ਦਿੰਦਾ ਹੈ।
UDP ਅਤੇ TCP ਵਿਚਕਾਰ ਫੈਸਲਾ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ
ਐਨਕੈਪਸੂਲੇਟਿਡ IPsec ਟਰੈਫਿਕ UDP ਉੱਤੇ ਚੱਲਦਾ ਹੈ, ਅਤੇ UDP ਰਾਹ ਨੂੰ ਕਿਸੇ ਨੂੰ ਦੱਸੇ ਬਿਨਾਂ ਮੁੜ-ਕ੍ਰਮ ਕਰਨ ਅਤੇ ਸੁੱਟਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਮੁੜ-ਕ੍ਰਮ ਪੈਕਟਾਂ ਨੂੰ ਟਨਲ ਦੀ ਦੁਬਾਰਾ-ਚੱਲਣ-ਵਿਰੋਧੀ ਵਿੰਡੋ ਤੋਂ ਬਾਹਰ ਧੱਕਦਾ ਹੈ, ਤਾਂ ਉਹ ਚੁੱਪਚਾਪ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਅੰਦਰਲਾ TCP ਸੈਸ਼ਨ ਬਸ ਉਡੀਕਦਾ ਹੈ। ਸਫਲ ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਕਦੇ ਨਾ ਮੁੜਨ ਵਾਲੀ ਕਵੈਰੀ ਪਿੱਛੇ ਇਹੀ ਵਿਧੀ ਹੈ।
ਰਾਹ ਸੁਧਾਰਨਾ ਜਾਂ TCP ਵੱਲ ਵਾਪਸ ਜਾਣਾ ਤਿੰਨ ਗੱਲਾਂ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਪਹਿਲਾਂ, ਰਾਹ ਉੱਤੇ ਸੱਚਮੁੱਚ ਪੈਕਟ ਨੁਕਸਾਨ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਮੁੜ-ਕ੍ਰਮ? ਦੂਜਾ, ਨਿਰੀਖਣ ਕਿੱਥੇ ਹੁੰਦਾ ਹੈ ਉਹ ਬਦਲ ਸਕਦੇ ਹੋ, ਜਾਂ ਇਸ ਟਨਲ ਨੂੰ ਮੁੜ-ਕ੍ਰਮ ਕਰਨ ਵਾਲੇ ਹਿੱਸੇ ਤੋਂ ਬਾਹਰ ਰੱਖ ਸਕਦੇ ਹੋ? ਤੀਜਾ, ਕੰਮ ਦਾ ਭਾਰ ਅਟਕਣ ਦੇ ਪੈਟਰਨ ਪ੍ਰਤੀ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ, ਜਿਵੇਂ ਇੱਕ ਲਿੰਕ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਕਈ ਮਲਟੀਪਲੈਕਸ ਸੈਸ਼ਨ?
ਜੇ ਪਹਿਲਾ ਜਵਾਬ ਨੁਕਸਾਨ ਹੈ ਅਤੇ ਦੂਜਾ ਨਹੀਂ,ਤਾਂ 443 ਉੱਤੇ TCP ਵਿਹਾਰਕ ਵਿਕਲਪ ਹੈ। ਜੇ ਦੂਜਾ ਜਵਾਬ ਹਾਂ ਹੈ, ਤਾਂ ਰਾਹ ਸੁਧਾਰੋ ਅਤੇ UDP ਰੱਖੋ।
ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਗਲਤੀ ਨਹੀਂ, ਫਾਇਰਵਾਲ ਦਾ ਰਿਕਾਰਡ ਪੜ੍ਹੋ
ਐਪਲੀਕੇਸ਼ਨ ਸਮਾਂ-ਸਮਾਪਤੀ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਜੋ ਕਾਰਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਫਾਇਰਵਾਲ ਦਾ ਆਪਣਾ ਲੌਗ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਡ੍ਰੌਪ ਜਾਂ ਬਲਾਕ ਦਿਖਦਾ ਹੈ, ਇਸ ਲਈ ਡੇਟਾਬੇਸ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਪਤਿਆਂ ਨਾਲ ਫਿਲਟਰ ਕਰੋ ਅਤੇ ਸਵੀਕ੍ਰਿਤੀਆਂ ਦੇ ਨਾਲ ਡ੍ਰੌਪ ਵੀ ਖੋਜੋ।ਖਤਰਾ ਰੋਕਥਾਮ ਬਲੇਡ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ ਉੱਤੇ ਗਲਤੀ ਬਣਾਏ ਬਿਨਾਂ ਪੈਕਟ ਸੁੱਟ ਸਕਦੇ ਹਨ, ਅਤੇ ਅਟਕਣ ਵਾਲੀ ਕਵੈਰੀ ਦਾ ਇਹੋ ਰੂਪ ਹੈ। ਲੌਗ ਵਿੱਚ ਚੁੱਪੀ ਵੀ ਜਾਣਕਾਰੀ ਹੈ: ਇਹ ਕਿਸੇ ਅਜਿਹੀ ਚੀਜ਼ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ ਜੋ ਲੌਗ ਨਹੀਂ ਕਰਦੀ, ਜਿਵੇਂ ਮੁੜ-ਕ੍ਰਮ।
ਕਲਸਟਰ ਵੀ ਜਾਂਚੋ। ਗਲਤ ਕਨਫਿਗਰ ਕੀਤਾ ਕਲਸਟਰ ਇੱਕ ਮੈਂਬਰ ਦੀ ਸਟੇਟ ਟੇਬਲ ਵਿੱਚ ਸੈਸ਼ਨ ਰੱਖ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਪੈਕਟ ਦੂਜੇ ਮੈਂਬਰ ਦੇ ਰਾਹ ਲੰਘਦੇ ਹਨ, ਇਸ ਲਈ ਜਵਾਬ ਉੱਥੇ ਪਹੁੰਚਦੇ ਹਨ ਜਿੱਥੇ ਕੋਈ ਸਟੇਟ ਨਹੀਂ। ਅਜਿਹੀਆਂ ਅਟਕਣਾਂ ਬੇਤਰਤੀਬ ਲੱਗਦੀਆਂ ਹਨ ਅਤੇ ਭਾਰ ਨਾਲ ਸੰਬੰਧਿਤ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਪੈਕਟ ਗਿਣਤੀ ਨਹੀਂ, ਆਉਣ ਦਾ ਕ੍ਰਮ ਤੁਲਨਾ ਕਰੋ:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap443 ਉੱਤੇ TCP ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਕਿੰਨਾ ਮਹਿੰਗਾ ਪੈਂਦਾ ਹੈ
ਟਨਲ ਨੂੰ TCP ਉੱਤੇ ਲਿਜਾਣ ਨਾਲ ਮੁੜ-ਕ੍ਰਮ ਦਾ ਲੱਛਣ ਹਟ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਵਿਚਕਾਰਲਾ ਬਾਕਸ ਹੁਣ ਕ੍ਰਮਬੱਧ ਸਟ੍ਰੀਮ ਦੇਖਦਾ ਹੈ। ਇਹ TCP-over-TCP ਵੀ ਬਣਾਉਂਦਾ ਹੈ। ਬਾਹਰਲਾ ਕਨੈਕਸ਼ਨ ਉਹੀ ਦੁਬਾਰਾ ਭੇਜਦਾ ਹੈ ਜੋ ਅੰਦਰਲੇ ਨੇ ਪਹਿਲਾਂ ਹੀ ਦੁਬਾਰਾ ਭੇਜ ਦਿੱਤਾ ਹੈ, ਅਤੇ ਇੱਕੋ ਨੁਕਸਾਨ ਇੱਕੋ ਵੇਲੇ ਸਾਰੇ ਮਲਟੀਪਲੈਕਸ ਸੈਸ਼ਨ ਰੋਕ ਸਕਦਾ ਹੈ। ਸਾਫ਼ ਰਾਹ ਉੱਤੇ ਇਹ ਅਦਿੱਖ ਹੈ। ਨੁਕਸਾਨ ਵਾਲੇ ਰਾਹ ਉੱਤੇ ਇਲਾਜ ਲੱਛਣ ਨਾਲੋਂ ਮਾੜਾ ਹੈ।
ਵਿਕਲਪ ਜਦੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਨੈਕਟੀਵਿਟੀ ਦੀ ਘਾਟ ਹੋਵੇ ਤਾਂ ਇਹ ਅਦਲਾ-ਬਦਲੀ ਸਵੀਕਾਰਯੋਗ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਆਮ ਮੰਨ ਕੇ ਸਵੀਕਾਰਨ ਦੀ ਥਾਂ ਮਾਲਕ ਸਮੇਤ ਅਪਵਾਦ ਵਜੋਂ ਦਰਜ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਟਰਾਂਸਪੋਰਟ, ਪੋਰਟ, ਨਮੂਨਾ ਕਵੈਰੀ ਅਤੇ ਮਾਪਿਆ ਨਤੀਜਾ, ਨਾਲ ਹੀ ਤਾਰੀਖ਼ ਦਰਜ ਕਰੋ। ਉਸ ਰਿਕਾਰਡ ਤੋਂ ਬਿਨਾਂ ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਪ੍ਰਯੋਗ ਦੁਹਰਾਉਂਦਾ ਹੈ, ਅਤੇ ਅਪਵਾਦ ਚੁੱਪਚਾਪ ਆਰਕੀਟੈਕਚਰ ਬਣ ਜਾਂਦਾ ਹੈ।
ਫੈਸਲੇ ਨੂੰ ਦੁਬਾਰਾ ਸਮੀਖਿਆ ਯੋਗ ਰੱਖੋ
ਰਾਹ ਦਾ ਨਿਦਾਨ ਜਲਦੀ ਪੁਰਾਣਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਵਿਚਕਾਰਲਾ ਬਾਕਸ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ, ਬਲੇਡ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਦੀ ਹੈ, ਲਿੰਕ ਅੱਪਗ੍ਰੇਡ ਹੁੰਦਾ ਹੈ, ਅਤੇ 443 ਉੱਤੇ TCP ਦਾ ਕਾਰਨ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਕਨਫਿਗਰੇਸ਼ਨ ਰਹਿੰਦੀ ਹੈ। ਅਪਵਾਦ ਉੱਤੇ ਸਮੀਖਿਆ ਤਾਰੀਖ਼ ਰੱਖੋ ਅਤੇ ਉਸ ਸ਼ਰਤ ਦਾ ਨਾਮ ਦਿਓ ਜੋ ਤੁਹਾਨੂੰ UDP ਵੱਲ ਵਾਪਸ ਜਾਣ ਦੇਵੇਗੀ।
ਛੋਟੀ ਕਵੈਰੀ ਅਤੇ ਵੱਡੇ ਨਤੀਜਾ ਸਮੂਹ ਨਾਲ ਦੋਵੇਂ ਟਰਾਂਸਪੋਰਟ ਜਾਂਚੋ। ਮੁੜ-ਕ੍ਰਮ ਆਕਾਰ-ਨਿਰਭਰ ਅਟਕਣਾਂ ਵਜੋਂ ਦਿਖਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਸਰੋਤੇ ਦੀ ਖਰਾਬੀ ਦੋਵੇਂ ਆਕਾਰਾਂ ਨੂੰ ਬਰਾਬਰ ਰੋਕਦੀ ਹੈ।