1. Предисловие

tcpreplayявляется мощнымсеть Инструмент воспроизведения пакетов,Он может воспроизводить захваченный сетевой трафик (обычно файл формата pcap) обратно в сеть.,Добиться воспроизводства сетевой связи. Это широко применяется при устранении неполадок в сети, тестировании безопасности, тестировании производительности, разработке и отладке и других сценариях. в то же время,tcpreplay может не только воспроизводить сообщения протокола TCP,Поддерживает воспроизведение всех сообщений протокола.,Поддерживает стеки протоколов IPv4 и IPv6.,Не вводите в заблуждение название,Аналогия с названием tcpdump,tcpdump также может захватывать все сообщения протокола, а не только TCP.

TCPReplay содержит несколько основных компонентов и функций:

В этой статье в основном будет описано, как первые три инструмента, а именно инструмент tcpreplay replay, tcprewrite rewriting и tcppgrep, используются вместе в различных сценариях приложений.

2. Полный повтор или повтор с фильтром: какой метод выбрать?

Перед воспроизведением лучше всего заранее подтвердить, следует ли воспроизводить весь файл pcap или выборочно фильтровать определенные пакеты, а затем воспроизводить их. Возможно, вы захотите взглянуть на преимущества и недостатки каждого сценария и то, что следует сделать. метод выбора и способы фильтрации конкретных сообщений.

1. Полный повтор всего файла pcap.

преимущество:

• Гарантированная оригинальная последовательность запроса-ответа,Может более точно моделировать реальные взаимодействия.
• Полностью воспроизводимый, включая рукопожатие、Сертификация、Все действия, включая обмен данными и т. д.

недостаток:

• Может содержать нерелевантный трафик, влияющий на эффективность тестирования.
• Если файл pcap слишком велик, воспроизведение будет потреблять много ресурсов и занимать много времени.

2. Фильтруйте определенные сообщения и затем воспроизводите их.

преимущество:

• Больше внимания уделять запросам, инициированным клиентом.,Тестовые сценарии можно контролировать более точно.
• Время повтора можно сократить.

недостаток:

• Если ответ сервера влияет на последующие запросы, простое воспроизведение запроса может привести к неточным результатам теста.
• Некоторая важная контекстная информация может быть пропущена, например, предыдущий процесс рукопожатия или последующие взаимодействия.
• Добавьте этапы работы.

3. Как выбрать?

Выбирайте в зависимости от цели тестирования:

• если для проверки функции отправки клиента,Или смоделируйте клиента для запуска атаки,Более целесообразно фильтровать и воспроизводить сообщения, отправленные клиентом.
• Если вы хотите протестировать все взаимодействие, включая ответ сервера, более подходящим будет полный повтор.

Выбирайте в зависимости от размера файла pcap:

• Если файл pcap слишком велик, воспроизведение фильтра может повысить эффективность.

По сетевому окружению:

• еслисеть Окружающая среда сложна,Есть помехи,Полный повтор лучше имитирует реальную среду.

Если вы не уверены, какой метод использовать, рекомендуется воспроизвести целостность.

4. Как фильтровать?

Tcpdump, tshark и Wireshark могут фильтровать, а затем записывать пакеты.

1.tcpdump

Например, если вы хотите отфильтровать файл пакета client.pcap и записать пакеты с исходным IP-адресом 192.168.1.100 в client_requests.pcap, это может быть:

tcpdump -r client.pcap -w client_requests.pcap src 192.168.1.100

2.tshark

IP-адрес источника фильтра — 192.168.1.100, а запрошенный порт протокола назначения — TCP 80, который может быть:

tshark -n -q -r client.pcap -Y 'ip.src==192.168.1.100&&tcp.dstport==80' -w client_requests.pcap

3.Wireshark

В Wireshark напрямую введите выражение фильтра и щелкните панель параметров в верхнем левом углу. документ（File）--> Экспортировать определенную группу (Экспорт Specified Пакеты).

Например, если вы хотите фильтровать только запросы на установление соединения SYN, инициированные клиентом, выражение фильтрации может быть следующим:

ip.src==192.168.1.3 && tcp.flags.syn==1 && tcp.flags.ack==0

3. Установка

1. Установите из исходного кода программного обеспечения.

2. Скомпилируйте и установите

приезжатьtcpreplayизстраница релизовЗагрузите последнюю версию,Например, последняя версия — v4.5.1:

