madwimax+iptables+dhcp

Хочу рассказать о своем опыте настройки раздачи интернета от yota модема во внутреннюю сеть.
Сетевой интерфейс, смотрящий на внутреннюю сеть – eth1, yota – wimax0
Драйвер для yota модема – madwimax.
Замечательная вещь, спасибо большое Александру Гордееву и остальным разработчикам.

Система – debian sid

DHCP:
/etc/dhcp3/dhcpd.conf: (наиболее важное)

INTERFACES=”eth1″;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.3 192.168.0.254;
option routers 192.168.0.1;
option domain-name-servers 94.25.208.74, 94.25.128.74;
}

IP-адреса 94.25.208.74, 94.25.128.74 – это адреса DNS провайдера

с этим проблем особо не было.

iptables:
с iptables у меня сложилось помучительней
вот вывод правил (iptables-save):

# Generated by iptables-save v1.4.3.2 on Wed May 6 23:22:16 2009
*mangle
:PREROUTING ACCEPT [3477:1950301]
:INPUT ACCEPT [1711:1300514]
:FORWARD ACCEPT [1760:649324]
:OUTPUT ACCEPT [1783:234934]
:POSTROUTING ACCEPT [3543:884258]
-A POSTROUTING -o wimax0 -p tcp -m tcp –tcp-flags SYN,RST SYN -j TCPMSS –clamp-mss-to-pmtu
COMMIT
# Completed on Wed May 6 23:22:16 2009
# Generated by iptables-save v1.4.3.2 on Wed May 6 23:22:16 2009
*filter
:INPUT ACCEPT [8:1026]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1783:234934]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
-A INPUT ! -i wimax0 -m state –state NEW -j ACCEPT
-A FORWARD -i wimax0 -o eth1 -m state –state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o wimax0 -j ACCEPT
-A FORWARD -i wimax0 -o wimax0 -j REJECT –reject-with icmp-port-unreachable
COMMIT
# Completed on Wed May 6 23:22:16 2009
# Generated by iptables-save v1.4.3.2 on Wed May 6 23:22:16 2009
*nat
:PREROUTING ACCEPT [354:25282]
:POSTROUTING ACCEPT [22:1488]
:OUTPUT ACCEPT [214:13312]
-A POSTROUTING -o wimax0 -j MASQUERADE
COMMIT
# Completed on Wed May 6 23:22:16 2009

/etc/init.d/iptables:
#!/bin/bash
iptables-restore /etc/firewall.conf

создал софт-линк этого файла на /etc/rc.2d/S21iptables

madwimax (yota):
у меня модем поднимается так:

/etc/init.d/start_wimax.sh:
#!/bin/bash
/usr/local/madwimax/sbin/madwimax -d -l /var/log/madwimax.

-d: “демонизироваться”.
-l: путь для лог-файла. У меня модем достаточно сильно забивает syslog и видеть все это на косоли не очень приятно))

на /etc/rc.2/S20wimax повесил софт-линк на вышеуказанный файл.

Таким образом при запуске сначала запускается madwimax, затем iptables обновляет правила.

Вообще-то лучше написать правило для udev-a, чтобы драйвер сам запускался при подсоединения модема,
чем скоро я и займусь=)

Проблема с Path MTU Discovery Black Hole:
Я столкнулся с тем, что некоторые сайты не работали во внутренней сети.
Достаточно скоро я с этим разобрался.

Вот что мне помогло:
http://www.opennet.ru/base/net/pppoe_mtu.txt.html

$ ifconfig wimax0

wimax0 Link encap:Ethernet HWaddr 00:21:d2:1e:77:3c
inet addr:10.130.31.12 Bcast:10.130.31.255 Mask:255.255.224.0
inet6 addr: fe80::221:d2ff:fe1e:773c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1386 Metric:1
RX packets:23188 errors:0 dropped:0 overruns:0 frame:0
TX packets:26921 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:17312996 (16.5 MiB) TX bytes:3682732 (3.5 MiB)

Как видим, wimax0 соединение имеет MTU 1386. Что по сути это означает?
Проще говоря, ваше соединение с интернет имеет окно в 1386 байт (MTU -
Maximim Transmission Unit) – это наибольший пакет, который ваша машина
может передать по данному соединению. В тоже время, почти все веб и
ftp серверы соединены с интернет с MTU 1500.

Если где-нибудь на пути пакета от одного хоста к другому выяснится,
что он не умещается в MTU следующего участка, то роутер будет фрагментировать
данный пакет. Так произошло бы, если бы роутеры не использовали технологию Path MTU Discovery.

Фрагментация существенно замедляет скорость передачи.

Суть технологии состоит в том, что когда два хоста соединяются друг с
другом, то устанавливается DF бит “Dont Fragment”), который запрещает
фрагментацию пакетов на роутерах.
Это заставляет роутер, который собирается перенаправить пакет через
соединение с MTU меньше размера пакета, отбрасывать пакеты и
отправлять хосту-отправителю сообщение типа ICMP 3:4. Данное сообщение
типа “Destination is unreachable” означает “Хост недоступен, поскольку
пакет слишком большой и роутер не будет его фрагментировать”. В
добавлении к данному сообщению, при применении PMTUD, прилагается
размер MTU нижестоящего за роутером участка. Таким образом,
хост-отправитель, после получения ICMP 3:4 с информацией от PMTUD,
уменьшает размер отправляемого пакета и пересылает его заново. Как
итог — пакеты доходят до хоста-получателя без фрагментации.

Все операционные системы с 1988 года поддерживают технологию PMTUD.
Однако, проблема может быть в том, что либо вышестоящий над вашим
соединением роутер, либо некий роутер между вами и удаленным сервером,
либо сам удаленный веб-сервер могут БЛОКИРОВАТЬ некоторые типы ICMP
пакетов, включая ICMP 3:4. Как итог – соединение между хостами устанавливается,
но пакеты от одного хоста к другому не доставляются, отбрасяваясь где-то по
пути… Похоже на наши симптомы?

Пришлось добавить
iptables -t mangle -A POSTROUTING -p tcp –tcp-flags SYN,RST SYN -o wimax0 -j TCPMSS –clamp-mss-to-pmtu

Это правило просто отключает бит DF.
Надо бы еще попробовать скорректировать размер MSS, но пока руки не доходят.

Вот собственно и все.