LINUX.ORG.RU

Сообщения firstcalled

 

iptables nat

Здравствуйте, товарищи!

Надеюсь лишь на наше рабочее движение!

В общем, ситуация такая
Компьютер А
(eth0)ip=10.31.86.2/24, default gw=10.31.86.1

Компьютер B
(eth0)ip=192.168.0.106/24, default gw=192.168.0.101
(eth1)ip=10.30.139.2/24, gw=none

Компьютер С(маршрутизатор + nat, ОС Debian 8.1)
(eth0)ip=192.168.0.102/24, gw=none
(eth2)ip=10.30.139.102/24, default gw=10.30.139.1
Содержимое rc.local
iptables -A INPUT -j ACCEPT
iptables -A OUTPUT -j ACCEPT
iptables -A FORWARD -j ACCEPT
iptables -t nat -A POSTROUTING -o eth2 -s 192.168.0.0/24 -j SNAT --to-source 10.30.139.102
rc.local ошибок не содержит, судя по логу.

Сеть 10.31.86.0/24 и 10.30.139.0/24 видят друг друга.

Теперь сама проблема: мне нужно по RDP с А подключиться к B. A видит напрямую B, но B не может передать ответ по eth1(10.30.139.0/24), B может ответить через маршрутизатор C. C, получая пакеты от B, делает nat и переправляет пакеты дальше. Все работает, и да, я понимаю, что так не должно быть, но сейчас ничего не могу поделать и не могу спрятать B за маршрутизатор целиком и делать портфорвардинг и тд, вот так вот тут все работает, но суть не в этом. Проблема моя заключается в том, что работает это все лишь в том случае, если iptables -t nat -A POSTROUTING -o eth2 -s 192.168.0.0/24 -j SNAT --to-source 10.30.139.102 содержит именно -s 192.168.0.0/24, хотя по идее все должно работать и просто с -o eth2. Вот это я и не могу понять, почему обязательно нужно указывать -s в данной ситуации? Если я убираю -s 192.168.0.0/24, то все машины из сети 192.168.0.0/24 отлично выходят в инет, но вот машины из других сетей, как машина A(10.31.86.2/32) никак не может подключиться к B(10.30.139.2/32). Куда копать, товарищи?

 ,

firstcalled
()

Debian 8.1, white screen

Здравствуйте! Проблема такая: После загрузки ОС экран становится белым. Порой присутствуют артефакты в виде полос, ну не суть. В общем, ничего не понятно, но если подождать пока экран потемнеет, то есть отключится и нажать любую клавишу, то экран загорается и все отлично видно, меню с выбором пользователя и тд и тд, можно залогиниться, войти и работать нормально. Но если сделать log out, то опять белый экран. Снова ждем, пока отключается дисплей, снова нажимаем клавишу и опять все видно. Теперь по тому, что есть в наличии:

  • ОС: linux Debian 8.1
  • ноутбук Samsung R40 с видео ATi Express 200m.

Что я уже пробовал:

  • Разные «рабочие столы»: GNM3, KDE, Xfce
  • Установка firmware-linux-nonfree, libgl1-mesa-dri, xserver-xorg-video-ati пакетов.
  • Чтение логов Xorg, ошибок не обнаружено.
  • dmesg | grep -E 'drm|radeon' | grep -iE 'firmware|microcode' Ошибок загрузки нужный файлов тоже нет.

куда еще можно копать, господа?

 

firstcalled
()

tc, iptables, IMQ vs IFB, Винни Пух и все-все-все.

День добрый! Сразу скажу, в linux новичок, поэтому прошу говорить попроще, использовать стандартную терминологию, желательно на английском, чтобы я мог загуглить и узнать, о чем вы ведете речь. А теперь сама проблема: Решил я взяться за управление трафиком под Лиункс, выбрал Debian. Хочу такое: есть 10мбит на выход, есть 10 пользователей. Если один только активно работает, то получает все 10мбит. Если двое работают, то по 5. Если трое, то по 3.3. Ну и тд.

Нашел, что за это отвечает tc, а в нем qdisc и разные классы, в нашем случае HTB как основной. Примерно понятна общая идея. Потом дошел до момента, где мне сказали, что эти все плюшки приятные с классами и прочим для шейпинга мы можем использовать только для outbound трафика. А как же inbound? Ок, и для этого у них есть решения, это или использование IMQ или использование IFB. И тут сразу два вопроса,
- первый, есть ли какой-то другой способ шейпинга входящего трафика? Нужен именно шейпинг, просто метод drop не подходит, да, мы сможем ограничить входящий трафик, но получится не комильфо, когда канал свободен, а использоваться будет лишь на какой-то процент. Я не жадный, хочет человек скачать фильм, пусть качает, главное - не в ущерб всем.
- второй вопрос, что же выбрать? IMQ или IFB? Ясно, что и там и там свои плюсы и минусы. Как я лично их вижу:
 — IMQ —
минусы:
- необходимость патчить ядро и iptables. Сразу скажу, как это делать, я не знаю, но научусь, куда денусь. Но патчить их каждый раз, когда обновляешь ядро? Не слишком ли большой геммор? Да и ждать, пока выйдет новый патч от IMQ под ядро...Или я тут кошмарю и ядра обновляются не так часто?
 — IFB —
минусы:
- плохо работает с NAT на одной машине, в нете я видел предложения разнести NAT и шейпинг, но у меня будет лишь один системник и слава Богу, что он еще есть. Может я что-то понял не так и IFB вполне можно подружить с NAT?
- отсутствие вменяемой документации. Рыть сырцы я пока просто не смогу, поэтому нужен нормальный ресурс, освещающий использование IFB.

Конечно, хотелось бы не париться с патчами, а сразу использовать IFB, раз он уже есть в ядре, но эта проблема с NAT все портит. В общем жду ваших ответов и комментариев! Напомню еще раз, новичок я, поэтому попроще и активную лексику на английском, please. Thanks in advance!

 , , ,

firstcalled
()

RSS подписка на новые темы