Принудительное завершение Ping, когда целевой интерфейс является локальным (Debian)

1249
Dave

Я использую Linux-контейнер на основе Debian под Proxmox 4.4. У этого хоста есть пять сетевых интерфейсов (хотя в проблеме, с которой я столкнулся, участвуют только два).

Пока я захожу на этот хост, я пингую IP-адрес, связанный с eth1. То, что происходит, и то, что, я считаю, должно произойти, - это две совершенно разные вещи.

Я хочу, чтобы пакет ping вышел из eth3, где он будет направлен в eth1.

Происходит следующее: стек IP видит, что я проверяю локальный интерфейс, а затем отправляет ответ обратно в стек. Я знаю, что пакет не выходит и не возвращается по двум причинам:

  1. Захват пакета не показывает ничего, что попадает ни в eth1, ни в eth3.
  2. Задержка пинга составляет в среднем 0,013 мс. Если бы пакет выходил и возвращался, как предполагалось, задержка составляла бы около 60 мс.

Конечно, я желаю соответствующего поведения, когда я пингую IP-адрес, связанный с eth3. В этом случае я хочу, чтобы пакет вышел из eth1, где он будет направлен в eth3. К сожалению, поведение, подобное описанному выше, происходит.

Ниже я показываю статические маршруты, которые я настроил, чтобы попытаться вызвать желаемое поведение. Такие маршруты работают так, как и предполагалось, на компьютере с Windows, но они не работают в соответствии с настройкой Linux, которую я использую.

Как я могу настроить этот хост для пересылки, как предполагалось?

root@my-host:~# uname -a Linux my-host 4.4.35-1-pve #1 SMP Fri Dec 9 11:09:55 CET 2016 x86_64 GNU/Linux root@my-host:~# root@my-host:~# cat /etc/debian_version 8.9 root@my-host:~# root@my-host:~# ifconfig eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:192.0.2.65 Bcast:192.0.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:195028 errors:0 dropped:0 overruns:0 frame:0 TX packets:12891 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:92353608 (88.0 MiB) TX bytes:11164530 (10.6 MiB)  eth1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:128.66.100.10 Bcast:128.66.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:816 errors:0 dropped:0 overruns:0 frame:0 TX packets:486 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:149517 (146.0 KiB) TX bytes:34107 (33.3 KiB)  eth2 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:203.0.113.1 Bcast:203.0.113.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:738 errors:0 dropped:0 overruns:0 frame:0 TX packets:880 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:423603 (413.6 KiB) TX bytes:94555 (92.3 KiB)  eth3 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:128.66.200.10 Bcast:128.66.200.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:611 errors:0 dropped:0 overruns:0 frame:0 TX packets:182 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:43921 (42.8 KiB) TX bytes:13614 (13.2 KiB)  eth4 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:198.51.100.206 Bcast:198.51.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:183427 errors:0 dropped:0 overruns:0 frame:0 TX packets:83 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:85706791 (81.7 MiB) TX bytes:3906 (3.8 KiB)  lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:252 errors:0 dropped:0 overruns:0 frame:0 TX packets:252 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:22869 (22.3 KiB) TX bytes:22869 (22.3 KiB) root@my-host:~# root@my-host:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 128.66.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 203.0.113.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 128.66.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 198.51.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4 root@my-host:~# root@my-host:~# route -v add 128.66.200.10/32 gw 128.66.100.1 root@my-host:~# route -v add 128.66.100.10/32 gw 128.66.200.1 root@my-host:~# root@my-host:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 203.0.113.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 198.51.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4 128.66.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 128.66.100.10 128.66.200.1 255.255.255.255 UGH 0 0 0 eth3 128.66.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 128.66.200.10 128.66.100.1 255.255.255.255 UGH 0 0 0 eth1 root@my-host:~# root@my-host:~# ping -c 3 128.66.100.10 PING 128.66.100.10 (128.66.100.10) 56(84) bytes of data. 64 bytes from 128.66.100.10: icmp_seq=1 ttl=64 time=0.008 ms 64 bytes from 128.66.100.10: icmp_seq=2 ttl=64 time=0.014 ms 64 bytes from 128.66.100.10: icmp_seq=3 ttl=64 time=0.017 ms  --- 128.66.100.10 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.008/0.013/0.017/0.003 ms root@my-host:~#

Четверг, 17.08.2017, 8:12 PDT ОБНОВЛЕНИЕ

По просьбе Диркта я уточняю нашу архитектуру и причину моего вопроса.