cd /opt
wget https://github.com/appneta/tcpreplay/releases/download/v4.5.1/tcpreplay-4.5.1.tar.gz

Затем распакуйте, скомпилируйте и установите гиперссылку на двоичный файл:

tar xf tcpreplay-4.5.1.tar.gz
cd tcpreplay-4.5.1.tar.gz
./configure 
make
make install
ln -s /opt/tcpreplay-4.5.1/src/tcpreplay /bin/tcpreplay
ln -s /opt/tcpreplay-4.5.1/src/tcprewrite /bin/tcprewrite

После завершения вы можете просмотреть установленную на данный момент версию с помощью следующей команды:

tcpreplay -V
tcprewrite -V

4. Практические занятия

1. Меры предосторожности

1) Направление воспроизведения и восприятие сообщения

Воспроизведение может выполняться на клиенте, на сервере или даже по запросу воспроизведения в изолированной экспериментальной среде.

Если на клиенте выполняется воспроизведение, воспроизводится весь пакет с одним кадром сообщения в качестве измерения только в направлении, отправленном клиентом к месту назначения. Во время воспроизведения пункт назначения может получить эту часть пакета и когда. воспроизведение на клиенте Пакеты, отправленные в направлении от пункта назначения, могут быть получены только самим клиентом и не могут быть обнаружены сервером;

Аналогично, если воспроизведение выполняется на сервере с одним кадром сообщения в качестве измерения, то во время воспроизведения клиент может принять только направление передачи от сервера к клиенту, а данные передаются от клиента к сервер воспроизводится на сервере. Направление может быть получено только сервером, а не клиентом.

2) Почему не рекомендуется использовать -i Any для захвата пакетов и последующего их воспроизведения?

Захват пакетов в Linux,если Интерфейс захвата пакетов указывается как-i any（напримерtcpdump -i any）,То есть захватить все сетевые карты,На этом этапе уровень канала передачи данных больше не может отображаться как Ethernet.,СкорееLinux cooked capture v2(SLL),Это псевдопротокол в Linux,Потому что не все интерфейсы на машине имеют одинаковый заголовок канального уровня.,ссылкаОписание официального сайта Wireshark。В этом случае tcpreplay не может воспроизводить такие пакеты без заголовка Ethernet. Вы обнаружите, что воспроизведение не имеет никакого эффекта, пакет не может быть отправлен или сообщается об ошибке. Поэтому перед воспроизведением файла pcap убедитесь, что в сети есть Ethernet. заголовок пакета.

Обычный заголовок Ethernet:

Заголовок SLL:

3) Воспроизведение пакетов не имитирует поведение стека протоколов TCP.

tcpreplay просто воспроизводит сообщение,Не моделирует поведение стека протоколов TCP.,Или, скорее,,Он не несет ответственности за поддержание состояния TCP-соединения.。Так что он не обрабатывает это автоматическиTCPиз Процесс трехстороннего рукопожатия и взаимодействиедля。напримерклиентпереигралSYNсообщение,Сервер ответил на сообщение SYN-ACK,Но поскольку tcpreplay не обрабатывает автоматически процесс трехэтапного установления связи TCP,клиент не отправил сообщение ACK для завершения рукопожатия,Вызывает отказ в соединении. Поэтому не удивляйтесь, увидев, что этот тип воспроизведения TCP включает в себя множество сценариев, в которых соединение не может быть установлено обычным образом и будет RST.,как и ожидалось.

Учитывая это, это может быть относительно абстрактно, и вы не знаете, что это значит. Давайте посмотрим на следующие примеры.

2. Полный повтор

В сценарии полного воспроизведения каждый кадр файла захвата пакета pcap воспроизводится в сети.

Например, следующий сценарий:

Сначала мы захватываем сегмент сообщений ICMP и TCP-порта 80 на клиенте:

tcpdump -i eth0 -nn host 192.168.1.8 and \( tcp port 80 or icmp \) -v -w client.pcap

У нас уже есть исходный файл захвата пакетов pcap. Мы используем tcpreplay для полного воспроизведения файла пакета и одновременно развертываем захват пакетов на клиенте и сервере, чтобы увидеть, какова производительность.

Сначала нам нужно обновить контрольную сумму по TCP в сообщении client.pcap и вывести ее как client_fix.pcap:

tcprewrite --infile=client.pcap --outfile=client_fix.pcap --fixcsum

1) Зачем нужно обновлять контрольную сумму?

