ਪੈਕਟ ਕੈਪਚਰ ਵਿੱਚ ਪਹਿਲੀ IKEv2 ਅਦਲ-ਬਦਲ ਕਿਵੇਂ ਪੜ੍ਹੀਏ
SPI ਅਤੇ ਸੁਨੇਹਾ ਆਈਡੀ ਨਾਲ IKE_SA_INIT ਬੇਨਤੀ ਅਤੇ ਜਵਾਬ ਮਿਲਾਓ, 4500 ਉੱਤੇ IKE ਨੂੰ ਇਨਕੈਪਸੁਲੇਟਡ ESP ਤੋਂ ਵੱਖ ਪਛਾਣੋ, ਅਤੇ ਵੇਖੋ ਕਿ ਇੱਕ ਚੁੱਪ ਟਰੇਸ ਕੀ ਸਾਬਤ ਕਰ ਸਕਦੀ ਹੈ।
ਸੈਸ਼ਨ ਦੇ ਵਿਚਕਾਰ ਲਏ ਕੈਪਚਰ ਹੀ ਆਮ ਕਾਰਨ ਹਨ ਕਿ IKEv2 ਟਰੇਸ ਸ਼ੋਰ ਵਰਗੀ ਲੱਗਦੀ ਹੈ, ਕਿਉਂਕਿ ਰਿਕਾਰਡਿੰਗ ਸ਼ੁਰੂ ਹੁੰਦਿਆਂ ਹੀ ਦੋਵੇਂ ਧਿਰਾਂ ਪਹਿਲਾਂ ਹੀ ਚਾਬੀਆਂ ਨਵੀਆਂ ਕਰ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਾਂ ਐਨਕ੍ਰਿਪਟਿਡ ਪੇਲੋਡ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਦੀ ਬਜਾਏ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਯਤਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਤਾਂ ਜੋ ਫਾਈਲ ਵਿੱਚ ਪਹਿਲਾ ਸੁਨੇਹਾ ਉਹੀ ਹੋਵੇ ਜੋ ਗੱਲਬਾਤ ਖੋਲ੍ਹਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ ਪੜ੍ਹਨ ਕ੍ਰਮ ਇਹੀ ਮੰਨਦਾ ਹੈ ਅਤੇ ਉਹ ਬਿੰਦੂ ਦੱਸਦਾ ਹੈ ਜਿੱਥੇ ਪੈਕਟ ਦੂਰ ਦੇ ਸਿਰੇ ਬਾਰੇ ਕੁਝ ਵੀ ਸਾਬਤ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਕਦਮ ਛੱਡਣ ਨਾਲ ਹੀ ਕੰਮ ਕਰ ਰਹੀ ਟਨਲ ਨੂੰ ਰੋਕਿਆ ਪੋਰਟ ਵਜੋਂ ਨਿਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਪੱਕਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਸ਼ੁਰੂਆਤੀ ਅਦਲ-ਬਦਲ ਵੇਖ ਰਹੇ ਹੋ
IKEv2 ਗੱਲਬਾਤ IKE_SA_INIT ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਅਦਲ-ਬਦਲ ਕਿਸਮ 34, ਸੁਨੇਹਾ ਆਈਡੀ 0। ਸ਼ੁਰੂ ਕਰਨ ਵਾਲਾ ਗੈਰ-ਸਿਫ਼ਰ SPI ਚੁਣਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਦਾ SPI ਉਸ ਪਹਿਲੀ ਬੇਨਤੀ ਵਿੱਚ ਸਿਫ਼ਰ ਅਤੇ ਜਵਾਬ ਵਿੱਚ ਗੈਰ-ਸਿਫ਼ਰ ਹੁੰਦਾ ਹੈ। ਇਹ ਤਿੰਨ ਤੱਥ ਨਵੇਂ ਯਤਨ ਨੂੰ ਚਾਬੀ ਨਵਿਆਉਣ ਜਾਂ ਕੈਪਚਰ ਦੇ ਸਿਖਰ ਉੱਤੇ ਸੰਜੋਗ ਨਾਲ ਪਏ IKE_AUTH ਸੁਨੇਹੇ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹਨ।
ਹੈਡਰ ਖੇਤਰ ਪੜ੍ਹਨਯੋਗ ਹਨ, ਅਤੇ ਪ੍ਰਸਤਾਵ, ਚਾਬੀ ਅਦਲ-ਬਦਲ ਤੇ nonce ਪੇਲੋਡ ਵੀ। ਪੜ੍ਹਨਯੋਗ ਹੋਣਾ ਪ੍ਰਮਾਣਿਤ ਹੋਣਾ ਨਹੀਂ ਹੈ: ਇਸ ਬਿੰਦੂ ਉੱਤੇ ਕਿਸੇ ਧਿਰ ਨੇ ਪਛਾਣ ਸਾਬਤ ਨਹੀਂ ਕੀਤੀ, ਅਤੇ Diffie-Hellman ਦਾ ਨਿੱਜੀ ਮੁੱਲ ਕਦੇ ਤਾਰ ਉੱਤੇ ਨਹੀਂ ਦਿਸਦਾ।
ਡੀਕੋਡ ਪੈਨਲ ਸਕ੍ਰੋਲ ਕਰਨ ਦੀ ਬਜਾਏ ਖੇਤਰਾਂ ਨੂੰ ਸਾਰਣੀ ਵਜੋਂ ਛਾਪੋ, ਕਿਉਂਕਿ ਮੁੜ-ਭੇਜਣਾ ਅਤੇ ਨਾ ਮਿਲਦੇ SPI ਕਾਲਮਾਂ ਵਿੱਚ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ।
tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi
ਆਉਟਪੁੱਟ ਜੋੜਿਆਂ ਵਿੱਚ ਪੜ੍ਹੋ। ਸੁਨੇਹਾ ਆਈਡੀ 0 ਵਾਲੀ ਬੇਨਤੀ ਤੋਂ ਬਾਅਦ ਉਹੀ ਆਈਡੀ ਅਤੇ ਗੈਰ-ਸਿਫ਼ਰ ਜਵਾਬਦਾਤਾ SPI ਵਾਲਾ ਜਵਾਬ ਇੱਕ ਹੀ ਅਦਲ-ਬਦਲ ਹੈ, ਭਾਵੇਂ ਉਹ ਤਿੰਨ ਵਾਰ ਦਿਸੇ ਕਿਉਂਕਿ ਬੇਨਤੀ ਮੁੜ ਭੇਜੀ ਗਈ ਸੀ। ਤਿੰਨ ਇੱਕੋ ਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਤਿੰਨ ਲੌਗਇਨ ਨਹੀਂ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੰਝ ਲੈਣ ਨਾਲ ਹੀ ਲੋਕ ਨਤੀਜਾ ਕੱਢਦੇ ਹਨ ਕਿ ਕਲਾਇੰਟ ਲੂਪ ਵਿੱਚ ਘੁੰਮ ਰਿਹਾ ਹੈ, ਜਦੋਂ ਕਿ ਉਹ ਸਿਰਫ਼ ਸਬਰ ਕਰ ਰਿਹਾ ਹੈ। ਸੁਨੇਹਾ ਆਈਡੀ ਅਨੁਸਾਰ, ਫਿਰ ਸਮਾਂ-ਛਾਪ ਅਨੁਸਾਰ ਤਰਤੀਬ ਦਿਓ, ਅਤੇ ਸਾਰੀ ਗੱਲਬਾਤ ਯਤਨਾਂ ਦੀ ਛੋਟੀ ਸੂਚੀ ਵਿੱਚ ਸਿਮਟ ਜਾਵੇਗੀ।
ਸਫਲਤਾ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਇਨਕਾਰ ਪੜ੍ਹੋ
ਜਵਾਬ ਆਪਣੇ ਆਪ ਤਰੱਕੀ ਨਹੀਂ ਹੈ। ਜਵਾਬ ਦੇਣ ਵਾਲਾ cookie ਸੂਚਨਾ ਨਾਲ ਜਵਾਬ ਦੇ ਕੇ ਆਸ ਰੱਖ ਸਕਦਾ ਹੈ ਕਿ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲਾ ਫਿਰ ਯਤਨ ਕਰੇਗਾ, ਜਾਂ INVALID_KE_PAYLOAD ਨਾਲ ਜਿਸ ਵਿੱਚ ਉਹ ਸਮੂਹ ਦੱਸੇ ਜੋ ਉਹ ਇਸ ਦੀ ਥਾਂ ਸਵੀਕਾਰ ਕਰੇਗਾ। ਦੋਵੇਂ ਸਹੀ ਬਣੇ IKE ਸੁਨੇਹਿਆਂ ਵਜੋਂ ਆਉਂਦੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਪੈਕਟ ਗਿਣਨ ਵਾਲੇ ਫਿਲਟਰ ਨੂੰ ਦੋਵੇਂ ਪੂਰਾ ਹੋਇਆ ਅਦਲ-ਬਦਲ ਲੱਗਦੇ ਹਨ।
ਸੂਚਨਾ ਪੇਲੋਡ ਖੋਲ੍ਹੋ ਅਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸਮ ਪੜ੍ਹੋ। cookie ਚੁਣੌਤੀ ਦਾ ਅਰਥ ਹੈ ਕਿ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਜਾਅਲੀ ਸਰੋਤ ਪਤਿਆਂ ਤੋਂ ਆਪਣਾ ਬਚਾਅ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ cookie ਜੋੜ ਕੇ ਮੁੜ ਭੇਜਣਾ ਪਵੇਗਾ। ਅਵੈਧ ਸਮੂਹ ਦਾ ਅਰਥ ਹੈ ਕਿ ਦੋਵੇਂ ਪ੍ਰਸਤਾਵ ਮਿਲਦੇ ਨਹੀਂ, ਜਿਸ ਨੂੰ ਇੱਕ ਧਿਰ ਦੀ ਸੰਰਚਨਾ ਬਦਲਣ ਤੱਕ ਕੋਈ ਵੀ ਮੁੜ-ਯਤਨ ਨਹੀਂ ਬਦਲੇਗਾ।
ਸਿਰਫ਼ IKE_AUTH, ਦੂਜਾ ਅਦਲ-ਬਦਲ, ਐਨਕ੍ਰਿਪਟਿਡ ਪਛਾਣ ਅਤੇ ਪ੍ਰਮਾਣਕਿਤਾ ਪੇਲੋਡ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ ਪੂਰਾ ਹੋਇਆ IKE_SA_INIT ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਦੋਵੇਂ ਧਿਰਾਂ ਐਲਗੋਰਿਦਮ ਅਤੇ ਕੱਢੀਆਂ ਚਾਬੀਆਂ ਉੱਤੇ ਸਹਿਮਤ ਹਨ, ਅਤੇ ਇਸ ਬਾਰੇ ਕੁਝ ਵੀ ਨਹੀਂ ਕਿ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਸਵੀਕਾਰ ਹੋਣਗੇ ਜਾਂ ਨਹੀਂ। ਉੱਥੇ ਵੀ ਦੋ ਸੁਨੇਹਿਆਂ ਦੀ ਆਸ ਰੱਖੋ, ਅਤੇ ਆਸ ਰੱਖੋ ਕਿ ਸੈਸ਼ਨ ਚਾਬੀਆਂ ਤੋਂ ਬਿਨਾਂ ਦੋਵੇਂ ਧੁੰਦਲੇ ਰਹਿਣਗੇ।
ਪੋਰਟ 4500 ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਨਹੀਂ ਹੈ
ਆਮ ਤੌਰ ਉੱਤੇ UDP 500 ਸ਼ੁਰੂਆਤੀ ਅਦਲ-ਬਦਲ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ। NAT ਖੋਜ ਚੱਲਣ ਤੋਂ ਬਾਅਦ IKE 4500 ਉੱਤੇ ਚਲਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹਰ ਸੁਨੇਹੇ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਬਾਈਟ ਦਾ ਸਿਫ਼ਰ ਗੈਰ-ESP ਨਿਸ਼ਾਨ ਲਾਉਂਦਾ ਹੈ। ਉਸੇ ਪੋਰਟ ਉੱਤੇ ਇਨਕੈਪਸੁਲੇਟਡ ESP ਇਸ ਦੀ ਥਾਂ ਗੈਰ-ਸਿਫ਼ਰ ESP SPI ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਬਾਈਟ ਦਾ NAT keepalive ਤੀਜਾ ਰੂਪ ਹੈ ਜੋ ਹੋਰ ਕੁਝ ਨਾ ਹੋਣ ਵੇਲੇ ਦਿਸਦਾ ਹੈ।
ਸਿਰਫ਼ ਪੋਰਟ ਮਿਲਾਉਣ ਵਾਲਾ ਫਿਲਟਰ ਤਿੰਨੇ ਰਲਾ ਦਿੰਦਾ ਹੈ, ਇਸੇ ਲਈ "4500 ਉੱਤੇ ਟ੍ਰੈਫਿਕ ਹੈ" ਬਹੁਤ ਘੱਟ ਤੈਅ ਕਰਦਾ ਹੈ। ਦੂਰ ਦੇ ਸਿਰੇ ਬਾਰੇ ਕੋਈ ਨਤੀਜਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਦ੍ਰਿਸ਼ ਨੂੰ ਪ੍ਰੋਟੋਕੋਲ ਅਨੁਸਾਰ ਵੱਖ ਕਰੋ।
tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi
ਚੁੱਪ ਅਵਲੋਕਨ ਬਿੰਦੂ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ
ਬਿਨਾਂ ਜਵਾਬ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਠੀਕ ਇੱਕ ਗੱਲ ਸਥਾਪਤ ਕਰਦੀਆਂ ਹਨ: ਉਸ ਕੈਪਚਰ ਬਿੰਦੂ ਉੱਤੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਆਇਆ। ਫਿਲਟਰਿੰਗ, ਜਵਾਬ ਕਿਤੇ ਹੋਰ ਭੇਜਣ ਵਾਲਾ ਮਾਰਗ, ਨਾ ਪਹੁੰਚਣ ਯੋਗ ਜਵਾਬ ਦੇਣ ਵਾਲਾ, ਜਾਂ ਪ੍ਰਸਤਾਵ ਪਸੰਦ ਨਾ ਆਉਣ ਵਾਲਾ ਜਵਾਬ ਦੇਣ ਵਾਲਾ — ਸਾਰੇ ਉਹੀ ਖਾਲੀ ਨਤੀਜਾ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਆਮ UDP ਜਾਂਚ ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰੇਗੀ।
ICMP ਨਾ-ਪਹੁੰਚ ਇੱਕ ਹੋਰ ਕਿਸਮ ਦਾ ਸਬੂਤ ਹੈ। ਇਸ ਦੇ ਅੰਦਰ ਦਰਜ ਪੈਕਟ ਪੜ੍ਹੋ ਅਤੇ ਪਛਾਣੋ ਕਿ ਕਿਹੜੇ ਜੰਤਰ ਨੇ ਇਹ ਭੇਜਿਆ, ਕਿਉਂਕਿ ਰਾਊਟਰ ਦਾ ਪ੍ਰਸ਼ਾਸਕੀ ਇਨਕਾਰ ਦੂਰ ਦੇ ਸਿਰੇ ਤੋਂ ਪ੍ਰਮਾਣਿਤ ਗਲਤੀ ਨਹੀਂ ਹੈ।
tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code
ਜਿੱਥੇ ਪੜ੍ਹਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ ਉੱਥੇ ਇਸੇ ਯਤਨ ਨੂੰ ਸਰਵਰ-ਪਾਸੇ ਦੇ ਲਾਗ ਨਾਲ ਮਿਲਾਓ। ਬੇਨਤੀ ਪਹੁੰਚੀ, ਸੇਵਾ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, ਅਤੇ ਜਵਾਬ ਕਿੱਥੇ ਰੁਕਿਆ? ਉਹ ਤਿੰਨ ਜਵਾਬ ਤੁਹਾਨੂੰ ਮਾਰਗ ਦੀ ਸਮੱਸਿਆ ਜਾਂ ਨੀਤੀ ਦੀ ਸਮੱਸਿਆ ਵੱਲ ਭੇਜਦੇ ਹਨ, ਅਤੇ ਚੌਥੀ ਵਾਰ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਬਦਲਣ ਨਾਲੋਂ ਘੱਟ ਖਰਚੇ ਵਾਲੇ ਹਨ।