nixp.ru v3.0

28 марта 2024,
четверг,
11:59:37 MSK

Аватар пользователя Zarg
Zarg написал 26 июня 2004 года в 17:07 (1390 просмотров) Ведет себя как мужчина; открыл 73 темы в форуме, оставил 120 комментариев на сайте.

Squid выдает в логах следующее:

2004/06/26 16:50:37| comm_udp_sendto: FD 4, 194.67.1.154, port 53: (65) No route to host

2004/06/26 16:50:37| idnsSendQuery: FD 4: sendto: (65) No route to host

У меня стоит ipfw на FreeBSD, разрешено все по lo0, разрешены 20,21,25,110,53,80 по ppp0. Так вот если по ppp0 разрешить все, то в логах прокси такой ерунды нет.

На сколько я понял сквиду нужны какие то разрешенные порты, какие я незнаю.

Если используется FreeBSD с ppp, то все это, как правило нафиг не нужно, потому что придется куртить кучу динамических правил keep-state — check-state. Самое грамотное решение — воспользоваться для установки ppp соединения утилиту ppp. В ней можно настроить запрет входящих соединений извне, что чаще всего и надо для диалапа. Тогда все динамические правила создаются автоматом (там используется nat). Настраивать так:

/etc/ppp/ppp.conf

<— cut —>

#Секция default

nat enable yes # включить NAT

nat deny_incoming yes # запретить входящие соединения (очень полезная штука и не только для параноиков)

nat use_sockets yes # открывать сокеты для входящих соединений при установлении нами сессий с внешними серверами, например,

nat same_ports yes # использовать по возможности оригинальные номера портов

# Можно делать редирект TCP или UDP на любой хост/порт

# если раскомментировать следующие строки, то можно

#nat port tcp webserver:80 80 # сделать доступным извне наш внутренний www сервер

#nat port tcp ftpserver:21 21 # сделать доступным извне наш внутренний ftp

set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 # интерфейс должен иметь хотябы фиктивный IP чтобы можно было добавить его в таб

add default HISADDR # добавление маршрута по умолчанию

set filter dial 0 permit 0 0 tcp syn # это для режима «-auto» устанавливать соединение по приходу на интерфейс TCP пакетов

# с флагом SYN (TCP коннект), «0 0» — значит c любого адреса на любой

set filter dial 1 permit 0 0 udp dst eq 53 # это то же, но для DNS

set filter alive 0 permit 0 0 tcp estab # держать связь до тех пор пока еще ходят пакеты уже установленных TCP соединений,

# игнорировать все кроме них и не поддаваться на провокации типа «ping -t www.mail.ru»

inet: # метка секции

enable lqr # Link Quality Requests — протокол контроля качества связи (полезно для часто зависающих сессий и кривых

# set lqrperiod 15 # если подряд пропадает 5 пакетов LQR с интервалом 15 сек. — класть трубку и перезванивать (если LQR не

# к сожалению, LQR поддерживается (правильно) не всеми dial-up серверами (зависит от прямых рук админа)

set timeout 600 # если в течение 10 минут не ходят пакеты описанные в правилах «set filter alive» — рвать связь

set phone 123456 # номера телефонов и правила их перебора (см. далее)

set login # сбросить чат скрипт (авторизация будет проходить через PAP/CHAP)

# к сожалению, некоторые тупые провы до сих пор юзают логин скрипт, так как не умеют настроить pap/chap

set authname vasya # логин

set authkey mYC00lpAsSw0rd # пароль

<— cut —>

Genie
Squid выдает в логах следующее:

2004/06/26 16:50:37| comm_udp_sendto: FD 4, 194.67.1.154, port 53: (65) No route to host

2004/06/26 16:50:37| idnsSendQuery: FD 4: sendto: (65) No route to host

У меня стоит ipfw на FreeBSD, разрешено все по lo0, разрешены 20,21,25,110,53,80 по ppp0. Так вот если по ppp0 разрешить все, то в логах прокси такой ерунды нет.

На сколько я понял сквиду нужны какие то разрешенные порты, какие я незнаю.

Если внимательно присмотреться к «comm_udp_sendto: FD 4, 194.67.1.154, port 53», и затем «idnsSendQuery», то становится понятно, что не разрешены исходящие запросы на 53ий порт протокола udp, использующегося для определения адреса по полному имени и наоборот.

«20,21,25,110,53,80» — это, видимо, только по протоколу tcp…

Да, чтобы разрешить udp соединения часто нужны всякие там keep-state. Потому лучше забить на ipfw для ppp соединений, т.к. ppp сделает это гораздо проще.

Zarg
Genie
Если внимательно присмотреться к «comm_udp_sendto: FD 4, 194.67.1.154, port 53», и затем «idnsSendQuery», то становится понятно, что не разрешены исходящие запросы на 53ий порт протокола udp, использующегося для определения адреса по полному имени и наоборот.

«20,21,25,110,53,80» — это, видимо, только по протоколу tcp…

Вообщем то я тоже это видел.

Вот как у меня выглядят правила для этого порта

$fwcmd add allow tcp from any to any 53 via ppp0

$fwcmd add allow tcp from any 53 to any via ppp0

$fwcmd add allow udp from any to any 53 via ppp0

$fwcmd add allow udp from any 53 to any via ppp0

По крайней мере с такими правами у меня DNS раньше работал, да собственно и сейчас прокси в инет пускает. Правда я не совсем уверен, что он кеширует.., а тут такая ерунда в логах.

P.S. А переходить на ppp не хочу, мне pppd по душе.

По умолчанию dns ответы при рекурсивном поиске принимаются на порту > 1024. Тогда либо открыть все непривиллегированные порты, либо использовать динамические правила, либо nat.

Genie

уж лучше тогда поставть себе локально кеширующий dns-сервер. ;)

много приятнее. особенно в плане уменьшения траффика при многочисленных резолвингах. ;)

Последние комментарии

ecobeingecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.