Контрольная сумма (checksum) — это значение, полученное в результате вычисления данных. Отправитель и получатель рассчитают одну и ту же контрольную сумму для одних и тех же данных. Если контрольная сумма, рассчитанная получателем, не соответствует контрольной сумме, предоставленной отправителем, это означает, что во время передачи данных произошла ошибка, и получатель отбросит пакет данных. Например, если csum не будет обновлен, противоположный конец. получит дублирующее сообщение. Если пакет выпущен и проверка неверна, он не ответит нормально и будет удален напрямую:

Вы также можете подсчитать количество пакетов ошибок контрольной суммы, полученных с помощью netstat:

netstat -s|grep -i sum

Из приведенного выше рисунка нетрудно обнаружить, что, когда контрольная сумма не обновляется, файл client.pcap воспроизводится напрямую. Клиент отправляет на сервер четыре TCP-пакета, но сервер проверяет csum неправильно и не отвечает клиенту. В это время значение InCsumErrors также увеличилось ровно на 4.

Сравнивая два файла pcap до и после восстановления, можно увидеть, что поле контрольной суммы явно изменилось, тогда как остальные поля остались неизменными:

2) Запустить полный повтор

После обновления контрольной суммы переигрываем client_fix.pcap целиком:

tcpreplay -v -t -i eth0 client_fix.pcap #-vпараметр позволяет просмотреть детали каждого воспроизводимого кадра; -tпараметр воспроизводит пакет как можно быстрее;

Внизу будет отображаться объем воспроизведенных пакетов, потребление времени, скорость отправки пакетов в секунду, пропускная способность, количество потоков, объем успешных пакетов, объем неудачных пакетов, объем усеченных пакетов, объем пакетов повторной передачи и другая статистическая информация.

Воспроизводя сообщение, мы захватываем пакеты на клиенте и сервере одновременно.

На этом этапе мы сначала сравниваем исходный пакет client_fix.pcap после обновления контрольной суммы и пакет client_replay.pcap, захваченный на клиенте после воспроизведения исходного пакета. В чем разница:

• 1-6 кадров,клиент закончил воспроизведение исходного сообщения,Это одна и та же часть обоих пакетов.
• Начиная с фрейма 7, клиент получил SYN, отправленный с Сервера.,На сообщение ACK второго рукопожатия отвечает второй кадр, что также соответствует ожиданиям. Сервер получил запрос SYN от клиента и ответил SYN.,ACKочень разумно,Просто скорость восстановления медленнее скорости воспроизведения клиента,Потому что клиенту не нужно ждать установления соединения,Он просто воспроизводит пакеты в pcap как можно быстрее.,Скорость доставки определенно будет очень быстрой,Он не требует какой-либо логики, такой как таймер TCP 0,2 с и повторная передача по тайм-ауту.,Примечания также были упомянуты ранее,это Не моделирует поведение стека протоколов TCP.。
• Дошёл до 8 кадра,клиент заранее отправил RST в ответ на кадр 7 ответа Сервера,По мнению клиента,На данный момент у меня больше нет TCP-соединений в состоянии SYN_SENT.,Сервер отправит мне SYN, что означает ACK?,Прямо откажитесь от RST.
• Кадры 10 и 11,Его можно найти по порядковому номеру SEQ RST.,клиент получил RST для Сервера,даRSTДайте первый5рамкаFIN,ACK, поскольку Сервер также почувствовал, что это TCP-соединение не было установлено нормально, клиент дал мне FIN.,ACKда В чем смысл,Какое соединение я хочу прекратить размахивать? Не знаю,прямой РСТ отказался.
• Та же причина,Кадр 12,Это также 6-й кадр ACK, который Сервер ответил на RST клиенту.,Посмотрите это в Сервере,Отправьте мне подтверждение из ниоткуда,РСТ отказался.

Почему РСТ?

Возвращаясь к мерам предосторожности, упомянутым ранее, поскольку пакеты данных, воспроизводимые tcpreplay, не моделируют поведение стека протоколов TCP и не поддерживают состояние TCP-соединения, они просто отправляют сообщения в pcap. В это время оба конца будут доступны всем. есть сомнения. Понятно, что TCP-соединение не установлено. Почему оно отправляет мне пакеты со странными флагами? Эти пакеты не могут быть обработаны нормально, поэтому я буду использовать RST, чтобы ответить вам.

Кстати, использование nping для указания флага также позволяет моделировать и тестировать этот тип сценария RST. Например, клиент отправляет на сервер какие-то необъяснимые пакеты флага:

nping --tcp -p 80 --flag ACK 192.168.1.8       # Отправить пакет ACK на Сервер
nping --tcp -p 80 --flags SYN,ACK 192.168.1.8  # Отправить пакет SYN, ACK на Сервер
nping --tcp -p 80 --flags FIN,ACK 192.168.1.8 # Отправить FIN,Пакет ACK для Сервера

Все без исключения такие пакеты были удалены RST.

Далее мы сравниваем пакет client_replay.pcap, захваченный клиентом, с пакетом server.pcap, захваченным сервером:

Сравнивая ip.id и контрольную сумму, можно обнаружить несколько характеристик:

Если пакет, воспроизведенный клиентом, отправляется с сервера клиенту, клиент воспроизводит его только самому себе. Он не может отправить копию на сервер. Он может быть воспроизведен на сервер только с клиента. сервером, как показано на рисунке server.pca выше. SYN (1-й кадр), ACK (3-й кадр), FIN, ACK (4-й кадр), ACK (7-й кадр) в p, а остальные кадры, такие как SYN, ACK (2-й кадр), представляют собой ответ сервера в реальном времени, не генерируется повтор, воспроизводится SYN, ACK Контрольная сумма — 0xb783, контрольная сумма SYN и ACK ответа сервера в реальном времени — 0x8395, а остальные одинаковы.

Итак, делаем вывод:

• клиент Воспроизвести полный пакет,Серверу не требуется отвечать на эти пакеты воспроизведения.,Вместо этого отправьте эти пакеты полностью;
• клиент При воспроизведении пакета,Для данных от клиента к Серверу,Сервер можно получить,Данные отправляются с Сервера в сторону клиента,клиента можно воспроизвести только самому себе,Нет возможности попросить Сервер отправить такой пакет данных;
• По мнению Сервера,Потому что воспроизведенный пакет не имеет реального атрибута соединения.,Сервер Даже в ответ на второе рукопожатие SYN,ACK и соединение не могут быть установлены, поэтому для последующих ACK и FIN, отправленных клиентом,ACK и т. д. отправят RST для ответа на сообщение этого типа.

Теперь, когда мы закончили чтение части TCP, давайте посмотрим на часть ICMP.

В то же время откройте пакет client_fix.pcap, который необходимо воспроизвести, пакет захвата пакетов client_replay.pcap в реальном времени на клиенте во время воспроизведения и пакет захвата пакетов в реальном времени server.pcap на сервере во время воспроизведения:

Сравнивая ip.id, нетрудно обнаружить, что он имеет некоторое сходство с приведенным выше выводом:

• клиент Воспроизвести полный пакетчас,прошлоеизнаправлениеicmp запрос и icmp со стороны входящего все ответы будут воспроизведены;
• для ICMP request,Это действительно было воспроизведено на Сервере.,Сервер получен,и ответил;
• Для воспроизведенного icmp ответ, клиент будет воспроизведен самому себе, плюс icmp ответа Сервера в режиме реального времени ответ, поэтому при захвате пакетов клиента в реальном времени появляется дубликат icmp. ответ ответ.

3. Воспроизведение однонаправленных пакетов.

Воспроизводятся только пакеты, отправленные клиентом. На примере client.pcap мы отфильтровываем пакеты, отправленные клиентом:

tcpdump -r client.pcap src 192.168.1.14 -w client_requests.pcap

Выполните восстановление csum:

tcprewrite --infile=client_requests.pcap --outfile=client_fix.pcap --fixcsum

Воспроизведите обновленный пакет csum на сервере:

tcpreplay -v -i eth0 -p 1000 client_fix.pcap # -p указывает скорость отправки пакетов в секунду

В это время из захвата пакета на сервере видно, что клиент воспроизвел SYN (первое рукопожатие), ACK (третье рукопожатие), FIN, ACK (волну приложения) и ACK (волну подтверждения) одновременно. для однонаправленных пакетов в настоящее время также очень интересна обработка на стороне сервера:

• Сервер ответил SYN,ACK для ответа на первое рукопожатие SYN клиента, поскольку промежуточный канал также требует много времени. С точки зрения клиента, этот SYN.,Очевидно, что ACK не так быстр, как скорость отправки пакетов клиента, поэтому он происходит в последних нескольких кадрах;
• Сразу после этого,Сервер ответил RST, чтобы ответить на FIN,ACK, отправленный клиентом., поскольку, по данным Сервера, это TCP-соединение не было нормально установлено, клиент отправил FIN,ACK,Сервер не понимаю, что это значит,Прямой отказ в RST;
• В то же время клиент также отправляет RST в ответ на SYN, отправленный Сервером.,ACK, потому что, по мнению клиента, отправленный партнером SYN не понятен.,Что такое ACK? В состоянии SYN_SENT нет соединения.

4. Воспроизведение определенных сообщений

Воспроизведение определенных сообщений очень полезно для бизнес-сценариев со сложными средами и сценариями протоколов уровня приложений, разработанными самостоятельно. Оно устраняет некоторые факторы помех и делает эксперимент по воспроизведению более чистым и кратким. Ниже показано воспроизведение первого запроса SYN и DNS-подтверждения. Запросить повтор, например.

1) Воспроизведите сообщение SYN первого рукопожатия.

Например, сообщение client_tcp.pcap содержит несколько полных запросов на установление соединения с портом 80 сервера внутренней и внешней сети:

Нам нужно только воспроизвести первое рукопожатие SYN. ​​Во-первых, нам нужно отфильтровать пакеты с битом флага SYN 1 и ACK 0 и сохранить их как client_syn.pcap:

tcpdump может быть:

tcpdump -r client_tcp.pcap 'tcp[tcpflags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) == 0' -w client_syn.pcap

tshark может быть:

tshark -n -q -r client_tcp.pcap -Y 'tcp.flags.syn==1&&tcp.flags.ack==0' -w client_syn.pcap

Отфильтрованное содержимое client_tcp.pcap выглядит следующим образом:

Далее мы используем tcprewrite для обновления контрольной суммы:

tcprewrite --infile=client_syn.pcap --outfile=client_syn_fix.pcap --fixcsum

Все готово для начала воспроизведения. Перед этим захватываем пакеты при развертывании клиента:

tcpdump -i eth0 -nn -s 0 tcp port 80 -v -w client_syn_replay.pcap

Сразу после этого используйте tcpreplay, чтобы начать воспроизведение:

tcpreplay -v -t -i eth0 client_syn_fix.pcap

Давайте посмотрим на захват пакетов на клиенте в реальном времени:

Четыре повтора SYN успешно получили ответы SYN и ACK с противоположного конца. Затем клиент отправил SYN и ACK с противоположного конца. Поскольку клиент воспроизвел сообщение, не было установлено TCP-соединение и стек протокола TCP не был установлен. поэтому tcpreplay не будет автоматически обрабатывать процесс трехстороннего установления связи TCP. Прочитав предыдущие меры предосторожности, вы поймете, что отправка RST очень разумна.

2) Воспроизвести запрос запроса DNS

Например, файл захвата пакетов dns.pcap содержит ряд запросов DNS. Мы хотим отдельно отфильтровать запросы DNS и воспроизвести их.

Сначала отфильтруйте запрос DNS и сохраните его как dns_query.pcap:

tcpdump -n -r dns.pcap 'udp port 53 and udp[10] & 0x80 == 0' -w dns_query.pcap

или:

tshark -n -q -r dns.pcap -Y 'dns.flags.response == 0' -w dns_query.pcap

Обновите контрольную сумму, на выходе будет dns_query_fix.pcap:

tcprewrite --infile=dns_query.pcap --outfile=dns_query_fix.pcap --fixcsum

Затем мы получили пакет pcap, который можно использовать для воспроизведения:

Всего четыре запроса записи A, соответствующие двум DNS-серверам интрасети.

На этом этапе мы можем начать воспроизведение dns_query_fix.pcap. В то же время мы перехватываем пакеты на клиенте, чтобы посмотреть, сможем ли мы получить ответ от сервера:

tcpdump -i eth0 -nn -s 0 udp port 53 -v -w client_dns.pcap
tcpreplay -v -t -i eth0 dns_query_fix.pcap

Используйте Wireshark, чтобы открыть файл перехвата клиентских пакетов client_dns.pcap:

Клиент видел повтор четырех записей A, а сервер отвечал одну за другой. Сервер dnsmasq также может запрашивать этот журнал:

5. Перезапишите IP-адрес источника/IP-адрес назначения/MAC-адрес источника/MAC-адрес назначения, а затем воспроизведите заново.

Информация, содержащаяся в известном файле client.pcap, следующая:

