LINUX.ORG.RU
ФорумAdmin

nat в Fedora 21

 , ,


0

2

Дистрибутив Fedora 21.
Решил по быстрому сделать точку доступа WIFI, чтобы на пять минут раздать интернет 5 устройствам.
Все как обычно, например на шлюзе Debian.
Установил и настроил dhcp сервер и hostapd, включил forwarding пакетов echo 1 > /proc/sys/net/ipv4/ip_forward.

И тут я заглянул в правила iptables. Увидел кучу правил. Понял что они устанавливаются демоном firewalld. Не захотел в этом разбираться и остановил демон - правила исчезли, все цепочки пусты. Отлично!
Действие по умолчанию во всех цепочках accept. Добавил правило:

iptables -t nat -A POSTROUTING -s 192.168.1.0/28 -j MASQUERADE
На всякий случай привожу выводы правил таблиц:
Таблица Filter:
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  

Таблица nat:
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  192.168.1.0/28       0.0.0.0/0           
В таблицах raw и mangle тоже по умолчанию стоят accept и цепочки пусты.

Итого forwarding пакетов работает нормально. tcpdump показывает что пакеты нормально перенаправляются. Но ip адрес источника не изменяется. То есть MASQUERADE не работает.

Если добавить правило:

iptables -t nat -I POSTROUTING 1 -s 192.168.1.0/28 -j LOG
То видно что в эту цепочку пакеты попадают. Но действие MASQUERADE не отрабатывает. Также пробовал использовать действие SNAT - оно тоже не меняет адрес источника.
Вроде необходимые модули ядра подгружены:
lsmod | grep -E "nf|ipt"
ipt_MASQUERADE         12678  1 
nf_nat_masquerade_ipv4    13203  1 ipt_MASQUERADE
nf_log_ipv4            12767  0 
nf_log_common          13086  1 nf_log_ipv4
iptable_nat            12875  1 
nf_conntrack_ipv4      14656  1 
nf_defrag_ipv4         12702  1 nf_conntrack_ipv4
nf_nat_ipv4            13848  1 iptable_nat
nf_nat                 25180  2 nf_nat_ipv4,nf_nat_masquerade_ipv4
nf_conntrack          103465  4 nf_nat,nf_nat_ipv4,nf_nat_masquerade_ipv4,nf_conntrack_ipv4
iptable_raw            12678  0 

Конечно я в итоге загуглил как включить nat через firewalld, и все заработало. Но мне очень интересно, почему же обычный iptables не работает.



Последнее исправление: demsi (всего исправлений: 3)

Я просто нажал пкм в трее на менеджера сети и там создал подключение. Зачем такие сложности?

spichka ★★★
()

Попробуй сам себе ответить - чем MASQUERADE отличается от NAT. Тогда ты сможешь сам понять, чего не хватает в твоих правилах POSTROUTING-а. Ибо понимание действий - всегда лучше копипаста.

xnt
()

Если интерестно разбираться в чудесах, то можно посмотреть счётчики у SNAT-правила, чтобы точно убедится, что правило срабатывало. И ещё посмотреть записи в таблице conntrack для этого соединения.

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

Попробуй сам себе ответить - чем MASQUERADE отличается от NAT. Тогда ты сможешь сам понять, чего не хватает в твоих правилах POSTROUTING-а. Ибо понимание действий - всегда лучше копипаста.

