ОВС ядро может использовать систему отслеживания соединения (соединения системы слежения) вместе, означает функцию трассировщика, поток OpenFlow может быть использован, чтобы соответствовать соединенному состоянию TCP, UDP, ICMP и т.д. (Система отслеживания соединения поддерживает контакт с сохранением состояния и протокол без сохранения состояния).
В данном руководстве показано, как использовать OVS системы слежения за соединение. Для того, чтобы установить соответствие с подключения к сегменту TCP, соединяющим удалено. Ядро OVS и Linux модули вместе, как канал передачи данных для этой презентации. (данные Openvswitch с помощью обработки модуля ядра Linux выполняющейся).
Это демо был протестирован в филиале «мастер» Открытого VSWITCH.
Определения
трассировщик : модуль отслеживания соединений. С сохранением состояния проверки пакетов.
Трубопровод : конвейер обработки пакетов. Это когда пакет во время прохождения по пути через таблицу, то сообщение должно быть в соответствии с полем соответствия в таблице к потоку, и выполняет заданную операцию в этом потоке.
Сетевые пространства имен : в одном ядре Linux, создать несколько виртуальных доменов метод маршрутизации. Каждая сеть имеет свою собственную таблицу сетевого пространства имен экземпляра (ARP, маршрутизация), а также конкретное соединение интерфейса.
Поток : Это руководство OpenFlow поток, или он может использовать контроллер OpenFlow ОВС программирования инструментов командной строки, как он использован здесь овс-ofctl инструмента. Поток , имеющий поле соответствия и поле действия.
Трассировщик смежная область
Matching поле
OVS поддерживает следующие совпадения полей, связанный с трассировщика из:
- ct_state :
Совпадение сообщение о состоянии соединения Возможные значения:
- *new*
- *est*
- *rel*
- *rpl*
- *inv*
- *trk*
- *snat*
- *dnat*
Каждый со знаком «+» в качестве префикса, выраженного должны быть установлены, или «-» знак представлен в виде префикс не может быть установлен. Вы также можете указать несколько флагов, например ct_state = + TRK + новый. Здесь мы рассмотрим некоторые признаки использования. Подробные инструкции приведены в полях ОВС в документе .
- ct_zone : подключение зоны отслеживания независимы операции контекста путем установки КТ.
Последнее действие карат (по OpenFlow потока , расположенного на входе трассировщика) 16 заданное ct_zoneзначение может быть использовано в качестве соответствующей записи в другом поле потока.
-
ct_mark : Exec параметры действий по КТ в действие , установленное к соединению принадлежит текущий 32-битный пакет данных.
-
ct_label :
представленный оператор в параметре 128-битного с выполняемой операцией тега CT, подключен к текущему пакет принадлежит. -
ct_label :
Exec параметры действий по КТ в текущем действии используется для подключения пакета 128 принадлежит метка. -
ct_nw_src / ct_ipv6_src :
Match IPv4 / IPv6 адреса источника направления трассировки соединения исходного кортежа. -
ct_nw_dst / ct_ipv6_dst :
соответствие целевого адреса IPv4 / IPv6 направление отслеживания соединения исходного кортежа. -
ct_nw_proto :
соответствующий разъем ориентация оригинала отслеживания IP - кортежи типа протокола. -
ct_tp_src :
соответствующий кортеж транспортного уровня исходного соединения порт первоначального направления слежения. -
ct_tp_dst :
порт ответного разъема кортеж объект оригинального слой транспортировки направление отслеживания.
действие
OVS трассировщик поддержка подключения отслеживания и связанные с ним «каратами» действие.
*ct([argument][,argument...])*
CT бродилка посылает пакеты с подключенным трекере.
Он поддерживает следующие параметры:
-
коммит :
Connect представлен модуль отслеживания соединения, модуль для хранения этого соединения пакетов , превышающих жизненный цикл в трубопроводе. -
Сила :
В дополнение к выше фиксации внешнего флага, флаг сила может быть использована для эффективной прекратить существующее соединение и начать новое соединение в направлении тока. -
= Таблица номеров :
обработка трубы на две части . Исходное сообщение будет продолжать иметь дело с текущим действием в виде списка действий неотслеживаемых пакетов. Другой пример сообщения будет отправлен программа слежения подключена, то он будет повторно инъекционным трубопровод OpenFlow стола и продолжитьnumberлечение в этом случае он установлен ct_state карат статус соответствия матча и другие области. -
Зона = значение или SRC = Зона [... Начало Конец] :
16-битовый идентификатор контекста, и соединение могут быть выделены в отдельном домене, позволяет использовать различную область перекрытия сетевых адресов. Если нет области значений, область по умолчанию 0 используется. -
Exec ([Action] [... Действие]) :
выполнение операции в ограниченном наборе контекста трассировки соединения. Вexecсписке действий только принять изменения ct_mark или ct_label поле действия. -
= ALG <FTP / TFTP> :
Определяет ALG (шлюз прикладного уровня ALG) для отслеживания конкретного типа соединения. -
NAT :
Определяет гусеничный NAT преобразование адреса и порта.
Пример топологии
Это руководство для выполнения теста с помощью следующей топологии.
+ +
| |
| +-----+ |
| | | |
| | | |
| +----------+ | OVS | +----------+ |
| | left | | | | right | |
| | namespace| | | |namespace | |
+-----+ A +------+ +-----+ B +--------+
| | | A'| | B' | | |
| | | | | | | |
| +----------+ | | +----------+ |
| | | |
| | | |
| | | |
| +-----+ |
| |
| |
+ +
192.168.0.X n/w 10.0.0.X n/w
A = veth_l1
A' = veth_l0
B = veth_r1
B' = veth_r0
Описанные выше шаги, чтобы создать топологию следующим образом.
Создание «левый» Сетевые пространства имен:
$ ip netns add left
Создание «правильного» пространства имен:
$ ip netns add right
Veth создал первую пару интерфейсов:
$ ip link add veth_l0 type veth peer name veth_l1
Добавление veth_l1 к «левым» Сетевым пространствам имен:
$ ip link set veth_l1 netns left
Создайте вторую пару Veth интерфейсов:
$ ip link add veth_r0 type veth peer name veth_r1
Добавление veth_r1 к «правым» сетям имен:
$ ip link set veth_r1 netns right
Создание моста br0:
$ ovs-vsctl add-br br0
Добавление veth_l0 и veth_r0 интерфейсов мост br0 ::
$ ovs-vsctl add-port br0 veth_l0
$ ovs-vsctl add-port br0 veth_r0
В пакете данных «левый» Сетевые пространства имен, генерируемые IP источника / назначения адреса 192.168.0.x / 10.0.0.x пакетной передачи данных, так и в противоположных направлениях «правильных» Сети пространств имен, генерируемых появится в OVS переключатель, если две сети (192.168.0.X и 10.0.0.x) хостов в сообщении.
Это существенно, чтобы имитировать связь между двумя узлами или сетевыми подсетей по центру OVS.
Примечание :
одна пара Veth интерфейсы для обмена данными между двумя сетями пространств имен, в настоящем варианте осуществления только представления.
TCP инструменты генерации пакетов
Scapy может быть использован для создания TCP-пакетов. Мы использовали шаги scapy для этого теста, выполненного на Ubuntu 16.04. (Scapy, установленный внутри, выходит за рамки).
Вы можете держать scapy два активных сессий на каждом пространстве имен:
$ sudo ip netns exec left sudo `which scapy`
$ sudo ip netns exec right sudo `which scapy`
Примечание: Если вы столкнулись следующее сообщение об ошибке:
ifreq = ioctl(s, SIOCGIFADDR,struct.pack("16s16x",LOOPBACK_NAME))
IOError: [Errno 99] Cannot assign requested address
Выполните следующую команду:
$ sudo ip netns exec <namespace> sudo ip link set lo up
Согласование TCP-пакетов
соединение TCP устанавливается
ОВС может быть добавлен в простом два потоке, два потока направляется от «левого» в пространстве имен «правильные» пространство имен, а также от «вправо» к «левому» пакету:
$ ovs-ofctl add-flow br0 \
"table=0, priority=10, in_port=veth_l0, actions=veth_r0"
$ ovs-ofctl add-flow br0 \
"table=0, priority=10, in_port=veth_r0, actions=veth_l0"
В дополнение к добавлению этих двух потоков снаружи, и мы также добавим TCP-пакеты, соответствующие состояния потока.
Мы будем посылать TCP сообщение установления соединения, а именно: Находится в «левой» сети имен хоста 192.168.0.2 син, син-Ack Ack пакетов и 10.0.0.2 и расположен между «правым» пространства имен хоста.
Во-первых, мы добавим поток, чтобы начать «отслеживание» отслеживания OVS в принятом сообщении.
Как это начиналось отслеживание сообщений?
Для того, чтобы начать отслеживать сообщения, сначала необходимо соответствовать действия как «CT» поток. Это действие посылает сообщение для подключения трекера. Для того, чтобы определить , является ли сообщение является «неотслеживаемым» неотслеживаемым поле матча потока пакетов ct_stateдолжны быть установлено в положении «-ТРК», то есть, она не гусеничный пакет. После того , как сообщение посылается на подключенный трекер, поэтому единственное , что мы обнаружили, что соединение отслеживания состояния. (Т.е., представляет ли пакет новое соединение или пакет принадлежит к существующему соединению или искаженных пакетов, и так далее.)
Добавим следующие потоки:
(flow #1)
$ ovs-ofctl add-flow br0 \
"table=0, priority=50, ct_state=-trk, tcp, in_port=veth_l0, actions=ct(table=0)"
Из «левого» пространства имен отправленных пакетов TCP-SYN соответствует поток # 1, когда пакет поступает от veth_l0 ОВС порта, и не была найдена. (Поскольку сообщение только что вошло в OVS. Все пакеты в первый раз в OVS являются «неотслеживаемыми»).
Поскольку конфигурации «CT» операции, поток будет сообщено пакетов подключения трекера. Параметры работы «Ct» «таблица = 0» обработка трубы на две части. Исходное сообщение в качестве примера «неотслеживаемого» сообщения, чтобы продолжить обработку текущего списка действий. (Поскольку не существует никакой операции после того, как исходное сообщение будет отброшено.).
Примеры пакетов, отправленных в другой разъем раздвоенного трекере, а затем повторно вводится в трубопровод продолжает обработку указанной таблицы потока OpenFlow, когда состояние было установлено ct_state Ct значения, и другие поля совпадают. При указанных обстоятельствах, пакеты с соответствующей каратным статусом ct_state и другими областями будут вернуться к списку 0.
Далее, мы добавим поток в соответствии с датаграммой, возвращенной из трассировщика:
(flow #2)
$ ovs-ofctl add-flow br0 \
"table=0, priority=50, ct_state=+trk+new, tcp, in_port=veth_l0, actions=ct(commit),veth_r0"
Так как пакет возвращается от отслеживания соединений, ct_state состояние должно быть установлено до «TRK».
Кроме того, если это первый пакет TCP соединений, состояние ct_state следует создать «новый» флаг. (Это в настоящее время, потому что нет никакой связи между TCP 192.168.0.2 и 10.0.0.2) ctпараметрами «фиксацией» подключат представляет модуль отслеживания соединений. Значение этого является то , что операция информации о соединении хранится в модуле отслеживания соединения, и пакет превышающий срок службы трубы.
Мы используем scapy послать TCP SYN пакетов (находится в «левой» пространство имен scapy сессии) (флаги = 0x02 является син):
$ >>> sendp(Ether()/IP(src="192.168.0.2", dst="10.0.0.2")/TCP(sport=1024, dport=2048, flags=0x02, seq=100), iface="veth_l1")
Это сообщение будет соответствовать потоку # 1 и # 2 потока.
Трассировщика модуль слежения за соединение будет иметь записи в этой связи:
$ ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2"
tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048),reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=SYN_SENT)
Примечание: На этом этапе, если повторная передача пакета TCP SYN, он будет соответствовать снова поток # 1 (так как новое сообщение не всегда отслеживаются), и он также будет соответствовать поток # 2. Причина, по которой совпадает с потоком # 2, несмотря на трассировщик информации об этой связи, но это не в «ESTABLISHED» состояние, таким образом, соответствие «новый» снова.
Далее, TCP SYN + ACK-пакет от направлении, противоположном / сервер, нам нужно следующее OVS поток:
(flow #3)
$ ovs-ofctl add-flow br0 \
"table=0, priority=50, ct_state=-trk, tcp, in_port=veth_r0, actions=ct(table=0)"
(flow #4)
$ ovs-ofctl add-flow br0 \
"table=0, priority=50, ct_state=+trk+est, tcp, in_port=veth_r0, actions=veth_l0"
поток # 3 на сервере согласования (10.0.0.2) назад неотслеживаемой пакет и посылает это сообщение к трассировщику. (Далее, мы можем течь # 1 и поток # 3 слияния процесс, чтобы удалить «in_port» поле матч)
TCP SYN + ACK пакет после трассировщика обработки, ct_state установлен флаг установления соединения «EST».
Примечание: После просмотра трассировщика двухстороннее движение, ct_state установить соединение с «ЭСТ» состояние, но он не видел, что третий пакет ACK клиента, он настроен сбросить счетчик на краткосрочный въезд трассировщика устройство.
Отправить TCP SYN + ACK пакет ( "правильный" пространство имен scapy сеанса) (= 0x12 в качестве флага ACK и SYN) с использованием scapy:
$ >>> sendp(Ether()/IP(src="10.0.0.2", dst="192.168.0.2")/TCP(sport=2048, dport=1024, flags=0x12, seq=200, ack=101), iface="veth_r1")
Это сообщение будет соответствовать потоку # 3 и # 4 потока.
трассировщика записей:
$ ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2"
tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048),reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=ESTABLISHED)
Только после получения пакета SYN и SYN ACK, трассировщик состояние становится «УСТАНОВИЛО». Но на этот раз, если он не получает третий ACK пакет (от клиента), это соединение, скоро будет удалено из трассировщика.
Далее, TCP ACK пакеты от направления клиента, мы можем добавить следующий поток, соответствующий это сообщение:
(flow #5)
$ ovs-ofctl add-flow br0 \
"table=0, priority=50, ct_state=+trk+est, tcp, in_port=veth_l0, actions=veth_r0"
В-третьих передачи TCP ACK-пакет (в "левой" пространство имен scapy сессии) (флаги = 0x10 как ACK) с использованием scapy:
$ >>> sendp(Ether()/IP(src="192.168.0.2", dst="10.0.0.2")/TCP(sport=1024, dport=2048, flags=0x10, seq=101, ack=201), iface="veth_l1")
Это сообщение будет соответствовать потоку # 1 и поток # 5.
трассировщика записей:
$ ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2"
tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048), \
reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024), \
protoinfo=(state=ESTABLISHED)
трассировщика состояние остается в «ESTABLISHED» состоянии, но теперь он получил ACK от клиента, даже если данные не получены в связи с этим, что в течение длительного времени будет оставаться в этом состоянии.
данные TCP
Когда сегмент TCP несет байты полезной нагрузки посланных от 192.168.0.2 к 10.0.0.2, сегменту, несущий пакеты данных будет соответствовать потоку # 1, # 5 потока и после.
Scapy послать байт с использованием сегмента TCP (в «левой» пространство имен scapy сессии) (флаги = 0x10 является Ack) ::
$ >>> sendp(Ether()/IP(src="192.168.0.2", dst="10.0.0.2")/TCP(sport=1024, dport=2048, flags=0x10, seq=101, ack=201)/"X", iface="veth_l1")
Используйте scapy, передаваемые по сегменту ACK ответа (в «правильном» пространство имен scapy сессии) (флаги = 0x10 является Ack) ::
$ >>> sendp(Ether()/IP(src="10.0.0.2", dst="192.168.0.2")/TCP(sport=2048, dport=1024, flags=0X10, seq=201, ack=102), iface="veth_r1")
ACK пакет данных ответа должен соответствовать потоку # 3 и # 4 потока.
TCP соединения на разрыв
Существуют различные способы, чтобы разрушить соединение TCP. Мы посылаем «FIN» пакет от клиента, сервер отвечает сообщение «FIN + ACK», то клиент посылает последний из «АСКА» связи сообщения утилизации.
От клиента к серверу будет соответствовать всем пакетам поток # 1 и # 5 Потока. От сервера к клиенту будет соответствовать все пакеты потока # 3 и # 4 потока. Точка стоит отметить, что даже если соединение TCP быть
демонтированы, все пакеты ( на самом деле срывая соединения) по- прежнему соответствует «+ ЭСТ» состояние. Сообщение, или если она была запись трассировщика является «УСТАНОВИЛ» состояние, он должен продолжать соответствовать ct_state в OVS «+ ЭСТ» знак.
Примечание: На практике, когда состояние соединения трассировщика «TIME_WAIT» состояние (все соединения TCP слезы обмен FIN и ACK-пакет от желаемого), пакет повторной передачи (от 192.168.0.2-> 10.0.0.2) , трафик по-прежнему хит # 1 и # 5.
TCP FIN передача пакетов ( "левая" пространство имен scapy сессия) (флаги = 0x11 для ACK и FIN) использование scapy:
$ >>> sendp(Ether()/IP(src="192.168.0.2", dst="10.0.0.2")/TCP(sport=1024, dport=2048, flags=0x11, seq=102, ack=201), iface="veth_l1")
Это сопоставление пакетов потока # 1 и поток # 5.
трассировщика записей:
$ sudo ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2"
tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048),reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=FIN_WAIT_1)
Отправить TCP FIN + ACK пакет ( "право" пространства имен scapy сеанса) (флаги = 0x11 для ACK и FIN) использования scapy:
$ >>> sendp(Ether()/IP(src="10.0.0.2", dst="192.168.0.2")/TCP(sport=2048, dport=1024, flags=0X11, seq=201, ack=103), iface="veth_r1")
Это сообщение ударил поток # 3 и # 4 потока.
трассировщика записей:
$ sudo ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2"
tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048),reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=LAST_ACK)
Передача TCP ACK пакет ( "левый" пространство имен scapy сеанса) (флаги = 0x10 как ACK) с использованием scapy:
$ >>> sendp(Ether()/IP(src="192.168.0.2", dst="10.0.0.2")/TCP(sport=1024, dport=2048, flags=0x10, seq=103, ack=202), iface="veth_l1")
Это сообщение поток # 1 хиты и поток # 5.
трассировщика записей:
$ sudo ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2"
tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048),reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=TIME_WAIT)
резюме
В следующей таблице приведены взаимосвязи между потоком TCP-пакета и поле соответствия
+-------------------------------------------------------+-------------------+
| TCP Segment |ct_state(flow#) |
+=======================================================+===================+
| **Connection Setup** | |
+-------------------------------------------------------+-------------------+
|192.168.0.2 → 10.0.0.2 [SYN] Seq=0 | -trk(#1) then |
| | +trk+new(#2) |
+-------------------------------------------------------+-------------------+
|10.0.0.2 → 192.168.0.2 [SYN, ACK] Seq=0 Ack=1 | -trk(#3) then |
| | +trk+est(#4) |
+-------------------------------------------------------+-------------------+
|192.168.0.2 → 10.0.0.2 [ACK] Seq=1 Ack=1 | -trk(#1) then |
| | +trk+est(#5) |
+-------------------------------------------------------+-------------------+
| **Data Transfer** | |
+-------------------------------------------------------+-------------------+
|192.168.0.2 → 10.0.0.2 [ACK] Seq=1 Ack=1 | -trk(#1) then |
| | +trk+est(#5) |
+-------------------------------------------------------+-------------------+
|10.0.0.2 → 192.168.0.2 [ACK] Seq=1 Ack=2 | -trk(#3) then |
| | +trk+est(#4) |
+-------------------------------------------------------+-------------------+
| **Connection Teardown** | |
+-------------------------------------------------------+-------------------+
|192.168.0.2 → 10.0.0.2 [FIN, ACK] Seq=2 Ack=1 | -trk(#1) then |
| | +trk+est(#5) |
+-------------------------------------------------------+-------------------+
|10.0.0.2 → 192.168.0.2 [FIN, ACK] Seq=1 Ack=3 | -trk(#3) then |
| | +trk+est(#4) |
+-------------------------------------------------------+-------------------+
|192.168.0.2 → 10.0.0.2 [ACK] Seq=3 Ack=2 | -trk(#1) then |
| | +trk+est(#5) |
+-------------------------------------------------------+-------------------+
Примечание: порядковый номер подтверждения и серийный номер отображаются захват tshark наоборот.
таблица расхода
(flow #1)
$ ovs-ofctl add-flow br0 \
"table=0, priority=50, ct_state=-trk, tcp, in_port=veth_l0, actions=ct(table=0)"
(flow #2)
$ ovs-ofctl add-flow br0 \
"table=0, priority=50, ct_state=+trk+new, tcp, in_port=veth_l0, actions=ct(commit),veth_r0"
(flow #3)
$ ovs-ofctl add-flow br0 \
"table=0, priority=50, ct_state=-trk, tcp, in_port=veth_r0, actions=ct(table=0)"
(flow #4)
$ ovs-ofctl add-flow br0 \
"table=0, priority=50, ct_state=+trk+est, tcp, in_port=veth_r0, actions=veth_l0"
(flow #5)
$ ovs-ofctl add-flow br0 \
"table=0, priority=50, ct_state=+trk+est, tcp, in_port=veth_l0, actions=veth_r0"