Предполагая, что по причинам производственной среды,1.14 Производственные машины больше нельзя использовать для воспроизведения.,В настоящее время мы хотим провести эксперименты по воспроизведению на других клиентах и ​​серверах.,Например, 192.168.1.12 для повтора.,Повтор до 192.168.1.72,Информация следующая:

Поскольку направление перезаписи tcprewrite является источником и местом назначения каждого измерения кадра, он не различает IP или MAC, а только левое и правое направления. Например, интерактивное сообщение выглядит следующим образом:

A --icmp request--> B
B --icmp reply  --> A

Эти два обычных сообщения взаимодействия имеют разные направления. С точки зрения tcprewrite, источник первого сообщения — A, пункт назначения — B, а источник второго сообщения — B, а пункт назначения — A. Если вы напрямую используете tcprewrite для измените адрес источника и адрес назначения, например, перезаписав источник на a и пункт назначения на b, это приведет к следующим последствиям:

a --icmp request--> b
a --icmp reply  --> b

С первым сообщением проблем нет, но есть проблема со вторым сообщением. Направление изменилось. Правильное направление должно быть:

b --icmp reply --> a

Поэтому, чтобы правильно переписать источник и место назначения всего сообщения и обеспечить правильное направление, необходимо выполнить несколько громоздкие шаги:

1) Разбить сообщение на пакеты в двух направлениях

Распаковку можно выполнить с помощью tcpdump, tshark или Wireshark.,Просто отфильтруйте нужное нам направление пакета и запишите его в новый файл pcap, например, направление выхода клиента;,tcpdump может быть:

tcpdump -r client.pcap src 192.168.1.14 -w client_src.pcap

tshark может быть:

tshark -n -q -r client.pcap -Y 'ip.src==192.168.1.14' -w client_src.pcap

Вы можете выбрать один из вышеперечисленных методов, чаще используется tcpdump.

Сервер Входящее направление:

tcpdump -r client.pcap dst 192.168.1.14 -w client_dst.pcap

Разделив пакеты на два направления, вы увидите, что каждый пакет представляет собой однонаправленное сообщение:

2) Перепишите источник и пункт назначения двух пакетов соответственно.

Сначала перезапишите IP-адрес источника, IP-адрес назначения, MAC-адрес источника и MAC-адрес назначения для пакетов в направлении источника:

Соответствующий метод записи tcprewrite может быть:

tcprewrite --infile=client_src.pcap --outfile=client_src_rewrite.pcap -S 0.0.0.0/0:192.168.1.12 -D 0.0.0.0/0:192.168.1.72 --enet-smac=00:50:56:81:8e:44 --enet-dmac=00:50:56:81:be:58

Та же причина,Перепишем пакет в сторону Сервера:

tcprewrite --infile=client_dst.pcap --outfile=client_dst_rewrite.pcap -S 0.0.0.0/0:192.168.1.72 -D 0.0.0.0/0:192.168.1.12 --enet-smac=00:50:56:81:be:58 --enet-dmac=00:50:56:81:8e:44

После перезаписи IP-адреса источника и назначения, а также MAC-адреса источника и назначения были изменены с производственной машины на нашу экспериментальную машину:

3) Объедините два переписанных пакета.

Просто используйте mergecap для слияния. По умолчанию они будут объединены в хронологическом порядке:

mergecap -w client_rewrite.pcap client_src_rewrite.pcap client_dst_rewrite.pcap

После объединения пакета четыре из пяти кортежей были, наконец, нормально изменены и переписаны в желаемый экспериментальный объект:

Вы можете выполнить операцию воспроизведения tcpreplay для этого пакета позже.

4) Воспроизвести сообщение

Перед повтором не забудьте обновить контрольную сумму:

tcprewrite --infile=client_rewrite.pcap --outfile=client_rewrite_fix.pcap --fixcsum

Затем поместите пакеты client_rewrite_fix.pcap, которые необходимо воспроизвести, на источник 192.168.1.12 для воспроизведения (конечно, вы также можете поместить их на Сервер для воспроизведения):

tcpreplay -v -t -i ens160 client_rewrite_fix.pcap

При захвате пакетов на Сервере вы также можете получать пакеты повтора, отправленные клиентом, в обычном режиме:

5) Другая альтернатива (tcpprep, конечные точки, кеш)

Вышеупомянутые шаги по распаковке, обработке и объединению пакетов относительно громоздки. Для реализации этого существует другой способ использования tcpprep.