NAT (от англ. Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. Также имеет названия IP Masquerading, Network Masquerading и Native Address Translation.

Может не будем делать из себя супер умных и выпендриваться? Теперь читаем http://www.opennet.ru/docs/RUS/iptables/#TABLE.MASQUERADETARGET и читаем что в контексте iptables действия SNAT и MASQUERADE являются почти синонимами. За исключением того что в SNAT можно указать вручную ip адрес на который будет произведена замена адреса источника в проходящих пакетах.

Маскарадинг (MASQUERADE) в основе своей представляет то же самое, что и SNAT только не имеет ключа --to-source. Причиной тому то, что маскарадинг может работать, например, с dialup подключением или DHCP, т.е. в тех случаях, когда IP адрес присваивается устройству динамически. Если у вас имеется динамическое подключение, то нужно использовать маскарадинг, если же у вас статическое IP подключение, то бесспорно лучшим выходом будет использование действия SNAT.

Маскарадинг подразумевает получение IP адреса от заданного сетевого интерфейса, вместо прямого его указания, как это делается с помощью ключа --to-source в действии SNAT. Действие MASQUERADE имеет хорошее свойство - «забывать» соединения при остановке сетевого интерфейса. В случае же SNAT, в этой ситуации, в таблице трассировщика остаются данные о потерянных соединениях, и эти данные могут сохраняться до суток, поглощая ценную память. Эффект «забывчивости» связан с тем, что при остановке сетевого интерфейса с динамическим IP адресом, есть вероятность на следующем запуске получить другой IP адрес, но в этом случае любые соединения все равно будут потеряны, и было бы глупо хранить трассировочную информацию.

Как вы уже поняли, действие MASQUERADE может быть использовано вместо SNAT, даже если вы имеете постоянный IP адрес, однако, невзирая на положительные черты, маскарадинг не следует считать предпочтительным в этом случае, поскольку он дает большую нагрузку на систему.

Действие MASQUERADE допускается указывать только в цепочке POSTROUTING таблицы nat, так же как и действие SNAT. MASQUERADE имеет ключ, описываемый ниже, использование которого необязательно.

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

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

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

Если интерестно разбираться в чудесах, то можно посмотреть счётчики у SNAT-правила, чтобы точно убедится, что правило срабатывало. И ещё посмотреть записи в таблице conntrack для этого соединения.

Спасибо за совет. О счетчиках совсем забыл. Обязательно посмотрю. Но из вывода tcpdump очевидно что nat не срабатывает, так как пакеты уходят наружу с исходным адресом внутренней сети (((.

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

Копипастить просто, а вот думать и анализировать Вас видимо не научили.

demsi

Маскарадинг подразумевает получение IP адреса от заданного сетевого интерфейса, вместо прямого его указания, как это делается с помощью ключа --to-source в действии SNAT


Теперь смотри на свое правило:

iptables -t nat -A POSTROUTING -s 192.168.1.0/28 -j MASQUERADE

А теперь ответь - к какому сетевому интерфейсу применяется в этом правиле маскарадинг?


demsi

Контингент конечно на лоре все хуже и хуже....


Да, по вам это хорошо заметно.


Как говорили классики:

Артур Кларк

Любая передовая технология подобна волшебству.

К сожалению, новое поколение совсем перестало использовать основной инструмент Человека.
Вставил магическую строчку - «и все работает»!

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

К сожалению, новое поколение совсем перестало использовать основной инструмент Человека. Вставил магическую строчку - «и все работает»!

А вот теперь убираем все Ваше высокомерное и бла бла бла. И смотрим что по существу.
Первым делом вы утверждаете что masquerade и nat принципиально отличаются и проблема в этом отличии. Про сетевой интерфейс изначально не сказано ни слова.
Затем сразу же меняете свою точку зрения и утверждаете что проблема в том что не указан сетевой интерфейс в правиле. То есть про отличия masquerade и nat сразу внезапно забываем.
У Вас явно слабая позиция в этом споре, учитывая что Ваши аргументы никак не связаны и Вы скорее всего на слабом уровне понимаете маршрутизацию и принципы работы iptables.

А теперь я Вам отвечаю без всяких высокомерных вставок говорю что Вы не правы. Iptables не осуществляет маршрутизацию пакетов. В iptabels задаются критерии. Пакеты проходя по цепочкам правил сравниваются с этими критериями, и если пакет выполняет условия критерия к нему применяется указанное действие. На какой интерфейс отправить пакет определяет ядро с помощью таблицы маршрутизации. Когда пакет попадает в цепочку POSTROUTING в моем случае он уже отправляется через интерфейс который имеет выход в интернет. Это легко доказать с помощью логирования пакетов. Если бы это было не так, то правило:

iptables -t nat -I POSTROUTING 1 -s 192.168.1.0/28 -j LOG
Не сработает. Но в моем конкретном случае в логах появляются записи подобные этой:
kernel: OUT=ppp0 SRC=192.168.1.2 DST=94.24.252.216 ...
Заметим что в правиле не указан сетевой интерфейс, но тем не менее логирование осуществляется, что доказывает факт правильно отработанного правила без указанного сетевого интерфейса. Также заметим что в логе указан интерфейс. Очевидно Ваша точка зрения про неуказанный сетевой интерфейс не верна. И естественно для чистоты эскперемента были опробованы правила:
-t nat POSTROUTING -o ppp0 -j MASQUERADE
и
-t nat POSTROUTING -o ppp0 -j SNAT --to-soure ext_ip
...
и подобные

C чего Вы взяли что более компетентный специалист? С чего Вы взяли что Вы лучше разбираетесь в iptables чем Я? С чего Вы взяли что умнее и старше меня? С чего вы взяли что Я не понимаю как работают элементарные правила iptables? Откуда у Вас такое высокомерие? Все Ваши попытки сделать вид что Ваш интелект выше чем у других людей и абсолютное невежество, говорят о Вас как о высокомерном человеке готовом отстаивать свою точку зрения даже когда он не прав. Такое поведение обычно присуще подросткам. Ведь перед тем как оскорблять другого человека нужно хотя бы из уважения к себе проверить свои знания. Вы надеюсь далее не будете показывать свое невежество, поймете что iptables не отвечает за маршрутизацию пакетов, и поступите как взрослый человек - признаете свою неправоту и извинитесь?

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

Я просто нажал пкм в трее на менеджера сети и там создал подключение. Зачем такие сложности?

У меня к сожалению при попытке создать беспроводную сеть через NetworkManager в разделе безопасность нет WPA шифрования скрин. Сети с Wep шифрованиям очень легко ломаются утилитами aircrack. Возможно есть какой-то плагин для NetworkManager, который добавляет нужный мне функционал? Но в любом случае это не универсальное решение. Хотелось бы его применять как к fedora с десктопами и к серверам centos 7 без Xorg, да и сложностей никаких тут нет. Как Вы уже заметили, меня интересует не реализация, так как у меня все работает. Меня интересует именно причины не работоспособности действия MASQUERADE и SNAT в iptables.

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

demsi

C чего Вы взяли что более компетентный специалист? С чего Вы взяли что Вы лучше разбираетесь в iptables чем Я? С чего Вы взяли что умнее и старше меня? С чего вы взяли что Я не понимаю как работают элементарные правила iptables?



Нет, разумеется Вы умнее и компетентнее.
И лучше меня знаете iptables, routing, nat и много других страшных слов.

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

Я думаю здесь найдутся другие желающие оказать Вам помощь в элементарных настройках, все разжуют, Вам останется только проглотить.
Однако при таком подходе Вы так никогда ничему и не научитесь.

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

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

И это говорит человек который пишет:

Ибо понимание действий - всегда лучше копипаста.

К сожалению, новое поколение совсем перестало использовать основной инструмент Человека. Вставил магическую строчку - «и все работает»!

Я конечно признаю что переборщил и прошу за это извинения, но меня раздражает когда люди не разбираясь в теме пытаются учить других. А именно Ваши фразы про маскарадинг и нат, потом про сетевой интерфейс в правилах iptables. Говорят о том что у Вас не много опыта работы с iptables. Но при этом Вы надменно полагаете по умолчанию, что я первый раз вижу iptables и его правила это какие-то магические, совершенно мне непонятные заклинания.

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

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

что nat не срабатывает

NAT в ядре состоит из двух частей. Одна часть это правило в iptables (SNAT или DNAT), которое просто модифицирует запись в таблице conntrack, другая — собственно код, изменяющий поля в заголовке пакета (ip-адрес) по записям в этой таблице.

Команда ″conntrack″ позволяет просматривать записи в этой таблице. Не знаю, в каком она пакете, но, наверное, сможете найти.

Например, с одного из клиентский компов можно сделать:

telnet 149.20.4.69 80

а на шлюзе (пока telnet не отвалился по таймауту) выполнить:

conntrack -L -s 149.20.4.69

и будет видна какая запись в таблице conntrack сейчас, при работающим nat'е. А потом отключите firewalld, создайте SNAT-правило и посмотрите, создаётся ли подобная запись.

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

Так попробовал это сделать на ноутбуке. На нем стоит Fedora 20. Странно но на нем все работает замечательно.
Завтра буду ковырять дальше 0)). Чудеса.

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

demsi

Я конечно признаю что переборщил


Проблема не Вас конкретно. А в общей системе современного образования. Когда человеку пытаешься помочь, задавая наводящие вопросы, чтобы он сам додумался до решения, а в ответ получаешь:

demsi

Понимаем всю глупость своего ответа и валим из ветки куда подальше


Отлично видно результат работы реформ образования,озвученные бывшим министром:

Андрей Фурсенко

…недостатком советской системы образования была попытка формировать человека-творца, а сейчас задача заключается в том, чтобы взрастить квалифицированного потребителя, способного квалифицированно пользоваться результатами творчества других

http://ru.wikipedia.org/wiki/%D4%F3%F0%F1%E5%ED%EA%EE,_%C0%ED%E4%F0%E5%E9_%C0%EB%E5%EA%F1%E0%ED%E4%F0%EE%E2%E8%F7#.D0.9E.D1.82.D0.BD.D0.BE.D1.88.D0.B5.D0.BD.D0.B8.D0.B5_.D0.BA_.D1.81.D0.BE.D0.B2.D0.B5.D1.82.D1.81.D0.BA.D0.BE.D0.BC.D1.83_.D0.BE.D0.B1.D1.80.D0.B0.D0.B7.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8E_.D0.B8_.D1.84.D0.BE.D1.80.D0.BC.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8E_.D1.87.D0.B5.D0.BB.D0.BE.D0.B2.D0.B5.D0.BA.D0.B0-.D1.82.D0.B2.D0.BE.D1.80.D1.86.D0.B0


Ибо ясно, что люди ожидают увидеть готовое решение своей проблемы. Воспользовавшись чужим трудом, знаниями, опытом. Не включая свою соображалку.
Таких много повидал на собеседованиях - нахватавшись заголовков, за решением элементарных проблем бегут на лор, опеннет, гугл/etc. Подставить свои параметры/айпишники и т.д. в скрипты и конфиги ума много не надо.
А вот понимание - стало редкой вещью. К сожалению :(

А по существу - запусти от рута скриптик:

#!/bin/sh

/sbin/iptables -F INPUT
/sbin/iptables -F FORWARD
/sbin/iptables -F OUTPUT

/sbin/iptables -t nat -F INPUT
/sbin/iptables -t nat -F OUTPUT
/sbin/iptables -t nat -F PREROUTING
/sbin/iptables -t nat -F POSTROUTING

/sbin/iptables -t mangle -F INPUT
/sbin/iptables -t mangle -F OUTPUT
/sbin/iptables -t mangle -F FORWARD
/sbin/iptables -t mangle -F PREROUTING
/sbin/iptables -t mangle -F POSTROUTING

/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

/sbin/sysctl -w net.ipv4.conf.all.forwarding=1
/sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0

Должно заработать.
По поводу wpa - смотрите в сторону wpa_supplicant.
В штатах есть ограничение на экспорт стойких систем шифрования.
Возможно нужен какой-нить extended пакет, или ставить из сторонних репозитариев - не знаю, у меня федоры нет, не пользую.
На debian-е, ubunt-e все работает штатно.

xnt
()

Забавно.

А покажи iptables-save после добавления правил и выхлоп tcpdump'а с улетающим наружу пакетом (который должен был бы замаскарадиться, но не замаскарадился). Ну и тоже с любопытством жду вывода таблиц conntrack по рецепту умного чувака выше.

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

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

Ибо ясно, что люди ожидают увидеть готовое решение своей проблемы. Воспользовавшись чужим трудом, знаниями, опытом

Я понял как с Вами нужно разговаривать. Спасибо за элементарный скрипт, который очищает все цепочки трех таблиц (таблицу raw забыли?), включает форвардинг, и отключает итак отключенную по умолчанию маршрутизацию от источника. Конечно же я нигде, например в описании своих проблем, не указывал что все таблицы очищены и не указывал что форвардинг включен. Конечно же я не понимаю что за магические заклинания Вы мне тут написали.

А теперь продолжим дискуссию,Вы признаете что были неправы в двух своих утверждениях?

Попробуй сам себе ответить - чем MASQUERADE отличается от NAT

То есть Вы утверждали что установленное мною правило не работало из-за отличий MASQUERADE от NAT

А теперь ответь - к какому сетевому интерфейсу применяется в этом правиле маскарадинг?

Теперь здесь вы утверждаете, то что без указания сетевого интерфейса правило работать не будет. Что конечно же совершенно абсурдное утверждение.

Поверьте, мне искренне жаль что Вам дали власть кого-то собеседовать. Берите пример с компетентных специалистов как mky. Отличный специалист, вот к какому уровню знаний нужно стремиться, человек отлично разбирается в сетях. Не первый раз дает полезные советы.

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

[quoute=«demsi»] Спасибо за элементарный скрипт

Всегда пожалуйста. Вот только результатов его работы Вы не привели.

demsi

Я понял как с Вами нужно разговаривать.

Т.К, становиться очевидным, что результат Вам не нужен, а всего-лишь споры/разговоры, весь этот тред я считаю «вбросом» тролля.
Человек неосиливший NAT в linux-е, это просто Epic Fail!

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

Ваш скрипт воспроизводит те действия которые я описал в начале треда.
Кроме вас всем очевидно, что тред создан не с целью получения какого-то результата. Так как результат уже есть и описан в начале треда , также в треде четко указано что все работает на другом компьютере и дистрибутиве Fedora 20 с аналогичными настройками iptables.
А Вы полностью игнорируйте эти факты и пытаетесь мне объяснить очевидные вещи в которых плохо разбираетесь. Подсовывайте «готовое решение», которое мало того что повторяет все что я описал в начале треда, так и вносит небезопасное правило:

/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
А вы учли, что может быть я хочу клиентов своей сети пустить во внутреннюю сеть провайдера? А вы учли, что может быть я не хочу раздавать всей внутренней сети провайдера интернет? Как эту строчку можно называть «готовым решением» когда она просто ужасна. Если я пишу:
iptables -t nat -A POSTROUTING -s 192.168.1.0/28 -j MASQUERADE
Вам не приходит в голову что мне так и нужно? Хотя кого я спрашиваю, Вы же гуру, а все тупые и некомпетентные. Вы такого не говорили, но манера вашего общения и менторский тон говорят об этом.

Конечно наверное лучше написать:

iptables -t nat -A POSTROUTING -s 192.168.1.0/28 -o ppp0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.1.0/28 -o p4p1 -j MASQUERADE
Но в моем случае этого не нужно делать, так как во внутренней сети клиенты напрямую обмениваются пакетами, и остается только два интерфейса ppp0(интернет) и p4p1(внутренняя сеть провайдера).

Вы называете меня Троллем, хотя не внимательно читаете Тред, пишите про какую-то копипасту, что-то там об образовании, отвлекаете меня от изучения странного поведения iptables. Кстати постараюсь напомнить что тред именно посвящен изучению странного поведения iptables, а не настройки точки доступа с раздачей интернета. Я на всякий случай напоминаю, а то кроме Вас об этом всем здесь известно, но Вы почему-то напрочь игнорируйте этот факт. Вступили со мной в дискуссию в которой оказались не правы, и не хотите признавать свои ошибки.

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

А теперь наконец-то можно по делу. iptables-save:

# Generated by iptables-save v1.4.21 on Tue Feb  3 13:55:30 2015
*nat
:PREROUTING ACCEPT [120:13494]
:INPUT ACCEPT [7:1968]
:OUTPUT ACCEPT [246:15306]
:POSTROUTING ACCEPT [246:15306]
-A POSTROUTING -s 192.168.1.0/28 -j MASQUERADE
COMMIT
# Completed on Tue Feb  3 13:55:30 2015
# Generated by iptables-save v1.4.21 on Tue Feb  3 13:55:30 2015
*filter
:INPUT ACCEPT [16803:17430056]
:FORWARD ACCEPT [495:77515]
:OUTPUT ACCEPT [12144:1296456]
COMMIT
# Completed on Tue Feb  3 13:55:30 2015
Из внутренней сети с машины 192.168.1.2 идет пинг 8.8.8.8.
tcpdump интерфейса шлюза через который раздается wifi, его адрес и маска 192.168.1.1/28:
# tcpdump -i wls1 -n host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wls1, link-type EN10MB (Ethernet), capture size 262144 bytes
13:51:49.491681 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2307, length 40
13:51:54.491763 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2308, length 40
13:51:59.491835 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2309, length 40
13:52:04.491901 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2310, length 40
13:52:09.494377 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2311, length 40
13:52:14.492158 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2312, length 40
....
tcpdump интерфейса через который шлюз получает доступ в интернет:
# tcpdump -i ppp0 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:51:34.991446 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2304, length 40
13:51:39.491538 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2305, length 40
13:51:44.494737 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2306, length 40
13:51:49.491719 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2307, length 40
13:51:54.491808 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2308, length 40
13:51:59.491889 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2309, length 40
13:52:04.491931 IP 192.168.1.2 > 8.8.8.8: ICMP echo request, id 1, seq 2310, length 40
....
Как видим адрес не изменяется.
Вывод conntrack:
# conntrack -L -d 8.8.8.8
icmp     1 25 src=192.168.1.2 dst=8.8.8.8 type=8 code=0 id=1 [UNREPLIED] src=8.8.8.8 dst=192.168.1.2 type=0 code=0 id=1 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
conntrack v1.4.2 (conntrack-tools): 1 flow entries have been shown.
При этом в таблице nat на правиле MASQUERADE число пакетов становится больше )))
num   pkts bytes target     prot opt in     out     source               destination         
1      121 12470 MASQUERADE  all  —  *      *       192.168.1.0/28       0.0.0.0/0           

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