Виртуальный хост, который является предметом этого поста (то есть хост с сетевыми интерфейсами eth1, eth3 и тремя другими сетевыми интерфейсами, не связанными с моим вопросом), используется для тестирования физической, проводной сетевой инфраструктуры TCP / IP, которую мы настроили, В частности, мы проверяем функциональность маршрутизации этой сетевой инфраструктуры TCP / IP.

У нас было два виртуальных хоста, а не один, как я описал в своем первоначальном посте. Пинг между этими двумя хостами был бы нашим тестом дыма, чтобы убедиться, что тестируемая сетевая инфраструктура TCP / IP все еще работает.

По слишком подробным причинам, наличие двух хостов затрудняло сбор журналов, которые нам нужны. Итак, мы переключились на один хост, дали ему два сетевых адаптера, настроили статические маршруты так, чтобы все, что предназначалось для сетевого адаптера 2, выходило из сетевого адаптера 1 и наоборот. Проблема в том, что, как я уже сказал, они не выходят.

Эта настройка одного хоста / двух сетевых карт работала под Windows в течение многих лет. Я не знаю, происходит ли это из-за того, что Windows сломана, и мы непреднамеренно воспользовались ошибкой, или если Windows работает нормально (то есть RFC-совместимо), и нам просто нужно настроить конфигурацию на наших виртуальных машинах Linux, чтобы получить то же поведение.

Подведем итоги и вычеркнем длинный блок текста оболочки выше:

Два интерфейса:

eth1: 128.66.100.10/24; the router on this interface's network has IP address 128.66.100.1 eth3: 128.66.200.10/24; the router on this interface's network has IP address 128.66.200.1

Соответствующие маршруты:

Destination Gateway Genmask Flags Metric Ref Use Iface 128.66.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 128.66.100.10 128.66.200.1 255.255.255.255 UGH 0 0 0 eth3 128.66.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 128.66.200.10 128.66.100.1 255.255.255.255 UGH 0 0 0 eth1

Команда, которую я выполняю:

ping -c 3 128.66.100.10

Пункт назначения 128.66.100.10 соответствует двум из указанных выше маршрутов:

Destination Gateway Genmask Flags Metric Ref Use Iface 128.66.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 128.66.100.10 128.66.200.1 255.255.255.255 UGH 0 0 0 eth3

Маршрут с самым длинным совпадением префикса:

Destination Gateway Genmask Flags Metric Ref Use Iface 128.66.100.10 128.66.200.1 255.255.255.255 UGH 0 0 0 eth3

Я пытаюсь понять, почему, учитывая существование этого маршрута, пакет не будет выходить из eth3, проходить через нашу сетевую инфраструктуру TCP / IP, возвращаться и попадать в eth1 извне .

Стек TCP / IP, очевидно, не обращается к таблице пересылки. Как будто, когда он видит, что я пингую локально подключенный интерфейс, стек TCP / IP просто говорит: «О, это локальный интерфейс. Поэтому я не собираюсь обращаться к таблице пересылки. Вместо этого я Я просто отправлю эхо-ответ прямо в стек ".

Является ли поведение, которое я желаю, RFC-совместимым? Если это не так, я должен отказаться от попытки. Но если он совместим с RFC, я хотел бы узнать, как настроить стек TCP / IP в Linux, чтобы разрешить такое поведение.

ПОНЕДЕЛЬНИК, 21.08.2017 ОБНОВЛЕНИЕ

Я обнаружил параметры ядра sysctl rp_filter и accept_local . Я установил их следующим образом:

root@my-host:~# cat /proc/sys/net/ipv4/conf/eth1/accept_local 1 root@my-host:~# cat /proc/sys/net/ipv4/conf/eth3/accept_local 1 root@my-host:~# cat /proc/sys/net/ipv4/conf/all/accept_local 1 root@my-host:~# cat /proc/sys/net/ipv4/conf/default/accept_local 1 root@my-host:~# cat /proc/sys/net/ipv4/conf/eth1/rp_filter 0 root@my-host:~# cat /proc/sys/net/ipv4/conf/eth3/rp_filter 0 root@my-host:~# cat /proc/sys/net/ipv4/conf/all/rp_filter 0 root@my-host:~# cat /proc/sys/net/ipv4/conf/default/rp_filter 0

Установка параметров этого ядра, перезагрузка, проверка того, что они пережили перезагрузку, и повторное тестирование не показали различий в поведении.