В качестве примера возьмем следующий сценарий:

Предполагая, что по причинам производственной среды,1.14 Производственные машины больше нельзя использовать для воспроизведения.,В настоящее время мы хотим провести эксперименты по воспроизведению на других клиентах и ​​серверах.,Например повтор в 1.12,Переиграй на 1.72,Информация следующая:

Используйте tcpprep для классификации пакетов данных в файле pcap по клиенту и серверу.

Способ первый：Воляclient.pcapв файлеIPдля192.168.1.14/32изнастраиватьдляclientконец,Остальные считаются серверными:

tcpprep -c 192.168.1.14/32 -i client.pcap -o client.cache

В это время создается файл кэша. Этот файл кэша будет использоваться при последующей перезаписи tcprewrite. Сгенерированное содержимое выглядит следующим образом:

Способ 2：позволятьtcpprepИспользовать автоматический/clientРежим субупаковки генерирует файлы кэша：

tcpprep -a client -i client.pcap -o client.cache

Содержание следующее:

В автоматическом режиме tcpprep считает клиентами IP-адреса со следующими характеристиками:

• Отправить пакет TCP SYN;
• Отправить пакет DNS-запроса;
• Полученный ICMP-порт недоступен Порт недоступен;

Серверными считаются те, которые имеют следующие характеристики:

• Отправить TCP SYN, ACK;
• Отправить DNS-ответ;
• Отправить ICMP-Порт недоступен Порт недоступен;

Если вы уже четко знаете, какие IP-адреса являются исходными, рекомендуется использовать первый метод.

Затем мы используем tcprewrite для изменения IP-адреса источника/IP-адреса назначения/MAC-адреса источника/MAC-адреса назначения и обновляем контрольную сумму:

tcprewrite --enet-smac=00:50:56:81:8e:44,00:50:56:81:be:58 --enet-dmac=00:50:56:81:be:58,00:50:56:81:8e:44 --endpoints=192.168.1.12:192.168.1.72 --infile=client.pcap -c client.cache --outfile=client_rewrite_fix.pcap --fixcsum

На этом этапе мы изменили IP-адрес источника/IP-адрес назначения/MAC-адрес источника/MAC-адреса назначения файла сообщения, который необходимо воспроизвести сразу. Все соответствует ожиданиям. Затем мы можем продолжить выполнение описанных выше шагов воспроизведения.

6. Перепишите исходный порт/порт назначения, а затем воспроизведите его.

Когда порт службы изменяется или порт источника/назначения занят, и порт необходимо изменить для воспроизведения пакета данных, вам пригодится параметр -r/--portmap команды tcprewrite. Этот параметр может перезаписать источник. Порт назначения TCP и UDP. Использование может представлять собой диапазон портов или несколько конкретных портов, измененных на указанный порт.

Например, в следующем сценарии исходная пятерка бизнес-доступа в пакете pcap:

Почему-то исходный порт60000/60001, порт назначения22 заняты другими предприятиями,Во время повтора,Необходимо исправить на последний бизнес-порт:

В настоящее время известно сообщение Client.pcap Содержание. следующее:

То есть клиент использует 60000 и 60001 в качестве исходного порта для отправки TCP-зонда на порт Сервер22 соответственно.

Во время повтора,Порты 60000 и 60001 необходимо изменить на порты 60002.,Назначение порта22 изменено на 22222. Выходные данные порта — client_port_changed.pcap.,Тогда tcprewrite можно записать так:

tcprewrite --portmap=60000-60001:60002 --portmap=22:22222 --infile=client.pcap --outfile=client_port_changed.pcap

В то же время обновите значение csum, и на выходе будет client_port_changed_fix.pcap:

tcprewrite --fixcsum --infile=client_port_changed.pcap --outfile=client_port_changed_fix.pcap

В это время может появиться предупреждение, и некоторые пакеты невозможно изменить, заставив параметр --fixcsum обновить csum:

В качестве альтернативы можно использовать --fixhdrlen, который изменяет заголовок TCP/IP в соответствии с длиной пакета:

tcprewrite --fixhdrlen --infile=client_port_changed.pcap --outfile=client_port_changed_fix.pcap

На этом этапе используйте Wireshark, чтобы просмотреть окончательный пакет client_port_changed_fix.pcap, который нам нужно воспроизвести:

Назначение исходного порта было успешно изменено. Далее просто воспроизведите пакет pcap в обычном режиме.