А чего тут трассировать?

MASQUERADE был введен для случаев, когда адрес интерфейса периодически меняется (к примеру при получении настроек от DHCP).
Когда невозможно заранее прописать фиксированный адрес для натирования (SNAT)

При действии MASQUERADE, определяется текущий адрес на интерфейсе и выполняется SNAT с этим адресом.
Правило

demsi

iptables -t nat -A POSTROUTING -s 192.168.1.0/28 -j MASQUERADE


смысла не имеет, ибо как любезно заметил demsi,
ВнезапнО вдруг вспомнив про маршрутизацию:

demsi

Iptables не осуществляет маршрутизацию пакетов

Это истина, и более того, ему абсолютно пофиг, откуда пришел пакет,
куда он уйдет, его задача проста - принять/отбросить или модифицировать пакет в соответствии с заданными критериями.
Учитывая то, что iptables ничего не знает про маршрутизацию,
взять айпишник для подстановки в действие MASQUERADE неоткуда.

На что я и задал наводящий вопрос demsi - понимает ли он разницу, между NAT и MASQUERADE:

demsi

Тогда ты сможешь сам понять, чего не хватает в твоих правилах POSTROUTING-а.


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

demsi

Если добавить правило:

iptables -t nat -I POSTROUTING 1 -s 192.168.1.0/28 -j LOG
То видно что в эту цепочку пакеты попадают. Но действие MASQUERADE не отрабатывает.