Обратите внимание, что my-host - это Linux-контейнер lxc, работающий под Proxmox 4.4. Я также установил rp_filter и accept_local, как показано выше, на интерфейсах гипервизора, которые соответствуют интерфейсам eth1 и eth3 на my-host .

Чтобы подвести итог моей цели, у меня есть хост Linux с двумя сетевыми картами, eth1 и eth3. Я пытаюсь пропинговать eth1, маршрутизировать пакет ping через тестируемую сетевую инфраструктуру TCP / IP и возвращаться к eth3.

Ничто из того, что я пробовал выше, не позволило мне сделать это. Как я могу это сделать?

27.08.2017 ОБНОВЛЕНИЕ

Согласно примечанию dirkt, которое я не упомянул, являются ли eth1 и eth3 чисто виртуальными или соответствуют физическому интерфейсу ... eth1 и eth3 оба соответствуют одному физическому интерфейсу на гипервизоре. Намерение состоит в том, что пакет, который выходит из eth1, фактически физически покидает блок гипервизора, выходит в настоящую сеть TCP / IP и возвращается обратно.

27.08.2017 ОБНОВЛЕНИЕ № 2

По сути, я исследовал сетевые пространства имен, так как это казалось довольно многообещающим. Однако это не «просто работает».

Я использую контейнеры LXC, и кажется, что некоторые механизмы изоляции, присутствующие в контейнерах, мешают мне создать пространство имен сети. Если бы я не работал в контейнере, думаю, у меня не было бы проблем с добавлением сетевого пространства имен.

Я нахожу некоторые ссылки на выполнение этой работы в контейнерах LXC, но они довольно туманны и неясны. Пока нет, и нужно накинуть полотенце на сегодня ... Если у кого-то есть какие-либо предложения на этот счет, пожалуйста, сообщите ...

