LINUX.ORG.RU
Форум — Admin  

Маршрутизация по двум провайдерам и доступ извне


0

1

Добрый день! 

# ifconfig
eth0      Link encap:Ethernet  HWaddr 1a:1a:1a:1a:1a:1a  
          inet addr:192.168.200.10  Bcast:192.168.200.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:28 Base address:0xe000 

eth1      Link encap:Ethernet  HWaddr 1b:1b:1b:1b:1b:1b  
          inet6 addr: fe70::224:d1ff:fe15:bd24/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:365574 errors:0 dropped:0 overruns:0 frame:0
          TX packets:319358 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:305510970 (305.5 MB)  TX bytes:43551826 (43.5 MB)
          Interrupt:21 Base address:0xbc00 

eth1:1    Link encap:Ethernet  HWaddr 1b:1b:1b:1b:1b:1b  
          inet addr:11.22.33.205  Bcast:11.22.33.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:21 Base address:0xbc00 

eth1:2    Link encap:Ethernet  HWaddr 1b:1b:1b:1b:1b:1b  
          inet addr:44.33.22.122  Bcast:44.33.22.127  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:21 Base address:0xbc00 

eth2      Link encap:Ethernet  HWaddr 1c:1c:1c:1c:1c:1c  
          inet addr:192.168.1.241  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe70::224:d1ff:fe10:c40e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:268328 errors:0 dropped:0 overruns:0 frame:0
          TX packets:292235 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:25363710 (25.3 MB)  TX bytes:300222487 (300.2 MB)
          Interrupt:20 Base address:0x2000 

eth2:1    Link encap:Ethernet  HWaddr 1c:1c:1c:1c:1c:1c  
          inet addr:192.168.1.240  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:20 Base address:0x2000 

eth1.10   Link encap:Ethernet  HWaddr 1a:1a:1a:1a:1a:1a  
          inet addr:44.33.22.125  Bcast:44.33.22.127  Mask:255.255.255.248
          inet6 addr: fe70::224:d1ff:fe15:bd24/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:4830 (4.8 KB)

eth1.20   Link encap:Ethernet  HWaddr 1a:1a:1a:1a:1a:1a  
          inet addr:11.22.33.207  Bcast:11.22.33.255  Mask:255.255.255.0
          inet6 addr: fe70::224:d1ff:fe15:bd24/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:6072 (6.0 KB)

lo        Link encap:Локальная петля (Loopback)  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:20300 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20300 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2344755 (2.3 MB)  TX bytes:2344755 (2.3 MB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.16.130.1  P-t-P:172.16.130.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


# ip route show
55.66.77.20 via 11.22.33.205 dev eth1 
172.16.130.2 dev tun0  proto kernel  scope link  src 172.16.130.1 
44.33.22.120/29 dev eth1.10  proto kernel  scope link  src 44.33.22.125 
44.33.22.120/29 dev eth1  proto kernel  scope link  src 44.33.22.122 
172.16.130.0/24 via 172.16.130.2 dev tun0 
11.22.33.0/24 dev eth1.20  proto kernel  scope link  src 11.22.33.207 
11.22.33.0/24 dev eth1  proto kernel  scope link  src 11.22.33.205 
192.168.3.0/24 dev eth1  scope link  src 192.168.1.241 
192.168.1.0/24 dev eth2  proto kernel  scope link  src 192.168.1.241 
192.168.200.0/24 dev eth0  proto kernel  scope link  src 192.168.200.10 
10.0.0.0/8 dev eth2  proto kernel  scope link  src 10.1.1.1 
default via 192.168.1.250 dev eth2

# iptables -tnat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
SQUID_ROUTE  all  --  0.0.0.0/0            0.0.0.0/0           
DNAT       tcp  --  0.0.0.0/0            11.22.33.205      tcp dpt:1230 to:192.168.1.100:22

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  172.16.201.172       0.0.0.0/0           mark match !0x1 to:44.33.22.122 
SNAT       all  --  172.16.130.0/24      0.0.0.0/0           to:192.168.1.240 
SECOND_ROUTE  all  --  192.168.1.0/24       0.0.0.0/0           

Chain SECOND_ROUTE (1 references)
target     prot opt source               destination         
SNAT       all  --  192.168.1.0/24       0.0.0.0/0           mark match !0x1 to:192.168.1.241

Chain SQUID_ROUTE (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            192.168.1.0/24      
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 80,8080 to:192.168.1.240:3128

# iptables -t mangle -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  0.0.0.0/0            192.168.2.0/24      MARK xset 0x1/0xffffffff 
MARK       all  --  0.0.0.0/0            10.10.10.0/24       MARK xset 0x1/0xffffffff 

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  0.0.0.0/0            192.168.2.0/24      MARK xset 0x1/0xffffffff 

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

11.22.33.205 - наш внешний адрес

44.33.22.122 - наш второй внешний адрес

192.168.1.250 - ADSL-роутер внутри локальной сети

В сети имеются web-серверы, доступ к которым осуществляется через адрес 11.22.33.205. Также имеется IPSec-соединение с удалённым адресом 11.22.33.205 <-> 55.66.77.20.

Задача: - Необходимо, чтобы исходящие в интернет пакеты, не относящиеся к IPSec, с клиентов и шлюза 192.168.1.240 ходили через шлюз 192.168.1.250. Соответственно, у всех клиентов сети будет указан 192.168.1.240 в качестве шлюза.

- Должна работать IPSec (как выше сказано, пакеты до удалённого адреса 55.66.77.20 должны уходить только с 11.22.33.205).

- Пакеты внешних соединений, установленных на 11.22.33.205 естественно должны ходить через 11.22.33.205.

Что имеем: в данный момент удалось орагнизовать первые два пункта. Проблема с третьим. В идеале должно быть так: удалённый клиент (пусть будет 88.88.88.88) запрашивает сайт с нашего адреса 11.22.33.205, устанавливается соединение и, в рамках данного содинения, наш шлюз должен отдавать пакеты через етот интерфейс. Если же кто-то из сети или сам шлюз решит установить соединение 88.88.88.88:1234, то такой пакет должен будет уйти через 192.168.1.250

Делал по етой статье: http://gazette.linux.ru.net/rus/articles/lartc/x348.html но столкнулся с той проблемой, что у меня два разномастных канала - один настроен через сетевую с внешним IP, другой - через ADSL-модем, который находится внутри сети.

Возникла мысль, что соединения как-то можно маркировать посредством iptables, но в мануалах написано, что MARK маркирует только одиночные пакеты, да и то внутри шлюза. Советуют играть с TOS. По нему есть два вопроса: будет ли один TOS принадлежать всем пакетам из одного соединения? И как правильно его задавать?

В общем, посоветуйте что-нть по задаче

← Проблема при установке wordpress
kvm bridge networking →

MARK маркирует только одиночные пакеты
одиночные пакеты

А что бывают другие?

По теме: не слушай фанатиков. Ставь fwbuilder и будет тебе щастье.

vahtu
()

И да - что за тема светить IP? Хоть бы х-ми заменил. Насчет ЛОР'а не думаю, что воспользуются. Но ведь жугл не дремлет.

vahtu
()

Погуглил по опции CONNTRACK. Переписал немного iptables: 

# iptables -tmangle -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  0.0.0.0/0            192.168.2.0/24      MARK xset 0x1/0xffffffff 
MARK       all  --  0.0.0.0/0            10.10.10.0/24       MARK xset 0x1/0xffffffff 
CONNMARK   all  --  0.0.0.0/0            11.22.33.205      state NEW CONNMARK xset 0xc/0xffffffff 

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
CONNMARK   all  --  0.0.0.0/0            0.0.0.0/0           CONNMARK restore 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  0.0.0.0/0            192.168.2.0/24      MARK xset 0x1/0xffffffff 
CONNMARK   all  --  0.0.0.0/0            0.0.0.0/0           CONNMARK restore 

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Добавляю 

# ip route add default via 11.22.33.205 table 100
# ip rule add fwmark 0xc table 100

Извне пинги так и не ходят. Но если сделать:

# ip rule add from 88.88.88.88 table 100

то пинги начинают нормально ходить от 88.88.88.88

ЧЯНТД? Как отследить, куда идёт ответный пакет? Пробовал ставить LOG на mangle OUTPUT, но там тишина.

abr_linux ★
() автор топика
Ответ на: комментарий от vahtu

А что бывают другие?

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

И да - что за тема светить IP?

А какой из них я засветил? Все внешние IP отредактировал, оставил только последние значения

abr_linux ★
() автор топика
Ответ на: комментарий от abr_linux

Я не понял, у вас 11.22.33.205 это адрес на Ethernet интерфейсе? Если это так, то что вы пытаетесь сделать командой «ip route add default via 11.22.33.205 table 100»?

Потом, зачем у вас дополнительные ip-адреса прописаны с масками сети (11.22.33.207/255.255.255.0) и (44.33.22.125/255.255.255.248)? В результате ведь только дублирующие маршруты появляются.

Как отследить, куда идёт ответный пакет?

С помощью tcpdump.

Вобще, не понятно, зачем вам fwmark, по идее у вас должно быть:

«ip rule add from 11.22.33.205 table 100»

Вы не дали вывода команды «ip rule», поэтому трудно сказать, что у вас там вобще сейчас с правилами выбора таблицы маршрутизации. Аналогично, вывод команды iptables дан без счётчиков сработки правил, поэтом не понятно, работает ли вобще CONNMARK set/restore.

Да, и команду «ip routе cache flush» вы не забываете делать?

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

По поводу доп. инфы - смогу только через неделю продолжить попытки решения своей задачи.

Если это так, то что вы пытаетесь сделать командой «ip route add default via 11.22.33.205 table 100»?

Хотел, чтобы все пакеты, проходящие через таблицу 100 шли через интерфейс с адресом 11.22.33.205. Аналогично тому, что в данный момент все пакеты default идут по правилу «default via 192.168.1.250 dev eth2»

Потом, зачем у вас дополнительные ip-адреса прописаны с масками сети

Ети настройки появляются автоматически. Скорее всего, они связаны с интерфесайми eth1.10 и eth1.20. Что ето за интерфейсы я не разбирался. Когда-то давно и без меня поднимали тоннель, но куда и зачем пока не знаю. Без них, в принципе, тоже всё работает как надо.

С помощью tcpdump

А подскажите, каким образом можно проследить, как пакет проход по ip route и iptables (помимо -j LOG)? То есть, я хочу полностью отследить, какие действия над пакетом проводит ядро.

«ip rule add from 11.22.33.205 table 100»

То есть, все пакеты извне на интерфейс «11.22.33.205» будут проходить ето правило?

Да, и команду «ip routе cache flush» вы не забываете делать?

Забываю, естественно :) Через неделю продолжу изыскания, учту все Ваши поправки

abr_linux ★
() автор топика
Ответ на: комментарий от abr_linux

С маршрутом по умолчанию у вас всё правильно. На интерфейсе назначен ip-адрес 192.168.1.241, пакеты идут через шлюз 192.168.1.250.

По правилам ip-маршрутизации в маршруте нужно указывать интерфейс и ip-адрес шлюза (сетевого устройства, которому нужно пересылать пакеты). Поэтому 11.22.33.205 в маршрутах быть не должно, какой там адрес должен быть я не знаю, но какой-то другой, допустим 11.22.33.201.

Вроде, нельзя отследить действия ядра над пакетом. Есть правила в iptables (и их счётчики), есть «ip route get». А так, проще запускать ping или ещё что и ловить пакеты tcpdump'ом на разных интерфейсах.

То есть, все пакеты извне на интерфейс «11.22.33.205»

Все приходящие из вне пакеты проходят правило «from all lookup local» и по таблице local маршрутизируются пакеты на адреса, принадлежащие данной машине. А приведённое мною правило как раз для уходящих наружу пакетов.

mky ★★★★★
()
Ответ на: комментарий от mky

Поэтому 11.22.33.205 в маршрутах быть не должно, какой там адрес должен быть я не знаю, но какой-то другой, допустим 11.22.33.201

В данный момент я вернул старые настройки - дефолтный маршрут через сетевую с белым адресом. Вот там какая маршрутизация по умолчанию: 

default via 11.22.33.205 dev eth1  scope link
Как бы, шлюза никакого нет, IP белый. Хотя, можно у провайдера шлюз узнать. Мож тогда получится по статье настроить.

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

Жаль.. Дело в том, что при старых настройках icmp-пакеты извне проходили цепочку mangle prerouting, а ответы на них через mangle output. Когда я сделал настройки такие, как в первом сообщении, ответные пакеты ни в mangle output, ни в mangle forward не наблюдались. Вот почему хотелось узнать, куда ядро их слало.

А приведённое мною правило как раз для уходящих наружу пакетов

Ага. А как потом в таблице 100 мне отправлять пакеты с connmark == 0xc по интерфесу 11.22.33.205, а остальные через шлюз 192.168.1.250?

Я пробовал ip route add fwmark 0xc via 11.22.33.205, только оно не принимается

abr_linux ★
() автор топика
Ответ на: комментарий от abr_linux

Пакеты всегда идут по iptables по одной схеме и входящие всегда проходят через mangle PREROUTING. Если вы его там не удаётся залогировать, то, либо правило логирования не правильное, либо пакета нет (отбросило ядро из-за перегрузки, сработал rp_filter, «потерял» провайдер).

Но входящие пакеты проще/нагляднее смотреть через tcpdump/wireshark.

Я пока не увидел в вашем случае необходимости использовать fwmark для «разруливания» пакетов. У вас задача простая — все пакеты с src-адресом 11.22.33.205 оправить через eth1, остальные пакеты через eth2. Прописали в таблице маршрутизации 100 маршрут по умолчанию через eth1, добавили туда, если нужно, маршруты к локальной сети 192.168.1.0/24. Добавили правило (ip rule) и проверяете с помощью «ping -I 11.22.33.205 ya.ru» и tcpdump, что пакеты уходят через eth1.

mky ★★★★★
()
Ответ на: комментарий от mky

Мне кажется Вы не так поняли задачу или я просто неверно понимаю её решение. Мне необходимо, чтобы абсолютно все уходящие из сети 192.168.1.0/24 пакеты шли через 192.168.1.250 eth2. Исключение составляет два типа пакетов:

- все пакеты на адрес 55.66.77.20 должны идти через 11.22.33.250 eth1 - не проблема, сделал

- все соединения, установленные извне на 11.22.33.205. То есть, если удалённый адрес (например 88.88.88.88) запрашивает 11.22.33.250:80, то ответы от nginx в рамках конкретно етого соединения должны уходить обратно через 11.22.33.250. Но если я захочу обратится по адресу 88.88.88.88:80, то такие пакеты должны ходить через 192.168.1.250. Вот почему я помечаю соединения посредством CONNMARK, а не отдельные пакеты

К слову nginx работает в качестве прокси, сайты внутри сети раскиданы по нескольким компам.

abr_linux ★
() автор топика
Ответ на: комментарий от abr_linux

Но если я захочу обратится по адресу 88.88.88.88:80

Когда просто идёт обращение к указанному адресу, то соединение открывается от адреса в маршруте по умолчанию (192.168.1.241) или можно явно указать в маршруте по умолчанию через опцию «src» от какого адреса идти.

Когда будет соединение извне будет на адрес 11.22.33.205, то ответные пакеты, идущие по этому соединению наружу будут от адреса 11.22.33.205.

Пакеты чётко делятся по src-адресу, поэтому нет необходимости в маркировке в iptables, достаочно «ip rule from 11.22.33.205».

mky ★★★★★
()
Ответ на: комментарий от mky

Картинка проясняется.

Тогда щё один, быть может глупый вопрос. Если я при помощи iptables пробрасываю порт 5432 на внутреннюю машину 192.168.1.100, то как шлюз будет различать ответы клиента 192.168.1.100 на запросы удалённого адреса 88.88.88.88 от соединений того же 192.168.1.100 на 88.88.88.88:5432. Ведь, в обоих случаях src и dst пакетов будут одни и те же и пройдут они одинаковый маршрут по iptables, но в первом случае соединение должно быть через eth1, а во втором - через eth2

abr_linux ★
() автор топика
Ответ на: комментарий от abr_linux

В этом случае (DNAT приходящих на 11.22.33.205) уже будет нужна маркировка пакетов в iptables через CONNMARK.

Но, «ip rule from 11.22.33.205 ...» лучше оставить, чтобы «ping -I 11.22.33.205 ...», «traceroute -s 11.22.33.205 ...» ходили через eth1.

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

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

abr_linux ★
() автор топика
Ответ на: комментарий от abr_linux

Всё зашибись! Действительно надо было просто правило rules прописать и задача решена. Выкладываю полный конфиг:

# iptables -tnat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
SQUID_ROUTE  all  --  0.0.0.0/0            0.0.0.0/0           
DNAT       tcp  --  0.0.0.0/0            11.22.33.205      tcp dpt:1230 to:192.168.1.100:22

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  172.16.201.172       0.0.0.0/0           mark match !0x1 to:44.33.22.122 
SNAT       all  --  172.16.130.0/24      0.0.0.0/0           to:192.168.1.240 
SECOND_ROUTE  all  --  192.168.1.0/24       0.0.0.0/0           

Chain SECOND_ROUTE (1 references)
target     prot opt source               destination         
SNAT       all  --  192.168.1.0/24       0.0.0.0/0           mark match !0x1 to:192.168.1.241

Chain SQUID_ROUTE (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            192.168.1.0/24      
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 80,8080 to:192.168.1.240:3128

# iptables -t mangle -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  0.0.0.0/0            192.168.2.0/24      MARK xset 0x1/0xffffffff 
MARK       all  --  0.0.0.0/0            10.10.10.0/24       MARK xset 0x1/0xffffffff 

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  0.0.0.0/0            192.168.2.0/24      MARK xset 0x1/0xffffffff 

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination


# ip route show
55.66.77.20 via 11.22.33.205 dev eth1 
172.16.130.2 dev tun0  proto kernel  scope link  src 172.16.130.1 
44.33.22.120/29 dev eth1.10  proto kernel  scope link  src 44.33.22.125 
44.33.22.120/29 dev eth1  proto kernel  scope link  src 44.33.22.122 
172.16.130.0/24 via 172.16.130.2 dev tun0 
11.22.33.0/24 dev eth1.20  proto kernel  scope link  src 11.22.33.207 
11.22.33.0/24 dev eth1  proto kernel  scope link  src 11.22.33.205 
192.168.3.0/24 dev eth1  scope link  src 192.168.1.241 
192.168.1.0/24 dev eth2  proto kernel  scope link  src 192.168.1.241 
192.168.200.0/24 dev eth0  proto kernel  scope link  src 192.168.200.10 
10.0.0.0/8 dev eth2  proto kernel  scope link  src 10.1.1.1 
default via 192.168.1.250 dev eth2

# ip rule show
0:	from all lookup local 
32765:	from 11.22.33.205 lookup 100 
32766:	from all lookup main 
32767:	from all lookup default

# ip route show table 100
default via 11.22.33.205 dev eth1
abr_linux ★
() автор топика
Ответ на: комментарий от abr_linux

А хотя нет, проблемка одна так и осталась.

Если извне сделать telnet на 11.22.33.205:1230, то ответа нет.

На шлюзе, судя по -j LOG пакет проходит DNAT, но затем вобще теряется. На eth2 его нет, в MANGLE INPUT/FORWARD тоже не ловится. При старых настройках такие пакеты ловились в цепочке NAT-PREROUTING (DNAT) -> MANGLE-FORWARD.

Заметил такую вещ, если записать NAT/PREROUTING в таком виде: 

LOG        all  --  0.0.0.0/0            11.22.33.205      LOG flags 0 level 4 prefix `NAT PREROUTING (1): ' 
DNAT       tcp  --  0.0.0.0/0            11.22.33.205      tcp dpt:1230 to:192.168.1.100:22
LOG        all  --  0.0.0.0/0            11.22.33.205      LOG flags 0 level 4 prefix `NAT PREROUTING (2): '
то в логе отображается только запись «NAT PREROUTING (1)». Если делать telnet на другой порт, то в логах обе строки. Как узнать, куда может деватся пакет?

abr_linux ★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Проблема при установке wordpress
Admin
kvm bridge networking →