=)

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

А чего тут трассировать?

Это мне вопрос? Если так, то conntrack применяется не для трассировки.

Учитывая то, что iptables ничего не знает про маршрутизацию, взять айпишник для подстановки в действие MASQUERADE неоткуда.

Вместе с пакетом в netfilter/iptables передаются некоторые параметры, в числе которых есть и имя входящего/исходящего (в зависимости от цепочки) интерфейса. Зная имя интерфейса, можно посмотреть адрес, висящий на нем. Поэтому правило

iptables -t nat -A POSTROUTING -s 192.168.1.0/28 -j MASQUERADE
валидно и не бессмысленно.

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

Забей. Это бесполезно.Человек совсем не понимает что происходит. Он не понимает что действие MASQUERADE да и вообще любое другое действие в iptables не может брать параметры из критериев. iptables просто выполняет действие сравнивая заголовки пакета и параметры с критериями. Нужно четко понимать, что критерии это просто критерии и они нужны для сравнения, они не могут быть параметрами для действий, это нарушило бы семантику работы iptables.
Я уже выкладывал запись лога при правиле

-t nat -A POSTROUTING -s 192.168.1.0/28 -j LOG
Лог:
kernel: OUT=ppp0 SRC=192.168.1.2 DST=94.24.252.216 ..
Здесь четко видно что присутствует параметр OUT=ppp0 указывающий интерфейс.
Но этого человека своя правда, жаль что она противоречит фактам.
Уже сотни раз было сказано, что с этим правилом все отлично и правильно работает прямо сейчас, и это ФАКТ. А он до сих пор не понимает что это какой-то баг, и продолжает талдычить одно и тоже. Адекватный человек давно бы уже извинился и сказал бы что был неправ.

уда он уйдет, его задача проста - принять/отбросить или модифицировать пакет в соответствии с заданными критериями. Учитывая то, что iptables ничего не знает про маршрутизацию,

Теперь ему нужно снова прочитать свои слова и понять их. Точнее это мои слова только перефразированы. Но это хорошо, что он начинает что-то понимать.

Кстати мистику я уже разгадал, все пробовал, кроме перезагрузки, у компа аптайм 2 месяца. Не ожидал что поможет.
Перезагрузил, в итоге и Fedora 21 начала нормально делать masquerade. Слышишь xnt, и на Fedora 20, Fedora 21, и на домашнем шлюзе Debian Wheezy, на работе признаю что пимимо сети указываю и интерфейс. И все с тем самым твоим любимым правилом без указания интерфейса.

Постараюсь понять при каких обстоятельствах происходит такой баг. Буду держать в курсе.

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

Ты случаем пинг запускал не до того, как правило с MASQUERADE добавлял? Есть один нюанс с таблицей nat и connection tracking'ом, который, как показывает практика, знают не все.

anonymous
()
Ответ на: комментарий от demsi

Ну, в интернете можно всяких людей встретить, этот хоть на маты не исходил ;)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.