LinuxForum.Fans
Тема

Проблема с использованием NAT

Автор: ShoTo 31 сообщений 9367 просмотров
#275386

Столкнулся с проблемой открытия некоторых сайтов. В качестве домашнего роутера используется сервер под управлением Debian.
Имеется две сетевые карты, их интерфейсы:
eth0 - интернет-провайдер (10.0.0.0/8, DHCP)
eth1 - домашняя локальная сеть (192.168.1.0/24)

Поднято vpn-соединение с помощью pptp-linux. При поднятии VPN-туннеля появляется интерфейс:
ppp0 - выдается статический адрес провайдером

На сервере поднято ПО: dhcp3-server, dnsmasq, pptp-linux.

Раздаю интернет на домашние машины с помощью тестовых правил iptables:

text
iptables -F
iptables -t nat -F
iptables -t mangle -F

iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j MASQUERADE

На локальной машине получаю:

text
DHCP включен. . . . . . . . . . . : Да
Автонастройка включена. . . . . . : Да
IPv4-адрес. . . . . . . . . . . . : 192.168.1.2(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . . : 192.168.1.1
DHCP-сервер. . . . . . . . . . . : 192.168.1.1
DNS-серверы. . . . . . . . . . . : 192.168.1.1

Проблема заключается в том, что при открытии некоторых сайтов получаю не до конца загруженную веб-страницу, особенно заметно, когда на сайтах используются внешние js-скрипты. Чтобы стало понятно, что имеется ввиду, привожу скриншот:

На этот этапе загрузка страницы останавливается, хотя ssl.google-analytics.com пингуется отлично на обоих машинах. Если подключиться к vpn-серверу на локальной машине, то такой проблемы уже нет. Уже и не знаю, куда копать дальше...

#275388

Вот попробуйте это

#275389

kisil, спасибо Вам большое! Я даже и подумать на это не мог! Потратил на это кучу времени, как и автор в приведенной выше ссылке, а все из-за того, что MTU PPTP соединения автоматически устанавливалось в 1400.
Проблему решил, добавив правило в iptables:

text
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 
#275390

Незачто пусть работает. Удачи.

#275607

Столкнулся с новой проблемой... При включении торрент-клиента на локальной машине, падает интернет, видимо из-за большого количества соединений. Отключение и подключение к vpn не помогают, только ребут сервера.

#275610

Есть такая зараза но ещё руки не дошли.

#275611

А если вместо pptp-linux использовать accel-pptp? Или это проблема не в pptp-linux?

#275625

Интернету нету тока на машыне которая стоит за шлюзом, а если сделать переконэкт нет на слюзе появляетса???
Когда инет пропадает то шлюз пингуетса с локального хоста?

#275641

Интернета нет как на локальных машинах, так и на шлюзе. Интерфейс при этом ppp0 сохраняется. С локальной машины можно спокойно достучаться до сервера, даже зайти по ssh. Если сделать poff, а затем pon <имя>, то интернет снова появляется и пропадает только во время запущенного торрент-клиента. Если в настройках торрент-клиента уменьшить количество активных соединений, то интернет не обрывается.

#275663

падает сетевая которая смотрит в сеть провайдера. accel-pptp пробуйте куда интереснее по тестам.

#275670

Сетевая карта не падает - это 100%, потому что после падения интернета локальные ресурсы провайдера доступны как на локальной машине, так и на сервере.

#275680

Торрент клиент похож чем-то на ддос атаку (утрирую)... Кстати можно и с помощью iptables резать кол-во активных соединений... :)

#275687

Очень странно... Раньше, когда был роутер Asus RT-N12 с томатовской прошивкой, таких проблем не было. Проблема была в том, что он резал трафик, поскольку не справлялся с потоком, и в том, что он отказался запускаться на повышенной частоте и после этого перестал работать. Поэтому и пришлось собрать свой роутер на базе intel atom.
Кстати, запущена всего 1 активная закачка с максимальным количеством пиров в 200 штук.

#275691

Запретить новые коннекты (убрать NEW из строк NEW,ESTABILESHED,CONNECTED в правилах iptables), и разрешить для торрентов только определенные порты.
В этой теме (где-то в конце) обсуждали кое-что про торренты.

#275696

Если убрать NEW, то у меня не подключается к впн вообще... В торрент-клиенте стоит разрешенный порт.

Мои правила iptables:

text
#!/bin/bash

# Объявление переменных export IPT="iptables"

# Интерфейс который смотрит в интернет export WAN=ppp0

# Локальная сеть export LAN=br0 export LAN_IP_RANGE=192.168.1.0/24

# Очистка всех цепочек iptables $IPT -F $IPT -F -t nat $IPT -F -t mangle $IPT -X $IPT -t nat -X $IPT -t mangle -X

# Закрываем изначально ВСЁ (т.е. изначально все что не разрешено - запрещено): $IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP

# разрешаем локальный траффик для loopback и внутренней сети $IPT -A INPUT -i lo -j ACCEPT $IPT -A INPUT -i $LAN -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT $IPT -A OUTPUT -o $LAN -j ACCEPT

# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении. # Пропускать все уже инициированные соединения, а также дочерние от них $IPT -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT # Пропускать новые, а так же уже инициированные и их дочерние соединения $IPT -A OUTPUT -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # Разрешить форвардинг для новых, а так же уже инициированных и их дочерних соединений $IPT -A FORWARD -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# Включаем фрагментацию пакетов. Необходимо из за разных значений MTU $IPT -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Отбрасывать все пакеты, которые не могут быть идентифицированы и поэтому не могут иметь определенного статуса. $IPT -A INPUT -m state --state INVALID -j DROP $IPT -A FORWARD -m state --state INVALID -j DROP

# Приводит к связыванию системных ресурсов, так что реальный обмен данными становится не возможным. $IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP $IPT -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP

# Разрешаем доступ из внутренней сети наружу $IPT -A FORWARD -i $LAN -o $WAN -j ACCEPT

# Запрещаем доступ снаружи во внутреннюю сеть $IPT -A FORWARD -i $WAN -o $LAN -j REJECT

# Маскарадинг $IPT -t nat -A POSTROUTING -o $WAN -s $LAN_IP_RANGE -j MASQUERADE $IPT -t nat -A POSTROUTING -o eth0 -s $LAN_IP_RANGE -j MASQUERADE

# Далее дано как пример открытие портов извне: # ********************************************************************** # Открываем порт для ssh $IPT -A INPUT -i $WAN -p tcp --dport 22 -m recent --name ssh --update --seconds 3600 --hitcount 4 -j REJECT $IPT -A INPUT -i $WAN -p tcp --dport 22 -m recent --name ssh --set $IPT -A INPUT -i $WAN -p tcp --dport 22 -m recent --name ssh ! --rcheck --seconds 30 --hitcount 2 -j REJECT $IPT -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT

# Открытие портов для торрентов (такие же указать в torrent-клиенте) $IPT -A INPUT -i $WAN -p tcp -m multiport --ports 50100:51100 -j ACCEPT

/var/log/syslog

text
Sep 19 19:43:40 debian pppd[2789]: Connection terminated.
Sep 19 19:43:41 debian pptp[3205]: anon warn[decaps_hdlc:pptp_gre.c:204]: short read (-1): Input/output error
Sep 19 19:43:41 debian pptp[3205]: anon warn[decaps_hdlc:pptp_gre.c:216]: pppd may have shutdown, see pppd log
Sep 19 19:43:41 debian pptp[3213]: anon log[callmgr_main:pptp_callmgr.c:234]: Closing connection (unhandled)
Sep 19 19:43:41 debian pptp[3213]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Sep 19 19:43:41 debian pptp[3213]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
Sep 19 19:43:43 debian pptp[3186]: anon log[decaps_gre:pptp_gre.c:405]: discarding duplicate or old packet 11 (expecting 450656)
...
Sep 19 19:43:58 debian pptp[2850]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 675893 (expecting 675892, lost or reordered)
...
Sep 19 19:43:58 debian rsyslogd-2177: imuxsock begins to drop messages from pid 2850 due to rate-limiting
Sep 19 19:43:58 debian pppd[2832]: LCP: timeout sending Config-Requests
Sep 19 19:43:58 debian pppd[2832]: Connection terminated.
Sep 19 19:43:58 debian pppd[2832]: Modem hangup
Sep 19 19:43:58 debian pptp[3186]: anon warn[decaps_hdlc:pptp_gre.c:204]: short read (-1): Input/output error
Sep 19 19:43:58 debian pptp[3186]: anon warn[decaps_hdlc:pptp_gre.c:216]: pppd may have shutdown, see pppd log
Sep 19 19:43:58 debian pptp[3195]: anon log[callmgr_main:pptp_callmgr.c:234]: Closing connection (unhandled)
Sep 19 19:43:58 debian pptp[3195]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Sep 19 19:43:58 debian pptp[3195]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
Sep 19 19:44:04 debian rsyslogd-2177: imuxsock lost 2081 messages from pid 2850 due to rate-limiting
Sep 19 19:44:04 debian pptp[2850]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 678175 (expecting 676191)
#275698
"ShoTo" написал:
Если убрать NEW, то у меня не подключается к впн вообще...

Кто бы сомневался, порты не только торенам и ssh открывать надо.

#275756

Тогда получится слишком большая таблица правил, если открывать для всех остальных исходящих соединений. Другого решения проблемы никакого нету? Еще хотя бы понять из-за чего такое происходит...

#275757
"ShoTo" написал:
Тогда получится слишком большая таблица правил,

Открыть десяток портов это много? Ерунда какая...

"ShoTo" написал:
Еще хотя бы понять из-за чего такое происходит...

вот пример скрипта, добавь нужные порты и все, еще, еще ...
Тему на которую ссылку дал внимательно изучи, должно полегчать.
Поиск по форуму даст много полезного.

#275766

Прочитал все темы по приведенным Вами ссылкам. Вы советуете убрать NEW из правил, но как быть, если локальным машинам может понадобится любой порт для исходящего соединения? Решения проблемы тогда нету получается?

#275775
"ShoTo" написал:
локальным машинам может понадобится любой порт для исходящего соединения?

Тут разговор про шлюз, а не про локальные машины, и это firewall все таки, и на нем разрешает что-то админ, надо открыть, пожалуйста открывай хоть все, надо порты пробросить тоже самое.

"ShoTo" написал:
Решения проблемы тогда нету получается?

Какого решения? Какой проблемы?

Войдите или зарегистрируйтесь, чтобы ответить.