Записи с меткой ‘iptables’

Пробрасываем порты

Существует как минимум два самых известных способа пробросить порт через Linux машину.
1. iptables
2. ssh
Недавно начал использовать еще один очень просто вариант — xinetd.
Сначала поставим его: apt-get install xinetd
Теперь настраиваем произвольные порты, например:

service proxy7001
{
        disable = no
        type = UNLISTED
        socket_type = stream
        protocol = tcp
        wait = no
        bind = 127.0.0.1
        user = www-data
        redirect = 172.18.1.3 7001
        port = 7001
}

Что имеем? Локальный порт tcp 7001, который форвардится на сервер с IP 172.18.1.3 и порт 7001.

В некоторых случаях это проще и легче, чем iptables и ssh. Действуйте по ситуации. 😉

Подлость от Ростелекома

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

Проблема номер раз.
Выдают белый внешний IP в стандартной PPPoE сессии. При этом все соединения наружу идут с другого IP. Первым сломался DynDNS. Сначала подумал, что проксируют. Перенастроил соединение добавив в /etc/ppp/peer/rt.fttb строку:
unit 35
Это дало постоянное имя интерфейса ppp35 для этого соединения (у меня несколько внешних pppoe). Затем исправил /etc/ddclient.conf:
use=if, if=ppp35
Технически всё заработало, но по ssh внутрь всё равно снаружи попасть было нельзя — трафик не шел. Справедливости ради стоит заметить, что внутри Ростелекома соединения на этот белый IP шли на ура.
Поскольку аналогичная конфигурация в другой точке города работала по иному, то тщательно сравнил и нашел разницу. Оказалось дело в диапазонах белых IP адресов, которые выдавались.
Оказалось, что на каждой точке есть две железки, которые дают инет:

# pppoe-discovery -I eth1
Access-Concentrator: MX960-1
Got a cookie: 85 3d c1 4b 07 46 95 f6 3c 64 72 08 ab cd 4b f2
--------------------------------------------------
AC-Ethernet-Address: 00:25:9e:80:b5:07
Access-Concentrator: MX960-2
Got a cookie: 85 3d c1 4b 07 46 95 f6 3c 64 72 08 ab cd 4b f2
--------------------------------------------------
AC-Ethernet-Address: 00:25:9e:80:b6:08

Опытным путём выяснилось, что MX960-1 выдаёт нормальные белые адреса, а MX960-2 — недоступные.
Пишем в /etc/ppp/peers/rt.fttb:
plugin rp-pppoe.so rp_pppoe_ac 'MX960-1' eth1
и получаем всегда то что нам надо. Разумеется пока эта самая железка будет доступна. Если она пропадёт, то инета не будет вообще никакого.

Проблема номер два.
Часть сайтов стала недоступна. Закономерностей нет. Протокол значения не имеет. Даже ssh сессии начали рваться. Первая же мысль, которую я почему-то быстро отогнал, была верной — MTU.
Странно, что не провелась параллель между первой проблемой и этой.
Но в результате она решилась очень даже тривиально (хоть и с подсказки):
iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Не ожидал такого через два-то с половиной года довольно стабильной работы…

Любопытное наблюдение…

…как только закрыл iptables’ом 53 tcp порт на всех DNS серверах для всех кроме своих же серверов количество всякого бредового tcp флуда (в т.ч. http) стало почти нулевым…