проблема masquerading
Подключаю я ноутбук по имени sputnik (EEE, Debian Squeeze) к интернету, используя компьютер (по имени theorie13, Debian lenny) с двумя сетевыми картами в качестве шлюза. Вот файл /etc/network/interfaces на theorie13:
auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet dhcp
allow-hotplug eth1
iface eth1 inet static
address 192.168.42.3
netmask 255.255.255.0А вот вывод команды ip route show на theorie13:
192.168.42.0/24 dev eth1 proto kernel scope link src 192.168.42.3 128.206.124.0/23 dev eth0 proto kernel scope link src 128.206.124.254 default via 128.206.125.254 dev eth0
<-- откуда следует, что theorie13 использует 128.206.125.254 в качестве gateway.
Проблема в том, что этот самый gateway -- самый удалённый компьютер, до которого я могу допинговаться со sputnik. Помогите, пожалуйста, разобраться и вылечить(ся).
ЗЫ: masquerading я делал разными способами, в т.ч. используя shorewall.
Другой способ
iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -i ! eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o eth
Что ни делай -- результат один: дальше 128.206.125.254 sputnik'у заходить не разрешают. На theorie13 никаких проблем. Вот файл /etc/network/interfaces на sputnik:
auto lo ath0 iface lo inet loopback iface mu inet dhcp iface mu2 inet static address 192.168.42.2 netmask 255.255.255.0 gateway 192.168.42.3 nameserver 128.206.10.3
# <-- включается командой ifup eth0=mu2
- 4094 просмотра
Страница для печати
раз ты видишь 128.206.125.254 со sputnik значит все работает. Вполне возможно, что твой провайдер специально отсекает пакеты которые идут от дополнительных компов через один подключенный в сеть. Они могут это делать по TTL. чтобы справиться с этим тебе необходимо добавить следующее правило
iptables -t mangle -A POSTROUTING -i eth1 -o eth0 -j TTL --ttl-inc 1
рекоммендую все же пользоваться MASQUARADE, так как этот интерфейс у тебя под управлением dhcp
ну и в любом случае, обязательно воспользуйся tcpdump чтобы убедиться в правильности или увидеть возможную проблему. Например, пингуй некоторый хост в мире со sputnik и смотри трейс на свoем роутере
theorie13: tcpdump -ni any host ya.ru or port 53
sputnik: ping ya.ru
ты должен увидеть запросы на днс (проверь, что они ходят), после пакет от sputnik к ya.ru. во всез случаях пакеты будут идти по схеме sputnik -> dest (eth1); theorie -> dest (eth0 : masq); dest -> theorie (eth0); dest -> sputnik (eth1: masq)
Спасибо за ответ!
Узнал, хоть, что такое TTL.
Команда
iptables -t mangle -A POSTROUTING -i eth1 -o eth0 -j TTL --ttl-inc 1
выдаёт сообщение об ошибке
iptables v1.4.2: Can't use -i with POSTROUTING
Я попробовал команду
iptables -t mangle -A POSTROUTING -j TTL -o eth0 --ttl-set 63
на theorie13 -- всё заработало, пропинговал яндекс, потом скопировал на sputnik
/etc/resolv.conf
с theorie13 и стали распознаваться имена серверов.
Правда, потом я смеху ради скомандовал на theorie13
iptables -t mangle -F
Казалось бы после этой команды всё должно перестать работать, но нет -- всё работает.
Теперь я уже сомневаюсь: была ли вообще проблема, на которую я вчера потратил почти день?
Я не сильно в iptables разбираюсь, но тут мне не понятно что за FORWARD?
Я сильно подозреваю что у тебя перебрасываются пакеты на другой интерфейс, не проходя собственно маскарадинг (поэтому дальний гейт и не пускает). Может попробуешь попроще?
1. Включить роутинг на theorie3
2. Убрать эти FORWARD. Я обычно делаю не маскарадинг, а SNAT (что тоже самое, только привязка к IP, а не к интерфейсу). Где то так:
Я в iptables не разбираюсь почти совсем.
Сегодня для шлюзования использовалась shorewall -- уверен, она делает это кошерно.
Проблема была точно не в выключенном /proc/sys/net/ipv4/ip_forward
Вроде бы рассосалось.
Спасибо!
Отправить комментарий