tcpreplay -i eth0 -v -t client_port_changed_fix.pcap

Вы можете увидеть это в захвате пакета Сервера.,запрос клиента на воспроизведение получен,И значение csum правильное.

7. Некоторые параметры, управляющие скоростью воспроизведения и количеством циклов.

Если вам нужно контролировать скорость воспроизведения или количество циклов, вам пригодятся следующие параметры:

Например, я хочу настроить цикл на воспроизведение 10 раз с интервалом 100 мс между циклами и на самой высокой скорости. Это может быть:

tcpreplay -i eth0 --loop=10 --loopdelay-ms=100 -t client_replay.pcap

Или я хочу, чтобы воспроизведение останавливалось после воспроизведения 10 пакетов, а скорость отправки пакетов составляла 2 пакета в секунду, что может быть:

tcpreplay -i eth0 --limit=10 --pps=2 client_replay.pcap

Другие параметры не будут отображаться по одному и могут использоваться в комбинации в соответствии с потребностями. Некоторые параметры будут взаимоисключающими и не могут отображаться одновременно.

8. Предварительная загрузка пакетов данных в память перед воспроизведением.

Одно важнееиз Улучшите производительностьизпараметр-K/--preload-pcap,Эта опция загружает указанный pcap в память (ОЗУ) перед началом отправки.,для улучшения производительности воспроизведения,В то же время это оказывает определенное влияние на производительность запуска.,потому чтодлясуществовать Прежде чем tcpreplay начнет отправлять пакеты, существует начальная задержка для загрузки всех пакетов в память. Эта опция также подавляет сбор статистики потока для каждой итерации, что может значительно уменьшить потребление памяти.

Преимущество этого подхода заключается в том, что он может сократить операции ввода-вывода на диске, поскольку пакеты данных считываются непосредственно из памяти, а не с диска, что значительно повышает скорость отправки пакетов данных и общую производительность воспроизведения, особенно для некоторых больших компьютеров. Эффект более очевиден, когда пакет необходимо зациклить и воспроизвести несколько раз.

Сотрудничество--loopпараметриспользоватьизслучай,Статистика трафика прогнозируется на основе данных, собранных во время первой итерации цикла, и опций, предоставленных пользователем.,Это может значительно сократить использование памяти.,Потому что нет необходимости хранить подробную статистику по каждому циклу. даже в нескольких циклах,Пакет данных будет предварительно загружен только один раз.,То есть до начала первого цикла.

Например, я хочу зациклить воспроизведение 500 раз с задержкой между циклами 10 миллисекунд и воспроизвести все пакеты как можно быстрее. Это может быть:

tcpreplay -i eth0 -K -t --loop=500 --loopdelay-ms=10 client_replay.pcap

Первая строка выводится"File Cache is enabled",Кэширование описаний включено,Этот процесс может занять некоторое время,Это время, необходимое для предварительной загрузки файлов пакета в память.

5. Резюме

На данный момент в этой статье систематически представлено применение tcpreplay и связанных с ним инструментов для сетевого тестирования, оценки безопасности и диагностики ошибок. Сначала описываются основные функции tcpreplay, включая воспроизведение сетевого трафика, настройку скорости воспроизведения и времени цикла и т. д., а также подчеркивается его важность в воспроизведении сетевых взаимодействий и всестороннем тестировании поведения сети. Затем подробно обсуждаются преимущества, недостатки и применимые сценарии полного воспроизведения и фильтрованного воспроизведения, чтобы помочь читателям выбрать подходящую стратегию воспроизведения в соответствии с фактическими потребностями.

Он также демонстрирует, как использовать такие инструменты, как tcpdump и tshark, для фильтрации пакетов и их перезаписи с помощью tcprewrite.,для более точного контроля тестового трафика,и продемонстрировал посредством практических упражнений, как изменить Исходный IP-адрес、IP-адрес назначения、Исходный MAC-адрес、Используйте MAC-адрес назначения и другую информацию для управления потоком.

Наконец, в статье обобщаются ключевые параметры и методы повышения производительности воспроизведения, такие как предварительная загрузка файлов pcap в память, настройка коэффициента воспроизведения и т. д. Эти материалы не только повышают эффективность и точность сетевого тестирования, но также предоставляют практические рекомендации для специалистов по сетевой безопасности и тестировщиков. Наконец, я надеюсь, что эта статья может быть вам полезна.

Прикреплена PDF-версия этой статьи: