Mga muling pagpapadala ng TCP laban sa mga pagtanggi sa replay ng IPsec: basahin ang bawat layer

Tatlong magkaibang tool ang nag-uulat ng tatlong magkaibang duplicate, at isa lamang sa kanila ang pangyayari sa network na maaari mong aksyunan. Ang muling pagpapadala ng TCP ay isang nagpadala na muling nagpapadala ng isang saklaw, ang dobleng ACK ay isang tumatanggap na inuulit ang isang pagpapatunay, at ang pagtanggi sa replay ng ESP ay isang samahan ng seguridad na tumatanggi sa isang sequence number na tinanggap na nito. Wala sa tatlo ang nagpapahiwatig ng iba pa. Basahin ang bawat counter sa layer na gumagawa nito bago mo pagsamahin ang mga ito sa isang kuwento.

Tatlong counter na hindi kailanman sumusukat sa parehong pangyayari

Ang anotasyon ng muling pagpapadala ng TCP ay nangangahulugang muling inilagay ng nagpadala ang isang saklaw ng sequence sa kawad. Ang pagkawala ay isa sa mga dahilan, at ang capture na hawak mo ay maaaring wala lamang ang orihinal na packet o ang pagpapatunay na magpapaliwanag sa oras. Ang dobleng ACK ay ang tumatanggap na inuulit ang isang cumulative na pagpapatunay ayon sa mga tuntunin ng recovery ng TCP, na hindi isang dobleng pagsulat ng application at hindi rin isang pangalawang kopya ng data.

Gumagana ang ESP sa sarili nitong espasyo ng sequence. Binibilang ng bawat samahan ng seguridad ang mga packet na ipinapadala nito, at nagtatago ang tumatanggap ng isang window ng mga numerong tinanggap na, kaya ang isang ESP packet na dumarating nang dalawang beses ay itinatapon sa basehang iyon lamang. Kaya ang isang muling ipinadalang TCP segment ay naglalakbay sa isang bagong ESP packet na may bagong sequence number, na tamang pag-uugali sa parehong layer. Ang parehong bytes ay maaaring magmukhang bago sa isang counter at luma sa iba, at walang layer ang nagsisinungaling.

Ano ang nakikita at hindi nakikita ng analyzer

Magsimula sa bokabularyo ng analyzer, dahil inilalarawan ng mga pangalan ng filter ang mga obserbasyon at hindi ang loob ng mga endpoint. Ang pagbilang gamit ang parehong mga pangalan na ginagamit ng tool ay nagpapanatili sa iyong tapat tungkol sa talagang sinukat. Ang bilang mula sa isang hindi kumpletong capture ay bilang ng nabuhay, hindi ng nangyari sa kawad.

tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l

Basahin ang impormasyong pantasya sa tabi ng mga numerong iyon, dahil binabago ng mga babala sa checksum at pagkakasunod-sunod kung gaano kalaking bigat ang nararapat sa kanila. Ang pinagsamang bakas mula sa dalawang sensor ay maaaring magpakita ng isang frame nang dalawang beses, at ang pagbilang ng parehong kopya ay lumilikha ng pangyayari ng recovery na hindi kailanman nangyari.

Nabubuhay ang mga counter ng ESP sa estado ng kernel

Ang mga sequence number ng ESP ay pag-aari ng samahan ng seguridad, hindi ng TCP stream, kaya ang gateway ang lugar na dapat tanungin. Ang listahan ng estado ay nag-uulat ng mga counter ng packet at error sa bawat samahan na walang capture ang makakabuo muli.

ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head

RFC 4303 ay tumutukoy sa sequence number at sa anti-replay window na gumagamit nito, kaya tumataas ang counter kahit walang mali. Ang mga panlabas na sequence number na monotoniko na walang katumbas na anomalya ng TCP ay tumuturo sa ibang nagpadala o isang nadobleng landas sa halip na sa isang bagyo ng muling pagpapadala. Ang panlabas na capture ng isang naka-encrypt na tunnel ay karaniwang nagtatago ng mga panloob na sequence number ng TCP, kaya hindi nito mapatunayan kung ano ang ginawa ng panloob na stack. Mag-capture lamang sa loob ng tunnel kung saan pinapayagan ng patakaran, at huwag kailanman patayin ang anti-replay para patahimikin ang isang walang kaugnayang babala.

Saan binabago ng punto ng obserbasyon ang sagot

Bago mag-escalate, isulat kung paano kinuha ang capture: ang interface, kung nag-ulat ng mga pagbagsak ang proseso ng capture, at kung maihahambing ang mga timestamp sa mga sensor. Ang isang punto ng obserbasyon ay hindi makikita ang dalawang dulo ng isang landas, kaya ang anumang pahayag tungkol sa pag-uugali ng tumatanggap ay isang hinuha at hindi isang pagsukat. Ang bakas na kinuha sa gateway at ang bakas na kinuha sa host ay hindi magkasundo tungkol sa pagkakasunod-sunod sa ilalim ng karga, at ang hindi pagkakasundong iyon ay karaniwang pag-aari ng capture at hindi ng tunnel. Ang pag-uugnay ng dalawang pananaw ang nagpapalit ng bilang tungo sa ebidensya.

Gumamit ng isang pinapayagang daloy ng application at itala ang mga counter ng endpoint sa tabi ng mga bilang ng capture sa parehong sandali. Kung hindi magkasundo ang mga numero, magtiwala sa layer na nagmamay-ari ng pangyayari at ituring ang isa pa bilang artefact ng obserbasyon hanggang mapatunayan ang kabaligtaran. Ang tuntuning iyon ay lumulutas sa karamihan ng mga ticket na ito nang hindi hinahawakan ang configuration ng tunnel.

Pagbasa ng mga numero sa tamang pagkakasunod-sunod

Magsimula sa layer kung saan itinanong ang tanong: ang babala ng TCP ay sinasagot mula sa isang capture ng TCP, at ang pagtanggi ng ESP ay sinasagot mula sa mga counter ng samahan ng seguridad sa gateway. Pagkatapos lamang tanungin kung inilalarawan ng dalawang pananaw ang parehong packet. Ang konklusyong nangangailangan ng parehong layer ay dapat pangalanan ang dalawa, dahil ang isang pahayag tungkol sa tunnel na nakasandal lamang sa anotasyon ng TCP ay isang hula.

Itala ang layer, counter at punto ng obserbasyon para sa bawat natuklasan, at hindi pagsasamahin ng susunod na mambabasa ang tatlong pangyayari sa isang guni-guning sira. Mag-escalate gamit ang tatlong field na iyon at ang pagwawasto ay karaniwang sumusunod mula sa una.