1
Неправильный сайт. Вы ищете [unix.se] или [su] вместо этого. Этот сайт предназначен для программирования вопросов. Ken White 7 лет назад 0
Да, договорились и извинения. Размещено здесь случайно. Предназначенный суперпользователь. Dave 7 лет назад 0
Ход был запрошен через флаг. Dave 7 лет назад 0
Ваше описание того, что вы хотите, немного сбивает с толку и не соответствует тому, как работает маршрутизация в ядре. Когда пакет выходит из `eth3` и покидает физический интерфейс, он не может быть впоследствии перенаправлен в` eth1`. Маршрутизация * всегда * по назначению. Можете ли вы объяснить * причину *, почему вам нужен ваш пинг для такого поведения? Если вы хотите проверить переадресацию с «eth3» на «eth1», вам нужно пропинговать «eth3» извне, то есть с другого компьютера, подключенного к этому сегменту локальной сети. Или может быть способ имитировать * входящие * пакеты в `eth3`, но не в` ping`. dirkt 7 лет назад 1
Диркт, я расширил свой оригинальный пост, чтобы ответить на ваши вопросы. Dave 7 лет назад 0
Я полагаю, что это может быть проблема RFC 1122 "модель сильного хоста" против "модели слабого хоста". Я изучаю, как настроить Linux для использования модели слабого хоста (если он действительно использует модель сильного хоста). Dave 7 лет назад 0
Модераторы: возможно ли разместить ссылку в группе Stack Exchange "Unix & Linux", чтобы эта тема также появлялась там? На этом форуме могут быть люди, которые могут ответить на этот вопрос. Dave 7 лет назад 0
Вы можете найти свой ответ [здесь] (https://serverfault.com/questions/127636/force-local-ip-traffic-to-an-external-interface). harrymc 7 лет назад 1

2 ответа на вопрос

1
dirkt

(Я оставлю другой ответ из-за комментариев).

Descripton задачи: Учитывая один виртуальный хост в LXC контейнер с двумя сетевыми интерфейсами eth1и eth3, которые находятся на разных сегментами LAN и внешне соединенных через маршрутизаторы, как можно реализовать «бумеранга» пинг, который оставляет на eth3и возвращается на eth1(или тисков Versa)?

Проблема здесь в том, что ядро ​​Linux обнаружит, что адрес назначения назначен eth1, и попытается напрямую доставить пакеты eth1, даже если таблицы маршрутизации предписывают, что пакеты должны маршрутизироваться через eth3.

Невозможно просто удалить IP-адрес eth1, потому что на пинг нужно ответить. Таким образом, единственным решением является каким - то образом использовать два разных адреса (или отдельно eth1и eth3друг от друга).

Одним из способов сделать это является использование iptables, как в этом ответе, связанном с harrymc в комментариях.

Другой способ, который я протестировал на своей машине со следующей настройкой, используя одно пространство имен сети для имитации внешней сети и два пространства имен сети для разделения IP-адресов назначения:

Routing NS Main NS Two NS's  +----------+ +----------+ | veth0b |--- veth0a ....... | ipvl0 | | 10.0.0.1 | 10.0.0.254 | 10.0.0.2 | | | +----------+ | | +----------+ | veth1b |--- veth1a ....... | ipvl1 | | 10.0.1.1 | 10.0.1.254 | 10.0.1.2 | +----------+ +----------+

Routing NSПереадресацией включен. Дополнительные 10.0.*.2адреса назначаются устройству IPVLAN, которое можно рассматривать как дополнительный IP-адрес, назначенный главному интерфейсу, к которому оно подключено. Более подробную информацию о IPVLAN, например, здесь . Создать как

ip link add ipvl0 link veth0a type ipvlan mode l2 ip link set ipvl0 netns nsx

где nsxновое сетевое пространство имен, то в этом пространстве имен,

ip netns exec nsx ip addr add 10.0.0.2/24 dev ipvl0 ip netns exec nsx ip link set ipvl0 up ip netns exec nsx ip route add default via 10.0.0.1 dev ipvl0

Main NSИмеет следующие правила маршрутизации в addtion к правилам по умолчанию

ip route add 10.0.0.2/32 via 10.0.1.1 dev veth1a ip route add 10.0.1.2/32 via 10.0.0.1 dev veth0a

а затем ping 10.0.0.2совершит «бумеранг» туда и обратно, что видно по tcpdumpобоим veth0aи veth1a. Таким образом, с этой настройкой все журналирование может быть выполнено с точки Main NSзрения проверки связи ncи т. Д., Но для более сложных тестов с т.

Контейнер LXC использует сетевые пространства имен (и другие пространства имен). Я не слишком знаком с контейнерами LXC, но если создание новых пространств имен внутри контейнера заблокировано, работайте извне контейнера. Сначала идентифицируйте название контейнера с

ip netns list

а затем сделайте, ip netns exec NAME_OF_LXC_NS ...как указано выше. Вы можете также замедлить перемещение eth1и eth3в контейнер LXC, и сначала создать два IPVLANs, а затем переместить его в контейнер. Сценарий по необходимости.

редактировать

Есть третий вариант, который работает без сетевых пространств имен. Хитрость заключается в том, чтобы использовать политику маршрутизации и дать локальному поиску более высокий («худший») приоритет, чем обычно, и обрабатывать пакеты из сокета, привязанного к определенному интерфейсу, по-разному. Это предотвращает доставку на локальный адрес, который был основным источником проблемы.

С той же настройкой моделирования, что и выше, минус IPVLAN, 

ip rule add pref 1000 lookup local ip rule del pref 0 ip rule add pref 100 oif veth0a lookup 100 ip rule add pref 100 oif veth1a lookup 101 ip route add default dev veth0a via 10.0.0.1 table 100 ip route add default dev veth1a via 10.0.1.1 table 101

команды 

ping 10.0.1.254 -I veth0a ping 10.0.0.254 -I veth1a

правильно отправлять запросы ping. Чтобы также получить ответ ping, необходимо отключить тесты от подмены исходного кода:

echo "0" > /proc/sys/net/ipv4/conf/vetha/rp_filter echo "1" > /proc/sys/net/ipv4/conf/vetha/accept_local

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

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

0
dirkt

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

Host 1 Main Host Host 2 ethX -------- eth1 eth3 --------- ethY 128.66.200.10 128.66.100.10

На главном хосте /proc/sys/net/ipv4/ip_forwardвключен, и вы хотите проверить, работает ли соединение между хостом 1 и хостом 2.

Краткое напоминание о том, как Linux обрабатывает IP-пакеты для каждого интерфейса:

Linux packet processing

Таким образом, входящий пакет из обходов физического PREROUTINGинтерфейса входного интерфейса затем маршрутизируется по назначению, затем проходит POSTROUTINGчерез выходной интерфейс и выходит на физический уровень. Наоборот, приложения, такие как pingотправка пакетов в OUTPUTцепочку, затем они маршрутизируются (не показано на рисунке), затем проходят через POSTROUTINGцепочку и, наконец, выходят.

Здесь я использую вход в смысле «входит в физический уровень», а выход в смысле «покидаю физический уровень».

То, что вы пытаетесь сделать, это как-то сказать ядру Linux не обрабатывать пакеты таким образом, а вместо этого имитировать входящий пакет при eth3использовании приложения ping, которое затем должно быть перенаправлено туда eth1, где оно выходит .

Но это просто не работает : приложения отправляют пакеты по OUTPUTцепочке. Если вы принудительно pingсвязываетесь eth3с этой -Iопцией, Linux просто решит, что это неправильный интерфейс для пакета, и отбросит пакет. Он никогда не будет пытаться лечить этот пакет, как если бы он был ingressing в eth3.

Поэтому нормальный способ справиться с этим - просто отправить пинг с хоста 1 и проверить, поступает ли он на хост 2 (и в другом направлении). Красиво, просто и легко, никаких искажений не требуется.

Поскольку «Основной хост» является виртуальным, eth1и eth3, скорее всего, это не настоящие интерфейсы (вы не сказали). Если они являются лишь одним концом пары ветеринаров, то легко получить другой конец и просто создать его pingна этом конце (где бы это ни было).

Если по каким-то причинам вы настаиваете на тестировании всего на «Главном хосте», вы также можете пройти через некоторые искажения и соединиться eth3с другой ветвью пары интерфейса, а затем pingна другом конце этой ветки пары. Когда пакет соединяется с Veth, это будет рассматриваться как ingressing в eth3, так что делает то, что вы хотите. Но это действительно излишне сложно.

Я не знаю других способов имитации входящих пакетов.

Вы можете попробовать немного iptableмагии, но если вы пытаетесь проверить сетевое соединение, это плохая идея: вы никогда не узнаете, что ваши iptablesправила также работают для реального трафика, потому что это не то, что вы тестируете.

Диркт, спасибо за этот ответ. Я посмотрю на это более внимательно через несколько часов (до конца периода щедрости, конечно). Но пара быстрых комментариев ... У меня * не * есть / proc / sys / net / ipv4 / ip_forward, я не пытаюсь заставить мою виртуальную машину с двумя сетевыми платами действовать как маршрутизатор. Скорее я пытаюсь заставить его вести себя как два хозяина. Dave 7 лет назад 0
Кроме того, я не пытаюсь * симулировать * вход и выход. Если мне удастся заставить это работать так, как я желаю, пинг действительно выйдет из одного из физических интерфейсов гипервизора, перейдет в реальный, физический, проводной TCP Интранет / IP, перенаправьте обратно туда, где он попадет обратно в тот же физический интерфейс гипервизора, и вернитесь обратно в стек гипервизора через виртуальный интерфейс, соответствующий eth3 в моей виртуальной машине. Dave 7 лет назад 0
dirkt, вы правы, я не смог сказать, соответствуют ли eth1 и eth3 физическим интерфейсам. eth1 и eth3 действительно соответствуют физическому интерфейсу на гипервизоре. Тем не менее, они соответствуют * тому же * физическому интерфейсу. У них * нет * каждого из них есть отдельный физический интерфейс. Dave 7 лет назад 0
Может быть, я до сих пор не понимаю ваши настройки. Таким образом, `eth3` и` eth1` связаны друг с другом (как? Через несколько маршрутизаторов? Они не находятся в одном и том же сегменте LAN), и проблема в том, что когда вы делаете `ping 128.66.200.10`, вам нужно ядро ​​Linux игнорировать, что этот адрес уже присутствует в «eth1», и вместо этого направить его через «eth3», где он будет проходить через сеть, и вернуться к «eth1»? Если это правильно, я совершенно не понял ваш вопрос ... dirkt 7 лет назад 0
В этом случае самое простое решение, которое я могу придумать, - это создать дополнительное пространство имен сети (например, «мини-виртуальный хост»), чтобы у вас была такая же ситуация, как и раньше, но теперь вы можете выполнять регистрацию в одном виртуальном хосте. Я не думаю, что маршрут, конфликтующий с адресом интерфейса, можно заставить работать (возможно, с некоторой магией `iptables ', но я должен был бы попробовать это). dirkt 7 лет назад 0
[Ответ] (https://serverfault.com/a/128680/378724), связанный с harrymc, является способом сделать это с помощью `iptables`. Он решает проблему, вводя дополнительные адреса, чтобы не путать маршрутизацию, а затем преобразовывать их в NAT, поэтому внешне они - то, что вам нужно. Я не уверен, какой вариант я бы предпочел, это действительно зависит от того, какие тесты вы проводите, и какие журналы вам нужны. dirkt 7 лет назад 0

Похожие вопросы