Линуксаводы!

Если я правильно понял то у тебя трафик идет через squid, следовательно ему и нужно подсовывать DNS-ы

 

Если доходчиво ответиш, нафейхуа сквид при современных скоростях и анлиме, то я отвечу на остальные твои вопросы.

 

nslookup - тестирование днс, есть в любой ОС. К слову сказать - как подсовывали ДНС? Тест ошибки приведите в браузере (ну тупо номер).

Включите запись логов уровня critical в ppp клиенте. Он может много чего любопытного там вам понаписать.

Для некоторых сетей менее геморойно использовать mpd заместо штатных средств установки соединений. Хотя судя по стартопику количество геморроя волнует вас в последнюю очередь...))

 

icefrog, Через сквид не может идти весь трафик. оно не для того создавалось. dns запросы уж точно не через него.
А вот правила iptables на "сервере" видимо хромают.

 

шлюз резолвить не надо - он везде записан как IP.
nslookup поможет отресолвить ИМЕНА. То есть после запуска этой утильки она вам подбросит командную строчку и список серверов которые будет использовать. Ей надо тупо скормить несколько имен сайтов в интернете, и посмотреть - выдаст ли она их IP. Если выдаст - значит все в порядке с днс.

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

 

Без конфигов говорить не о чем. А статей как настроить шлюз на линупсе в сети море.
Продавать нельзя. Для этого должна быть лицензия на телематику+передачу данных и сдан узел связи. Иначе вздрючат.
Продавать услугу с проксиком вообще бред. Обычный NAT и в путь.

 

Возможно, вам пригодиится такая утилитка как tracert (Windows) или traceroute в линупсе.

Вот пример использования:

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

Логично.

Тут простая последовательность:
1. проверить доступность сервера ДНС (на стороне провайдера )пингом по IP.
2. Запустить nslookup и посмотреть сервер которым пользуеться браузер для ресолва:

3. Скормить nslookup имя проблемного узла и посмотреть ответ:

если нет ответа, попробовать попросить адрес проблемного узла у другого сервера ДНС, выше того которым пользуетесь, по иерархииуказав его утилите nslookup командой server <ip_addr_upper_dns>),

если ответа нет, попробывать сервер днс гугла (8.8.8.8).
Если и он не отвечает, значит между вами и другими днс, есть узел (включая ваш собственный компьютер), на котором действуют ограничения фильтра пакетов, включающие запрет открытия соединений на 53 порт. тоессть в вашем случае это иптаблес.


Если все ресолвится как надо. То трасерт в руки, как написано выше.

---------- Сообщение добавлено 05.05.2013 22:02 ----------

если вы хотите интернет в складчину, то учтите что любой отказ или тормоза лягут на вашу совесть, а не на совесть провайдера. В этом случае намного эффективнее упростить организацию процесса на вашей стороне, чтобы не вносить лишних шансов на отказ связи.

На вашем месте я бы поставил роутер обычный (меньше кушает электричества, надежнее домашнего компьютера), а зону покрытия обеспечил бы точками доступа в режиме повторителей

Если ваш сосед не заплатит вовремя, прикройте ему доступ через пакетный фильтр роутера. Если соседей много, то есть вариант немного автоматизировать этот процесс.

---------- Сообщение добавлено 05.05.2013 22:08 ----------

Купите другой, роутер с вайфаем счас можно рублей за 700-900 купить. Эти затраты быстро окупятся свободным временем освободившимся от ковыряний с прошивками, даже в том случае, если ваша проблема на том оборудовании которое уже есть, имеет решение с помощью напильника и такой то матери.

---------- Сообщение добавлено 05.05.2013 22:15 ----------

хм, а кто у вас провайдер? помоему сейчас лимит у проводных сетей уже ушел в прошлое.

 

электрик, понятное дело что не может, но человек явно тестирует работоспособность по 80 порту.

 

пингуй по цепочке, попробуй шлюз по-умолчанию попинговать.
проверь еще раз нат, в иптаблес

 

Если L2TP настроен правильно, то
sudo -i
apt-get install unbound
nano /etc/squid3/squid.conf
найти dns_nameservers, прописать там 127.0.0.1

PS. электрик, squid - для контроля.

 

без лицензии - незаконная предпринимательская деятельность вообще-то

 

ты бы весь список вывел правил.

Вообще говоря из указаной цепочки второе правило не совсем логичное, вместо него стоит использовать конструкцию которая разрешает обмен пакетами по уже установленным соединениям. примерно так: iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Надо сказать, я сталкивался на работе с pf и ipfw, там язык правил более понятный и ясный. Потому что практически человечий.

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

 

Ну никакой девайс провайдера не обязан отвечать по icmp
Провайдер волен роутить пакеты так, как считает нужным
Возьмите листок и карандаш. Разрисуйте схемотично как куда у вас ходят пакеты. Думаю наступит просветление. Опять же по DENY правилам внимательнее.
Прислушайтесь к openboy по поводу установленных соединений.

 

а вот тут вы зря...)

---------- Сообщение добавлено 12.05.2013 10:47 ----------

отключите совсем, будет ясно

 

Покажите правила полностью.
И ifconfig

---------- Сообщение добавлено 13.05.2013 09:49 ----------

Вернитесь на землю. На клиентах то MTU зачем трогать?

 

+1

А вообще, прежде чем навешивать запрещающие правила и фильтры, сделай чтобы форвард нормально заработал.

iptables --policy INPUT ACCEPT
iptables --policy OUTPUT ACCEPT
iptables --policy FORWARD DROP

iptables --flush
iptables -A FORWARD -s $LAN_IP_RANGE -o $INET_IFACE -j ACCEPT
iptables -A FORWARD -i $INET_IFACE -d $LAN_IP_RANGE -j ACCEPT

iptables -t nat --flush
iptables -t nat -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t nat -A POSTROUTING -s $LAN_IP_RANGE -j MASQUERADE

Как-то так. TCPMSS должно помочь с MTU без подкручивания оного вручную.