Быстрый проброс портов на шлюзе во внутреннюю сеть или на другой хост. Быстро NAT’им порты. rinetd. « Debian.pro



Есть у меня статейка про то, как NAT’ить отдельные порты на другую машину. Как-то я её написал и забыл. А на самом деле использую утилиту rinetd. Во-первых проще, во-вторых утилита — отдельный демон и работает шустрее iptables. Минус в однопоточности. DDoS в 100к pps такой штукой отмаршрутизировать ещё можно, но дальше начнутся проблемы. С другой стороны, там, где летает 100к пакетов в секунду и iptables будет задумчиво перекидывать пакеты (хоть и в несколько потоков).

Через rinetd нельзя пробросить FTP, не пытайтесь.

Применимо, опять же, в тех же случаях, что и /375

1) на шлюзе домашней/мелкой корпоративной сети можно пробросить порт на IP из серой подсети.2) ваш веб-сервер переехал целиком на другой IP (сервер новый купили, например), а DNS записи ещё не поменялись3) вам просто нужно пробросить трафик, летящий на определенный порт на другую машинку.

Ограничения и проблемы те же:

1) трафик проходит через шлюз в обе стороны (от отправителя к шлюзу, от шлюза к получателю, от получателя к шлюзу, от шлюза к отправителю). Аккуратнее с полосой и оплатой за трафик2) получатель пакета получит его с source-ip вашего шлюза. То есть узнать реальный IP клиента из заголовков TCP нельзя. Так что такой способ не подходит для того, чтобы быстренько сервер с FreeBSD своей стойкой грудью закрыл Linux-сервер (хотя, если IP посетителей вам не важны… А статистику собираете через Google Analitycs или Метрику — то пожалуйста =) ). С ipfw намного легче отбить ddos (особенно в случае, если отбиваем не сам сервер, а стоящий за ним хост) из-за совершенно другой логики работы.

  Проблема с монтирование диска - загрузка в emergency mode (Страница 1) — Кросс-дистрибутивные вопросы — Linux Forum

Ну ладно, чего-то я разговорился. Я уже писал, что всё делается не просто, а очень просто?

У нас есть:1) хост 8.8.8.8, старый вебсервер (офисный).2) хост 4.4.4.4, новый вебсервер (в дц, например). На него нужно перенаправить https и http трафик (443, 80й порты) со старого.3) за машиной с IP 8.8.8.8 — корпоративная «серая» подсеть. У машины на внутренней сетевой карте — IP 192.168.0.1, остальные машины в сети получают IP из подсети 192.168.0.1/24.4) машина в серой подсети с IP адресом 192.168.0.2, по этому IP адресу она доступна с машины из пункта 3. Её ssh и вебсервер нужно пробросить наружу.

Само собой, мы не можем сделать пункт 4й в лоб. SSH серой машины мы повесим на 222й порт внешнего IP, а вебсервер — на 8080.

Ставим сам rinetd:

root@gateway:~# aptitude install rinetd

Открываем его конфиг:

root@gateway:~# nano /etc/rinetd.conf И пишем туда следующее: # разрешим всем ходить по редиректам (и вообще цепляться к портам): allow *.*.*.* # перенаправление http трафика с 8.8.8.8 на 4.4.4.4: 8.8.8.8 80   4.4.4.4 80 # перенаправление https трафика с 8.8.8.8 на 4.4.4.4: 8.8.8.8 443   4.4.4.4 443 # пробрасываем ssh с серой машины наружу: 8.8.8.8 222   192.168.0.2 22 # пробрасываем web-сервер с серой машины наружу: 8.8.8.8 8080   192.168.0.2 80

На всякий случай поясню:

— 1й столбик — IP, который слушает rinetd- 2й столбик — порт, который слушает rinetd- 3й столбик — IP, на который перенаправляем трафик- 4й столбик — порт, на который перенаправляем трафик с порта из второго столбика.

  Как сменить железо, не переустанавливая windows? :: RuTracker.org (ex torrents.ru)

Правил может быть сколько угодно (65к я не вбивал, но, думаю, справится).

В первый столбик нельзя вписывать IP, не принадлежащий машине (не поднятый на интерфейсах), иначе rinted не запустится. Точнее запустится, но будет дропать коннекты и спамить в логи.

Лог пишется в /var/log/rinetd.log, посматривайте сколько он места занимает — может расти достаточно быстро, если есть какие-либо проблемы.

После правки конфига следует перезапускать rinetd командой:

root@gateway:~# /etc/init.d/rinetd restart

Быстрый проброс портов на шлюзе во внутреннюю сеть или на другой хост. Быстро NAT’им порты. rinetd.

Губарь Маргарита Александровна