Page 5 of 12 FirstFirst ... 34567 ... LastLast
Results 61 to 75 of 174

Thread: помогите с конфигурацией iptables

  1. #61
    Quote Originally Posted by zap View Post
    А Вы изучали бессмертную страничку: http://www.docum.org/docum.org/kptd/?

    Навскидку не могу пока сказать, но мне кажется что эта задача должна быть вполне выполнима. Вечером приду домой, подумаю. В частности, возможно, каким-то образом можно просто грязно пропатчить поля src IP/dst IP в таблице mangle в цепочках PREROUTING и POSTROUTING соответственно. Гм, не помню точно где, но вроде видел средства для чуть ли не побайтного редактирования служебных полей IP заголовка... или то в tc было...
    С нетерпением жду ваших идей.
    Пока я попробовал поэксперементировать с MARK целью в PREROUTING mange таблицы - не получается .

    Мысль следующая:
    1) Промаркируем интересующие нас пакеты, двигающиеся в обоих направлениях, разными маркерами;
    2) Создадим свои табицы маршрутизации для этих пакетов;
    3) Будем проводить nat (source и destination) обычным способом для промаркированных пакетов

    Должно получится приблизительно следующее:
    Code:
    iptables -t mangle -I PREROUTING -d 2.0.0.0/8 -j MARK --set-mark 4
    iptables -t mangle -I PREROUTING -i vlan1 -s 10.0.0.0/8 -j MARK --set-mark 5
    ip route add table 4 default via 192.168.24.1
    ip route add table 4 nat 2.0.0.0/8 via 10.0.0.0
    ip rule add fwmark 4 table 4
    ip rule add fwmark 5 nat 2.0.0.0 from 10.0.0.0/8
    ip route flush cache
    Тут 192.168.30.54 - адрес на WAN порту (NAT-ится в локальный сегмент 10.0.17.64/28), 192.168.24.1 гейтвей в городскую локалку, 10.0.0.0/8 имеющиеся в городской локалке адреса. Default gateway в основной таблице сделан к совсем другому провайдеру, там необходимых нам станций (из диапазона 10.0.0.0/8) нет.

    Результат не утешительный (пакеты идут только до рутера):
    Code:
    Tracing route to 2.4.43.75 over a maximum of 30 hops
    
      1    <1 ms    <1 ms    <1 ms  10.0.17.66
      2     *        *        *     Request timed out.
      3     *        *        *     Request timed out.
      4     *        *        *     Request timed out.
    10.0.17.66 - рутер

    Есть предположения что не нужно смешивать iproute2 и iptables... Может у кого нибудь есть мысли что я сделал не так? Или есть какой нибудь инструмент, что позволит более детально рассмотреть сей процесс?
    Last edited by AYuusuke; 14-12-2007 at 22:47.

  2. #62
    Code:
    ip route add table 4 nat 2.0.0.0/8 via 10.0.0.0
    Я не совсем понял, что Вы хотели сказать этим правилом. Что, адрес 10.0.0.0 это адрес Вашего роутера? По сути то, чего Вы добились этим правилом - на все Ваши пинги на любой IP из диапазона 2.0.0.0/8 будет выставляться адрес источника 10.0.0.0. Это наверняка не то, что Вы хотели. Эти пакеты надо NATить на выделенный Вам адрес из подсети 10.0.0.0/8, я так понял что это 10.2.2.6 (10.0.17.66?).

    Вообще не вижу смысла мешать iptables и iproute. nat от iproute имеет достаточно ограниченное применение, iptables позволяет сделать всё то же самое, кроме роутинга - да и то, в ядре 2.6 iptables может вмешиваться даже в решения роутера пакетов. Даже место в цепочке, где выполняется nat у роутера и iptables практически совпадают, так что даже с этим особо не поиграешь.

    Далее, для отладки tracert не годится нифига, это всё равно что пытаться понять, почему не работает телевизор, бросая в него теннисные шарики. Для этого удобно использовать tcpdump, он как раз есть в прошивке роутера:

    Code:
    tcpdump -n -i vlan1
    покажет все пакеты, которые входят и выходят с WAN интерфейса, -i vlan0 покажет пакеты, которые тусуются на LAN интерфейсе и так далее. Командная строка у tcpdump очень гибкая, изучайте его man если что. Хождение пакетов обычно проверяю пингом.

    Теперь о самой сути. Давайте попробуем составить план Пу... эээ работ , а то, как мне кажется, Вы просто слепо перебираете все фичи, о которых нашли информацию, особо не вдумываясь в их смысл :-)

    1. Первым делом понятно, что для доступа в любую сеть Вам необходим обычный SNAT. Адреса из Вашей внутренней сети (192.168.1.* ?) надо будет "замаскировать" либо как 10.1.1.5, либо как 10.2.2.6 в зависимости от того, в какую сеть уходит пакет. SNAT выполняется в самом-самом конце, перед отправкой пакета в сеть (и соответственно, ответные пакеты окучиваются сразу по приходе пакета из сети). Про NAT на диапазон адресов забудьте напрочь, это фича совсем для других случаев.

    iptables -t nat -I POSTROUTING -o vlan1 -j SNAT --to-source 10.1.1.5
    iptables -t nat -I POSTROUTING -o vlan2 -j SNAT --to-source 10.2.2.6

    2. Далее, понятноm что для того, чтобы наш пакет для левой подсети "всосался" в нужный нам интерфейс (в дальнейшем я буду исходить из того, что это vlan2) необходимо указать, что у этого интерфейса есть доступ к нашей 'обманной' сетке:

    Code:
    ip r a 2.0.0.0/8 dev vlan2
    Теперь все пакеты для этой подсети уйдут в правильную сетевую карту, и мы имеем шансы 'перехватить' их перед самым выходом.

    3. Для изменения адресов с 2.0.0.0/8 в 10.0.0.0/8 и обратно DNAT опять же не годится совсем. Во-первых --to-destination понимает только диапазон адресов (10.0.0.0-10.255.255.255), во-вторых он подменяет адреса абсолютно незакономерно, то есть 2.2.2.2 может оказаться заменённым на 10.5.9.7 и это будет абсолютно правильной работой модуля.

    4. К сожалению, я просмотрел какие есть возможности у таблицы mangle, и в своём 'стандартном' состоянии она мало на что способна - можно менять TTL, TOS и маркировать пакеты и это всё. Таким образом, единственный доступный способ сделать то, что нам надо - цель NETMAP. К счастью, она у нас имеется, пусть и в каком-то непонятно-модифицированном виде.

    По идее, должно быть что-то вроде:

    Code:
    iptables -t nat -I PREROUTING -s 10.0.0.0/8 -i vlan2 -j NETMAP --to 2.0.0.0/8
    iptables -t nat -I POSTROUTING -d 2.0.0.0/8 -o vlan2 -j NETMAP --to 10.0.0.0/8
    Не забудьте загрузить модуль ipt_NETMAP.o, он (у меня?) почему-то не подгружается автоматически командой iptables:

    Code:
    insmod /lib/modules/2.4.20/kernel/net/ipv4/netfilter/ipt_NETMAP.o
    После этого вышеуказанные правила загрузились без проблем, но вот попытка посмотреть каков результат меня несколько озадачило:

    Code:
    [zap@gate|/lib/modules/2.4.20/kernel/net/ipv4/netfilter]tcpdump -n -i vlan1 icmp
    listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
    03:26:46.769396 IP 10.0.0.0 > 2.1.2.3: icmp 64: echo request seq 5
    03:26:47.769206 IP 10.0.0.0 > 2.1.2.3: icmp 64: echo request seq 6
    03:26:48.769035 IP 10.0.0.0 > 2.1.2.3: icmp 64: echo request seq 7
    03:26:49.768860 IP 10.0.0.0 > 2.1.2.3: icmp 64: echo request seq 8
    То есть по какой-то причине модуль NETMAP в лоб заменило source IP на параметр --to (причём даже без учёта маски!). В общем, надо разбираться с исходниками NETMAP, это единственный реальный вариант, который я вижу. Завтра скачаю, поковыряюсь а сегодня уже поздно

  3. #63
    zap, cпасибо за ответ!

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

    Есть подключение к 2-м провайдерам:
    - провайдер A выдал 2 блока адресов (10.0.17.64/28 и 89.223.97.248/29), со шлюзами 10.0.17.65 и 89.223.97.249 соответственно, для доступа в интетернет;
    - провайдер B дал один IP (192.168.30.54) со шлюзом 192.168.24.1 для доступа в свою локалку (192.168.0.0/16, 10.0.0.0/8 и еще несколько подсетей) (интернет там тоже есть, но я его не использую)
    (89.223.97.248/29 рассматривать отдель не имеет смысла)

    Кабель A подключен в WAN порт рутера (настройки на static ip), кабель B в LAN порт.
    Результат приблизительно следующий:
    Code:
    [admin@anthy root]$ ip route
    192.168.24.1 dev vlan1  scope link
    89.223.97.248/29 dev br0  proto kernel  scope link  src 89.223.97.254
    10.0.17.64/28 dev br0  proto kernel  scope link  src 10.0.17.66
    192.168.24.0/21 dev vlan1  proto kernel  scope link  src 192.168.30.54
    85.249.160.0/20 via 192.168.24.1 dev vlan1  metric 2
    192.168.0.0/16 via 192.168.24.1 dev vlan1  metric 2
    1.0.0.0/8 via 192.168.24.1 dev vlan1  metric 2
    10.0.0.0/8 via 192.168.24.1 dev vlan1  metric 2
    127.0.0.0/8 dev lo  scope link
    default via 89.223.97.249 dev br0
    Локальный сегмент 10.0.17.64/28, DHCP моего рутера раздает адреса в этом диапазоне.

    Так я хожу в интернет:
    Code:
    Трассировка маршрута к ya.ru [213.180.204.8]
    с максимальным числом прыжков 30:
    
      1     1 ms     1 ms     1 ms  10.0.17.66
      2     1 ms     1 ms     1 ms  10.0.17.65
      3     4 ms     4 ms     4 ms  81.222.220.97
      4     4 ms     5 ms     6 ms  10.54.0.1
      5     5 ms     6 ms     5 ms  194.226.196.1
      6     5 ms     6 ms     7 ms  217.170.94.241
      7     5 ms     6 ms     8 ms  81.222.2.1
      8    14 ms    14 ms    13 ms  81.222.15.1
      9    14 ms    15 ms    14 ms  81.222.7.162
     10    19 ms    15 ms    13 ms  87.250.233.99
     11    15 ms    15 ms    17 ms  213.180.201.222
     12    16 ms    16 ms    14 ms  213.180.204.8
    
    Трассировка завершена.
    , а так - в локалку
    Code:
    Трассировка маршрута к 10.4.43.75 с максимальным числом прыжков 30
    
      1     1 ms     1 ms     1 ms  10.0.17.66
      2     2 ms     2 ms     2 ms  192.168.24.1
      3     2 ms     2 ms     2 ms  10.250.0.2
      4     *      740 ms     *     10.250.2.1
      5     2 ms     2 ms     1 ms  10.4.43.75
    
    Трассировка завершена.
    Есть возможность подключить еще одну локалку (там тоже дадут только 1 IP), где тоже будет диапазон 10.0.0.0/8.
    Пока подключения нет, я экспериментирую следующим образом:
    Code:
    ip route delete 10.0.0.0/8
    все пакеты на 10.0.0.0/8 начинают идти в инет
    Code:
    Трассировка маршрута к 10.4.43.75 с максимальным числом прыжков 30
    
      1     2 ms     1 ms     1 ms  10.0.17.66
      2     2 ms     2 ms     1 ms  10.0.17.65
      3    11 ms   112 ms     5 ms  81.222.220.97
      4     *     ^C
    Назовем данную конфигурацию базовой. Задача - сделать так, что бы:
    - пакеты идущие из локального сегмента на 2.0.0.0/8 уходили в vlan1 с соответствующей перекодировкой
    - у пакетом идущих с vlan1 пере кодируется source поле 10.0.0.0/8 в 2.0.0.0/8 (destination пере кодируется обычным MASQUERADE/DNAT в зависимости от направления в котором установлено соединение)

    ------------------------------------------------------------

    Теперь отвечаю на ваше сообщение:

    ip route add table 4 nat 2.0.0.0/8 via 10.0.0.0 должно перекодировать поле destination из 2.0.0.0/8 в 10.0.0.0/8 для всех пакетов,
    промаркированных 4-кой (http://linux-ip.net/html/nat-stateless.html example 5.2)

    Я бы тоже не хотел смешивать iproute2 и iptables, нужного мне преобразования я не смог добиться с помошью iptables...

    Про tcpdump спасибо, буду пользоваться.

    Насчет "1." конечно же вы правы, у меня оно так и делается. Тут вопросов особых нет.

    "2." - этого я попытался добиться отдельной таблицей маршрутизации (table 4) для помеченных пакетов. Попробую и ваш вариант.

    "3." - тут я руководствовался статьей http://lists.netfilter.org/pipermail...ch/008924.html и мне показалось что если размер подсетей
    совпадает, должно быть прямое преобразование. Я был не прав? Конечно если размеры диапазонов разные - будет чехарда как вы и написали (в чем я пару раз убеждался).

    "4." - определенную попытку использования NETMAP я делал (пару сообщений ниже), но результата я не добился. Так же Олег говорил о том что асусовцы подправили эту цель...
    Как мне кажется моя конструкция из "ip route add nat" и "ip rule add nat" должны быть тождественно равна вашему iptables NETMAP. Это не так?

    Жду ответа.

    Теперь статистика с помошью tcpdump моего варианта с ip route nat (на базовую конфигурацию накатываю настройки их прошлого поста):
    Code:
    Трассировка маршрута к 2.4.43.75 с максимальным числом прыжков 30
    
      1     1 ms     1 ms    <1 мс  10.0.17.66
      2     *        *        *     Превышен интервал ожидания для запроса.
      3     *        *     ^C
    (должно быть как в начале поста)
    Code:
    [admin@anthy root]$ tcpdump -n -i vlan1 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
    16:14:40.167239 IP 192.168.30.54 > 10.4.43.75: ICMP echo request, id 1, seq 488, length 72
    16:14:40.169695 IP 192.168.24.1 > 192.168.30.54: ICMP time exceeded in-transit, length 36
    16:14:43.897703 IP 192.168.30.54 > 10.4.43.75: ICMP echo request, id 1, seq 489, length 72
    16:14:43.898984 IP 192.168.24.1 > 192.168.30.54: ICMP time exceeded in-transit, length 36
    16:14:47.896878 IP 192.168.30.54 > 10.4.43.75: ICMP echo request, id 1, seq 490, length 72
    16:14:47.897902 IP 192.168.24.1 > 192.168.30.54: ICMP time exceeded in-transit, length 36
    16:14:51.896701 IP 192.168.30.54 > 10.4.43.75: ICMP echo request, id 1, seq 491, length 72
    16:14:51.897705 IP 10.250.0.2 > 192.168.30.54: ICMP time exceeded in-transit, length 36
    16:14:55.932562 IP 192.168.30.54 > 10.4.43.75: ICMP echo request, id 1, seq 492, length 72
    16:14:55.933766 IP 10.250.0.2 > 192.168.30.54: ICMP time exceeded in-transit, length 36
    16:14:59.900137 IP 192.168.30.54 > 10.4.43.75: ICMP echo request, id 1, seq 493, length 72
    16:14:59.902178 IP 10.250.0.2 > 192.168.30.54: ICMP time exceeded in-transit, length 36
    
    12 packets captured
    12 packets received by filter
    0 packets dropped by kernel
    Интересный результат, не так ли? По крайней мере 2.0.0.0/8->10.0.0.0/8 преобразование происходит правильно (одновременно и source поле ставится как надо), пакеты уходят на нужный интерфейс, но вот ответы где то застревают...
    Есть какие нибудь мысли?
    Last edited by AYuusuke; 15-12-2007 at 15:39.

  4. #64
    Quote Originally Posted by AYuusuke View Post
    Видимо я плохо сформулоровать свою проблему и плохо рассказал о попытках. В ообщих чертах вы правильно поняли, что мне нужно, но вот с конкретными адресами/масками не все хорошо.
    Я сначала хотел попросить разьяснений, но потом подумал что незачем тратить время впустую, лучше просто попытаюсь догадаться

    Quote Originally Posted by AYuusuke View Post
    Есть подключение к 2-м провайдерам:
    - провайдер A выдал 2 блока адресов (10.0.17.64/28 и 89.223.97.248/29)
    Гм, провайдер выделил Вам аж 16 серых и 8 реальных адресов? Весьма нетипично

    Quote Originally Posted by AYuusuke View Post
    Кабель A подключен в WAN порт рутера (настройки на static ip), кабель B в LAN порт.
    Может имеет смысл переразбить порты на роутере? То есть, сделать порт WAN1, WAN2 и оставшиеся три порта обьединить в LAN? Или, с учётом ещё одного потенциального провайдера, разбить имеющиеся 5 портов на WAN1, WAN2, WAN3 и два порта оставить на LAN? Таким образом Вы получите свою приватную подсеть, где не будут бегать левые броадкасты от провайдера и где не надо защищаться файрволом, плюс Вам не понадобится целый блок адресов от первого провайдера, будет достаточно 1 выделенного адреса от каждого провайдера?

    Quote Originally Posted by AYuusuke View Post
    Code:
    85.249.160.0/20 via 192.168.24.1 dev vlan1  metric 2
    Обана... вижу знакомые цифры между прочим, мой адрес 85.249.169.28

    Quote Originally Posted by AYuusuke View Post
    Локальный сегмент 10.0.17.64/28, DHCP моего рутера раздает адреса в этом диапазоне.
    Если отделиться от WAN'ов высокой огненной стеной, то можно сделать себе спокойно внутри квартиры какой-нибудь 172.16.8.0/24 и не париться с публично видимыми диапазонами. Кстати, а что происходит когда какой-нибудь товарищ из локалки делает запрос DHCP, ему Ваш сервак выделит адрес в Вашем приватном диапазоне?

    Quote Originally Posted by AYuusuke View Post
    ip route add table 4 nat 2.0.0.0/8 via 10.0.0.0 должно перекодировать поле destination из 2.0.0.0/8 в 10.0.0.0/8 для всех пакетов,
    промаркированных 4-кой (http://linux-ip.net/html/nat-stateless.html example 5.2)
    Я не уверен. Пример задан для всего лишь одного айпишнега, то есть IF DST=205.254.211.17 THEN REPLACE DST=192.168.100.17. Про работу с целым диапазоном там нет ни слова.

    Кстати спасибо за ссылку, я там прочитал ключевое слово STATELESS. Оказывается NAT у iproute не отслеживает состояние соединения, то есть он просто заменяет поле адреса и всё - этим он кардинально отличается от NAT'а iptables (но зато это же роднит его с NETMAP'ом, собственно NAT iproute == NETMAP iptables . Так что если не выйдет с NETMAP'ом, может получится с iproute

    Quote Originally Posted by AYuusuke View Post
    "3." - тут я руководствовался статьей http://lists.netfilter.org/pipermail...ch/008924.html и мне показалось что если размер подсетей
    совпадает, должно быть прямое преобразование. Я был не прав? Конечно если размеры диапазонов разные - будет чехарда как вы и написали (в чем я пару раз убеждался).
    Я не знаю, что курил этот Mark A. Howard в момент написания, но лично у меня такой синтаксис не прокатывает, и в мануале iptables такой синтаксис вообще не описан.

    На роутере:
    Code:
    [zap@gate|/tmp/local/root]iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o vlan0 -j SNAT --to-source 5.6.7.0/24
    iptables v1.2.7a: Bad IP address `5.6.7.0/24'
    На компьютере (ядро 2.6.23):

    Code:
    [1|root@zap|~]iptables -t nat -A POSTROUTING -s 192.168.211.0/24 -o eth0 -j SNAT --to-source 5.6.7.0/24
    iptables v1.3.8: Bad IP address `5.6.7.0/24'
    В мануале написано, что формат параметра - "--to-source <ipaddr>-<ipaddr>".

    Возможно, учитывая что письмо написано в 2001м году, что информация относится к какой-то лысой версии ядра. В любом случае, современный SNAT не годится, так как и SNAT и DNAT делают STATEFUL NAT, а нам нужен STATELESS NAT.

    Quote Originally Posted by AYuusuke View Post
    "4." - определенную попытку использования NETMAP я делал (пару сообщений ниже), но результата я не добился. Так же Олег говорил о том что асусовцы подправили эту цель...
    К сожалению, я сегодня весь день пытался скачать исходники с сайта асуса, но сайт так и не заработал, поэтому с исследованием исходников придётся подождать пока.

    Quote Originally Posted by AYuusuke View Post
    Как мне кажется моя конструкция из "ip route add nat" и "ip rule add nat" должны быть тождественно равна вашему iptables NETMAP. Это не так?
    Как я писал выше, iproute nat оказался братом-близнецом NETMAP, только вроде бы работает правильно :-)

    Quote Originally Posted by AYuusuke View Post
    Code:
    16:14:40.167239 IP 192.168.30.54 > 10.4.43.75: ICMP echo request, id 1, seq 488, length 72
    О как! Таки iproute nat заменяет всё как надо, это здорово.

    Quote Originally Posted by AYuusuke View Post
    Code:
    16:14:40.169695 IP 192.168.24.1 > 192.168.30.54: ICMP time exceeded in-transit, length 36
    Хм, а это случайно не оттого что TTL слишком маленький? Попробуйте задать tcpdump опцию -v, он должен распечатать TTL пакета. Возможно, по какой-то причине TTL уменьшается до нуля раньше времени. Сравните с TTL пакетов, которые доходят до цели как надо.

  5. #65
    (Только что заметил описку, кабель B подключен в LAN порт, кабель A - в WAN)

    Насчет 16-ти серых и 8 реальных адресов думаю я лучше оставлю как есть. Данная схемы еще с тех времен когда у меня стоял тупой свич. DHCP работает, т.к. мне выделили отдельный vlan на оборудовании провайдера, и другие пользователи в мой сегмент только с помошью l3 маршрутизации ходят, соответственно и лишних broadcast-ов нет. Зато 5 реальников и никакой головной боли из за зависшего рутера (у меня асус периодически виснет из за моих экспериментов). Когду буду подключать следующего провайдера (дада, я хочу в Корбину! ) конечно сделаю на асусе еще один WAN порт.

    Давно вы в Озерках?

    С диапазоном ip route/rule nat точно работает, причем синтаксис я написал правильно, если нужно попробую найти соответствующий tutorial...

    По поводу SNAT/DNAT - http://www.netfilter.org/documentati...O-6.html#ss6.2 раздел Multiple Mappings, Overlap and Clashes - там в поле --to используется подсеть. Тут вроде документ не такой старый.... Хотя я с вами абсолютно согласен, что в нашем iptables такое не пройдет.

    Про Stateful и Stateless я пока плохо понимаю (ну кроме факта что в одном случае запоминается и сопровождается каждое соединение, а в другом - обработка отдельных пакетов без какой либо памяти). Нам кончено же должно хватить stateless, но почему помешает stateful я не понял. Поясните?

    GPL исходники от асуса есть на files.wl500g.info (видимо нас интересует http://files.wl500g.info/asus/wl500g/gpl/GPL_1927.zip)

    TTL там нормальный, я выполнял tracert, а не пинг. По логу прямо видено что сначала идет 3 ответа от первого хопа, потом 3 ответа от второго. Дальше я нажал ctrl-c. Тут вроде никаких проблем.

    Заметил следующую вешь: если не удалять маршрут 10.0.0.0/8 и сначала сделать "tracert 10.4.43.75", а потом почти сразу "tracert 2.4.43.75", то ответы приходят, но с не поменяным source (с штатным, начинающимся с 10). Если подождать некоторое время и опять сделать "tracert 2.4.43.75", то ответа опять не будет (тут под "ответом" я понимаю доходящие ответы от 2-го, 3-го и т.п. хопа, 1-й хоп - рутер, он всегда отвечает).

    Соответственно у меня возникло подозрение, что мои правила ip route/rule nat каким то образом мешают штатному stateful NAT из iptables... При трассировке адреса "2.4.43.75" в таблице conntrack появляется строчка
    Code:
    icmp     1 23 src=10.0.17.76 dst=2.4.43.75 type=8 code=0 id=1 src=2.4.43.75 dst=192.168.30.54 type=0 code=0 id=1 use=1 mark=0
    , при трассировке на "10.4.43.75" - строчка
    Code:
    icmp     1 29 src=10.0.17.76 dst=10.4.43.75 type=8 code=0 id=1 src=10.4.43.75 dst=192.168.30.54 type=0 code=0 id=1 use=1 mark=0
    Получается что сопровождение соединений происходит до нашего преобразования, что вообщем то правильно. Но почему обратные пакеты не пролезают?

    (если я опять не понятно рассказал про мой эксперимент с одновременной трассировкой адресов 2.4.43.75 и 10.4.43.75 - говорите, я распишу подробнее и с картинками)

  6. #66
    Quote Originally Posted by AYuusuke View Post
    (Только что заметил описку, кабель B подключен в LAN порт, кабель A - в WAN)
    Хм, по-моему Вы опять описались =) Наверное всё-таки кабель A в LAN, кабель B - в WAN?

    Quote Originally Posted by AYuusuke View Post
    Насчет 16-ти серых и 8 реальных адресов думаю я лучше оставлю как есть.
    Жадность, конечно, не порок ;-)

    Quote Originally Posted by AYuusuke View Post
    экспериментов). Когду буду подключать следующего провайдера (дада, я хочу в Корбину! ) конечно сделаю на асусе еще один WAN порт.
    Так можно уже сейчас отцепить один из LAN портов, и сделать WAN2. Эксперименты лучше проводить в условиях, максимально приближенных к боевым

    Quote Originally Posted by AYuusuke View Post
    Давно вы в Озерках?
    С 2003го года.

    Quote Originally Posted by AYuusuke View Post
    С диапазоном ip route/rule nat точно работает, причем синтаксис я написал правильно, если нужно попробую найти соответствующий tutorial...
    Ну, вообще говоря, это логично, учитывая тот факт что iproute это скорее инструмент для управления массовыми скоплениями компьютеров а не для управления по одному

    Quote Originally Posted by AYuusuke View Post
    По поводу SNAT/DNAT - http://www.netfilter.org/documentati...O-6.html#ss6.2 раздел Multiple Mappings, Overlap and Clashes - там в поле --to используется подсеть. Тут вроде документ не такой старый.... Хотя я с вами абсолютно согласен, что в нашем iptables такое не пройдет.
    Обратная сторона того, что для Линукса очень много технической документации и информации в сети - то, что в сети полно устаревшей документации. У нас на форуме регулярно всплывает какой-нибудь пользователь, который пытается настроить VPN по туториалам десятилетней давности и тому подобное. Правда, это скорее касается того письма 2001го года :-)

    Что же до раздела "Multiple Mappings, Overlap and Clashes", то как раз там написано обратное - что "NAT code is clever enough", чтобы подменять айпишнеги и порты на что попало :-) А пример с -j SNAT --to 1.2.3.0/24 вообще некорректен, я удивляюсь откуда эта ошибка кочует из мануала в мануал... ведь на роутере ядро времён царя Гороха, и то оно такой синтаксис не понимает.

    Quote Originally Posted by AYuusuke View Post
    Про Stateful и Stateless я пока плохо понимаю (ну кроме факта что в одном случае запоминается и сопровождается каждое соединение, а в другом - обработка отдельных пакетов без какой либо памяти). Нам кончено же должно хватить stateless, но почему помешает stateful я не понял. Поясните?
    Вы правильно понимаете, просто надо сделать ещё один шаг и понять, зачем он запоминает каждое соединение. А запоминание делается потому, что адреса и/или порты могут заменяться, то есть не существует способа определить пару SRC IP/PORT <-> DST IP/PORT без линейного запоминания всех установленных соединений. Соответственно, сам факт, что NAT есть STATEFUL уже говорит нам о том, что маппинг не 1:1.

    Ну и плюс к тому, каждое соединение жрёт ресурсы. Возможно, для маленькой домашней сети это не так страшно (хотя ресурсов у роутера не так уж много), а вот для шлюза типа нашего озерковского (между прочим, у нас как раз имеется доступ в две другие городские локалки по адресам 1.x.x.x и 2.x.x.x, хотя у них в локалках используется адресация 10.x.x.x) это ужосна.

    Quote Originally Posted by AYuusuke View Post
    GPL исходники от асуса есть на files.wl500g.info (видимо нас интересует http://files.wl500g.info/asus/wl500g/gpl/GPL_1927.zip)
    Здорово, уже качаю. На oleg.wl500g.info приведена устаревшая информация о том, что нужны исходники GPL_1817.zip, я безуспешно пытался их найти на сайте асуса :-)

    Quote Originally Posted by AYuusuke View Post
    TTL там нормальный, я выполнял tracert, а не пинг. По логу прямо видено что сначала идет 3 ответа от первого хопа, потом 3 ответа от второго. Дальше я нажал ctrl-c. Тут вроде никаких проблем.
    О как интересно, оказывается:

    Quote Originally Posted by Wikipedia
    The Time Exceeded Message is an ICMP message which is generated by a gateway to inform the source of a discarded datagram due to the time to live field reaching zero. [...]

    Time exceeded messages are used by the traceroute utility to identify gateways on the path between two hosts.
    То есть time exceeded это штатная "фишка" traceroute, он намеренно выставляет низкий TTL, чтобы выявлять шлюзы. Зря Вы всё-таки не присмотрелись к выхлопу tcpdump -v. Вот пример моего traceroute до одного из шлюзов провайдера:

    Code:
    [2|root@zap|~]traceroute -z 1 -I 192.168.240.1
    traceroute to 192.168.240.1 (192.168.240.1), 30 hops max, 40 byte packets
     1  gate.home.lan (192.168.1.1)  0.464 ms  0.433 ms  0.431 ms
     2  vlan16-DGS5.ozerki.net (85.249.169.1)  22.548 ms  19.714 ms  9.128 ms
     3  DGS1.ozerki.lan (192.168.240.1)  16.148 ms  21.245 ms  21.045 ms
    При этом на шлюзе всё очень сходно с Вашей ситуацией:

    Code:
    [zap@gate|/tmp/local/root]tcpdump -vn -i vlan1 icmp            
    tcpdump: listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
    14:23:49.493446 IP (tos 0x0, ttl   5, id 64239, offset 0, flags [none], length: 68) 85.249.169.28 > 194.87.0.50: icmp 48: echo request seq 18
    14:23:49.504422 IP (tos 0x0, ttl 251, id 37013, offset 0, flags [none], length: 56) 85.249.160.1 > 192.168.1.2: icmp 36: time exceeded in-transit
    14:23:53.193230 IP (tos 0x0, ttl   1, id 64243, offset 0, flags [none], length: 68) 85.249.169.28 > 194.87.0.50: icmp 48: echo request seq 4
    14:23:53.210666 IP (tos 0x0, ttl  30, id 0, offset 0, flags [none], length: 56) 85.249.169.1 > 192.168.1.2: icmp 36: time exceeded in-transit
    14:24:07.948034 IP (tos 0x0, ttl   1, id 63648, offset 0, flags [none], length: 68) 85.249.169.28 > 192.168.240.1: icmp 48: echo request seq 4
    14:24:07.963909 IP (tos 0x0, ttl  30, id 0, offset 0, flags [none], length: 56) 85.249.169.1 > 192.168.1.2: icmp 36: time exceeded in-transit
    14:24:08.947740 IP (tos 0x0, ttl   1, id 63649, offset 0, flags [none], length: 68) 85.249.169.28 > 192.168.240.1: icmp 48: echo request seq 5
    14:24:08.962690 IP (tos 0x0, ttl  30, id 0, offset 0, flags [none], length: 56) 85.249.169.1 > 192.168.1.2: icmp 36: time exceeded in-transit
    14:24:09.947528 IP (tos 0x0, ttl   1, id 63650, offset 0, flags [none], length: 68) 85.249.169.28 > 192.168.240.1: icmp 48: echo request seq 6
    14:24:09.963014 IP (tos 0x0, ttl  30, id 0, offset 0, flags [none], length: 56) 85.249.169.1 > 192.168.1.2: icmp 36: time exceeded in-transit
    14:24:10.947347 IP (tos 0x0, ttl   2, id 63651, offset 0, flags [none], length: 68) 85.249.169.28 > 192.168.240.1: icmp 48: echo request seq 7
    14:24:10.949408 IP (tos 0x0, ttl 254, id 63651, offset 0, flags [none], length: 68) 192.168.240.1 > 85.249.169.28: icmp 48: echo reply seq 7
    14:24:11.947143 IP (tos 0x0, ttl   2, id 63652, offset 0, flags [none], length: 68) 85.249.169.28 > 192.168.240.1: icmp 48: echo request seq 8
    14:24:11.948523 IP (tos 0x0, ttl 254, id 63652, offset 0, flags [none], length: 68) 192.168.240.1 > 85.249.169.28: icmp 48: echo reply seq 8
    14:24:12.946996 IP (tos 0x0, ttl   2, id 63653, offset 0, flags [none], length: 68) 85.249.169.28 > 192.168.240.1: icmp 48: echo request seq 9
    14:24:12.959689 IP (tos 0x0, ttl 254, id 63653, offset 0, flags [none], length: 68) 192.168.240.1 > 85.249.169.28: icmp 48: echo reply seq 9
    Посмотрите на TTL исходящих пакетов И обратите внимание, что time-limit exceeded идут по три штуки, как раз сколько попыток делает traceroute на каждый хоп.

    Итак вывод: исходящий траффик у Вас вроде бы работает как надо, значит затык происходит на обратном пути.

    Quote Originally Posted by AYuusuke View Post
    Заметил следующую вешь
    Возможно это связано с тем, что TCP/IP стек работает асинхронно и кэширует дофига чего; не зря во всех примерах iproute всё время советуют делать ip route flush cache после каждого изменения таблицы маршрутов.

    Quote Originally Posted by AYuusuke View Post
    Получается что сопровождение соединений происходит до нашего преобразования, что вообщем то правильно. Но почему обратные пакеты не пролезают?
    Вот это и есть следующая задача :-)
    Last edited by zap; 16-12-2007 at 11:34.

  7. #67
    Да, конечно же я опять описался (всетаки 3 часа ночи было). Ну похоже и так понятно какой кабель в какой порт подключен

    Про второй WAN порт конечно можно попробовать, но к сожалению не сейчас. Пока все порты асуса заняты (я не с проста брал диапазон на 16 плюшевых адресов), нужно или еще свич покупать или еще кабели прокладывать... пока повременю с этим.

    Я правильно понял что если получится необходимое мне преобразование реализовать с помошью какого то stateful nat-а, то сильно хуже не будет? У меня дома не так много компов (следовательно и общее кол-во соединений, которые будут сопровождаться рутером не очен велико), должно потянуть...

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

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

    У вас есть мысли, почему не срабатывает обратное преобразование 10.0.0.0/8->2.0.0.0/8 ?
    Code:
    iptables -t mangle -I PREROUTING -i vlan1 -s 10.0.0.0/8 -j MARK --set-mark 5
    ip rule add fwmark 5 nat 2.0.0.0 from 10.0.0.0/8
    Правила написаны до смешного простыми, все преобразование должны быть stateless... Почему же не рабоатет..

  8. #68
    Quote Originally Posted by AYuusuke View Post
    То что наши админы смогли такое сделать и послужило поводом попробовать это же сделать самому.
    Ну, у админов, я думаю, NETMAP работает правильно :-)

    Quote Originally Posted by AYuusuke View Post
    Я правильно понял что если получится необходимое мне преобразование реализовать с помошью какого то stateful nat-а, то сильно хуже не будет? У меня дома не так много компов (следовательно и общее кол-во соединений, которые будут сопровождаться рутером не очен велико), должно потянуть...
    Я бы не стал, но в принципе конечно это будет работать.

    Quote Originally Posted by AYuusuke View Post
    Насчет входящих пакетов: можете посоветовать какую либо утилиту или команду логирования, которая бы показала на каком этапе входящие пакеты отбрасываются? Я что то слышал про возможность логирования из iptables, но какую цель писать, в какой таблице и в какой цепочке мне плохо понятно. Поможете?
    Это достаточно просто, но я не уверен что это даст искомый ответ.

    iptables -A xxx -j LOG

    при этом пакеты будут уходить в журнал ядра (dmesg либо включите klogd на /var/log/messages).

    Quote Originally Posted by AYuusuke View Post
    У вас есть мысли, почему не срабатывает обратное преобразование 10.0.0.0/8->2.0.0.0/8 ?
    Возможно, оно срабатывает но, например слишком поздно (после принятия решения о роутинге?). Может оно не в тот интерфейс уходит? Для профилактики посмотрите tcpdump на других интерфейсах, и не пользуйте Вы этот tracert, он даёт кучу ненужных эффектов. Простой пинг; один пакет туда - один обратно. Всё предельно ясно, а tracert вон какие сюрпризы выкидывает

    Quote Originally Posted by AYuusuke View Post
    Code:
    iptables -t mangle -I PREROUTING -i vlan1 -s 10.0.0.0/8 -j MARK --set-mark 5
    ip rule add fwmark 5 nat 2.0.0.0 from 10.0.0.0/8
    Может попробовать сначала сделать простое правило:

    Code:
    ip rule add nat 2.0.0.0 from 10.0.0.0/8
    Возможно mangle отрабатывает уже после того, как срабатывает ip rule?

    Покопаюсь попозже в исходниках, посмотрю что там с NETMAP. Возможно, можно будет отказаться от iproute.
    Last edited by zap; 16-12-2007 at 12:25.

  9. #69
    Пока вы еще не разобрались с NETMAP, я поставил еще эксперимент. Тестировал только iproute2 правила (ниже по тексту видно).

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

    "ping 10.20.36.183" (настройки по умолчанию):
    Code:
    [admin@anthy root]$ tcpdump -n -i vlan1 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
    15:58:03.115315 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 459, length 40
    15:58:03.117777 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 459, length 40
    15:58:04.117792 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 460, length 40
    15:58:08.729143 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 461, length 40
    15:58:08.745746 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 461, length 40
    15:58:09.731992 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 462, length 40
    [admin@anthy root]$ tcpdump -n -i br0 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on br0, link-type EN10MB (Ethernet), capture size 68 bytes
    15:58:03.115153 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 459, length 40
    15:58:03.117992 IP 10.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 459, length 40
    15:58:04.117633 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 460, length 40
    15:58:08.728976 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 461, length 40
    15:58:08.745886 IP 10.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 461, length 40
    15:58:09.731827 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 462, length 40
    Делаем
    Code:
    ip route add nat 2.0.0.0/8 via 10.0.0.0
    ip rule add nat 2.0.0.0 from 10.0.0.0/8
    ip route flush cache
    Конечно это правило совсем не то что мне нужно, но будем проверять как это простое преобразование работает само по себе. Почти что пример из книжки.

    "ping 10.20.36.183":
    Code:
    [admin@anthy root]$ tcpdump -n -i vlan1 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
    16:02:27.112499 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 467, length 40
    16:02:27.114954 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 467, length 40
    16:02:31.691791 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 468, length 40
    16:02:36.691114 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 469, length 40
    16:02:41.690412 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 470, length 40
    16:02:41.691577 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 470, length 40
    [admin@anthy root]$ tcpdump -n -i br0 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on br0, link-type EN10MB (Ethernet), capture size 68 bytes
    16:02:27.112332 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 467, length 40
    16:02:27.115121 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 467, length 40
    16:02:31.691623 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 468, length 40
    16:02:36.690946 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 469, length 40
    16:02:41.690244 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 470, length 40
    16:02:41.691717 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 470, length 40
    Подмена source поля работает. На хосте в окне пинга "Превышен интервал ожидания для запроса". Пока все правильно.

    Ждем минуту и делаем "ping 2.20.36.183":
    Code:
    [admin@anthy root]$ tcpdump -n -i vlan1 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
    16:05:51.007108 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 477, length 40
    16:05:51.023498 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 477, length 40
    16:05:55.662083 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 478, length 40
    16:05:55.664256 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 478, length 40
    16:06:00.661375 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 479, length 40
    16:06:00.666117 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 479, length 40
    16:06:05.660651 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 480, length 40
    16:06:05.671859 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 480, length 40
    [admin@anthy root]$ tcpdump -n -i br0 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on br0, link-type EN10MB (Ethernet), capture size 68 bytes
    16:05:51.006936 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 477, length 40
    16:05:55.661919 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 478, length 40
    16:06:00.661200 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 479, length 40
    16:06:05.660478 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 480, length 40
    Ответы застряли где то внутри рутера.

    Делаем "ping 10.20.36.183 -w 50" и сразу после этого "ping 2.20.36.183 -w 50":
    Code:
    [admin@anthy root]$ tcpdump -n -i vlan1 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
    16:09:19.885091 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 506, length 40
    16:09:19.895111 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 506, length 40
    16:09:21.134841 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 507, length 40
    16:09:21.138853 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 507, length 40
    16:09:22.633631 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 508, length 40
    16:09:24.133358 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 509, length 40
    16:09:27.552651 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 510, length 40
    16:09:27.555015 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 510, length 40
    16:09:28.555700 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 511, length 40
    16:09:29.633477 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 512, length 40
    16:09:29.637206 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 512, length 40
    16:09:30.639318 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 513, length 40
    16:09:30.649347 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 513, length 40
    [admin@anthy root]$ tcpdump -n -i br0 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on br0, link-type EN10MB (Ethernet), capture size 68 bytes
    16:09:19.884839 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 506, length 40
    16:09:19.895262 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 506, length 40
    16:09:21.134610 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 507, length 40
    16:09:21.139002 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 507, length 40
    16:09:22.633392 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 508, length 40
    16:09:24.133184 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 509, length 40
    16:09:27.552409 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 510, length 40
    16:09:27.555158 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 510, length 40
    16:09:28.555522 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 511, length 40
    16:09:29.633313 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 512, length 40
    16:09:29.637353 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 512, length 40
    16:09:30.639144 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 513, length 40
    Работает и подмена source и подмена destination. На хосте в окне ping-а видны ответы

    Как я интерпретирую полученный результат: где то все равно используется stateful преобразование, и пока нет запроса на 10.x.x.x, наши ответы с 2.x.x.x игнорируются. Когда проходит один запрос на 10.x.x.x - появляется запись в какой то таблице, и наши ответы на запрос уже на адрес 2.x.x.x приходят обратно по "соединению", оставшемуся от запроса на 10.x.x.x.

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

    Так же посмотрел что происходит на других интерфейсах - там все нормально, наши потерявшиеся пакеты на неправильный интерфейс не уходят.
    Last edited by AYuusuke; 16-12-2007 at 17:11.

  10. #70
    To: Oleg
    Я столкнулся с такой же проблемой NETMAP действительно битый (прошивка 1.9.2.7-8). У меня это проявляется тем что я не могу постаить правила для цепочки OUTPUT:
    Code:
    # iptables -t nat -A OUTPUT -d 192.168.0.0/16 -j NETMAP --to 10.24.0.0/16
    iptables: Invalid argument
    А правила для цепочки PREROUTING/POSTROUTING:
    Code:
    # iptables -t nat -A PREROUTING -d 192.168.0.0/16 -j NETMAP --to 10.24.0.0/16
    Ставятся но неверно работают. Трансляция адреса происходит но младшие 16 бит содержат мусор, а не то что было в оригинальном адресе.

    Это можно как-то исправить, так чтобы NETMAP работал как положено?

  11. #71

    iptables, правило для pptp

    Всех с новым годом !

    Что-то никак не могу найти подходящее правило. Нужно чтобы машины с внутренней сети могли подключаться к vpn.

    Заранее спасибо.

  12. #72
    Это не правило iptables, a модуль conntrack ( connection tracking). Что-то типа ip_conntrack_pptp, как точно называется у Олега в прошивке сказать не могу, нет железки под рукой. Посмотри у себя в /lib/modules/<version>/kernel/net/ ....

    Это если касательно pptp. IPSec работает и без трекинга ...

  13. #73
    Quote Originally Posted by MMike View Post
    Это не правило iptables, a модуль conntrack ( connection tracking). Что-то типа ip_conntrack_pptp, как точно называется у Олега в прошивке сказать не могу, нет железки под рукой. Посмотри у себя в /lib/modules/<version>/kernel/net/ ....

    Это если касательно pptp. IPSec работает и без трекинга ...
    Блин, нестыковочка вышла, у меня debian, contrack стоит или по у молчанию есть в тамошнем iptables...

  14. #74
    Да у нас в Debiane лежат тут /lib/modules/<version>/kernel/net/netfilter/

    по умолчанию в 2.6.23 есть такие:
    nf_conntrack_amanda.ko
    nf_conntrack_ftp.ko
    nf_conntrack_h323.ko
    nf_conntrack_irc.ko
    nf_conntrack_pptp.ko нужный нам действительно есть
    nf_conntrack_proto_gre.ko
    nf_conntrack_proto_sctp.ko
    nf_conntrack_proto_udplite.ko
    nf_conntrack_sane.ko
    nf_conntrack_sip.ko
    nf_conntrack_tftp.ko

    У Олега в прошивке, да и вообще по моему в 2.4м ядре должен называться ip_conntrack_pptp.

    Так что ищите и обрящите

  15. #75
    Quote Originally Posted by MMike View Post
    Да у нас в Debiane лежат тут /lib/modules/<version>/kernel/net/netfilter/

    по умолчанию в 2.6.23 есть такие:
    nf_conntrack_amanda.ko
    nf_conntrack_ftp.ko
    nf_conntrack_h323.ko
    nf_conntrack_irc.ko
    nf_conntrack_pptp.ko нужный нам действительно есть
    nf_conntrack_proto_gre.ko
    nf_conntrack_proto_sctp.ko
    nf_conntrack_proto_udplite.ko
    nf_conntrack_sane.ko
    nf_conntrack_sip.ko
    nf_conntrack_tftp.ko

    У Олега в прошивке, да и вообще по моему в 2.4м ядре должен называться ip_conntrack_pptp.

    Так что ищите и обрящите
    Так... странно что-то нет нужного файла...

    xt_conntrack.ko - самое похожее

    ядро 2.6.18.

Page 5 of 12 FirstFirst ... 34567 ... LastLast

Similar Threads

  1. How to run two webservers
    By sesamebike in forum WL-500g/WL-500gx Tutorials
    Replies: 36
    Last Post: 13-03-2007, 08:05
  2. How to automatically start post-boot?
    By VaZso in forum WL-500g Q&A
    Replies: 8
    Last Post: 04-07-2006, 11:48
  3. SSH and iptables trouble
    By tokyoturnip in forum WL-500g Q&A
    Replies: 4
    Last Post: 11-06-2006, 17:14
  4. WL-500gx WAN & LAN Filter example
    By pshah in forum WL-500g Q&A
    Replies: 1
    Last Post: 24-09-2005, 13:50
  5. How to configure Firewall/iptables
    By samoht in forum WL-500g/WL-500gx Tutorials
    Replies: 3
    Last Post: 14-08-2005, 01:28

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •