URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 84258
[ Назад ]
Исходное сообщение
"из-за NATа не видно часть спйтов"
Отправлено solariz , 26-Фев-09 11:41 
Господа!
Имеем следующую проблему.
Есть роутер на базе FreeBSD. Соединение с провом - pppoe.
За NATом роутера компьютеры с разнообразным виндоуз.
Есть сайт который открывается напрямую с роутера (или если подрубать любую виндовую машину напрямую)
Но не открывается из внутренней сети.

router# ifconfig
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether 00:02:44:2d:8f:86
        inet 10.19.18.8 netmask 0xfffffc00 broadcast 10.19.19.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether 00:c0:0c:72:69:2c
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
vr0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>
        ether 00:16:ec:cf:d8:6e
        media: Ethernet autoselect (none)
        status: no carrier
plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT> metric 0 mtu 1500
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
pfsync0: flags=0<> metric 0 mtu 1460
        syncpeer: 224.0.0.240 maxupd: 128
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1492
        inet 81.xxx.xxx.xxx --> 81.9.101.119 netmask 0xffffffff
        Opened by PID 568

В pf.conf:
[cut]
nat on $pppoe_if proto tcp from $int_if/24 to any port $nat_allowed_tcp_ports -> ($pppoe_if)
nat on $pppoe_if proto udp from $int_if/24 to any port $nat_allowed_udp_ports -> ($pppoe_if)
[cut]

router# telnet media-portal.ru 80
Trying 81.9.101.68...
Connected to media-portal.ru.
Escape character is '^]'.
GET
....и дальше все нормально

т.е. ресурс ТОЧНО живой и доступен.

Благодарен за помощь.

Содержание
Сообщения в этом обсуждении
"из-за NATа не видно часть спйтов"
Отправлено reader , 26-Фев-09 12:54 
>[оверквотинг удален]
>router# telnet media-portal.ru 80
>Trying 81.9.101.68...
>Connected to media-portal.ru.
>Escape character is '^]'.
>GET
>....и дальше все нормально
>
>т.е. ресурс ТОЧНО живой и доступен.
>
>Благодарен за помощь.

а если убрать ограничение по портам в правилах NAT и фильтров?

"из-за NATа не видно часть спйтов"
Отправлено solariz , 26-Фев-09 12:59 
>а если убрать ограничение по портам в правилах NAT и фильтров?

Нет ограничений. Все тупо пробрасывается через NAT.


"из-за NATа не видно часть спйтов"
Отправлено Pahanivo , 26-Фев-09 13:35 
>router# telnet media-portal.ru 80
>Trying 81.9.101.68...
>Connected to media-portal.ru.
>Escape character is '^]'.
>GET

а ты дай такой телнет с локальной машины из под ната
сайт может быть виртуальным хостом - телнет на 80 идет те сервак робит, а конкретный хост не открывается ибо не доступен как вхост.


"из-за NATа не видно часть спйтов"
Отправлено solariz , 26-Фев-09 14:11 

>а ты дай такой телнет с локальной машины из под ната

С локальной машины telnet не прокатывает (

"из-за NATа не видно часть спйтов"
Отправлено reader , 26-Фев-09 15:05 
>
>>а ты дай такой телнет с локальной машины из под ната
>
>С локальной машины telnet не прокатывает (

у меня через ADSL модем с NAT он тоже не открылся.
наверно нужно слушать интерфейс на шлюзе при проверке с него и с клиентов, а потом сравнить.

"из-за NATа не видно часть спйтов"
Отправлено solariz , 26-Фев-09 16:07 
>>
>>>а ты дай такой телнет с локальной машины из под ната
>>
>>С локальной машины telnet не прокатывает (
>
>у меня через ADSL модем с NAT он тоже не открылся.
>наверно нужно слушать интерфейс на шлюзе при проверке с него и с
>клиентов, а потом сравнить.

этот сайт открывается только из подсети моего провайдера

"из-за NATа не видно часть спйтов"
Отправлено McLeod095 , 26-Фев-09 18:51 
>[оверквотинг удален]
>router# telnet media-portal.ru 80
>Trying 81.9.101.68...
>Connected to media-portal.ru.
>Escape character is '^]'.
>GET
>....и дальше все нормально
>
>т.е. ресурс ТОЧНО живой и доступен.
>
>Благодарен за помощь.

Не знаю как с pppoe но с pptp иногда бывает проблема с mtu. решается его уменьшением. Попробуй при поднтии интерфейса mtu прописать в районе 1300-1400. Может поможет.

"из-за NATа не видно часть спйтов"
Отправлено solariz , 26-Фев-09 21:21 
>Не знаю как с pppoe но с pptp иногда бывает проблема с
>mtu. решается его уменьшением. Попробуй при поднтии интерфейса mtu прописать в
>районе 1300-1400. Может поможет.

Пробовал. к сожалению не помогает.

"из-за NATа не видно часть спйтов"
Отправлено LS , 27-Фев-09 21:24 
>[оверквотинг удален]
>>Connected to media-portal.ru.
>>Escape character is '^]'.
>>GET
>>....и дальше все нормально
>>
>>т.е. ресурс ТОЧНО живой и доступен.
>>
>>Благодарен за помощь.
>
>Не знаю как с pppoe но с pptp иногда бывает проблема с

и то и другое в конечном итоге под pppd крутится (что отразиться на MTU обоих протоколов).

>mtu. решается его уменьшением. Попробуй при поднтии интерфейса mtu прописать в
>районе 1300-1400. Может поможет.

+1  - хорошо вспомнил. я все время эту банальную вещь забываю

решается именно уменьшением mtu. тока вот никакого шаманства на счет "в районе 1300-1400" не надо.

все легко выясняется банальным пингом с разным размером посылаемых пакетов с запретом дефрагментации c локальной машины. в результате чего выясняем максимальный MTU для "несущего" протокола. после банально вычитаем из полученной величины размер служебной информации в заголовках/хвостах пакетов инкапсулированных протоколов и прописываем на НАТ-сервере соотвествующий MSS для клиентов. меньше чем нужно оно все равно конечно заработает, только вот при нынешних скоростях подключения - это уж слишком - так и до диалаповских mtu дойдем )

"из-за NATа не видно часть спйтов"
Отправлено solariz , 26-Фев-09 21:23 
кстати вот с сервера:
router# tshark -i rl0 -t a host 81.9.101.68
Capturing on rl0
20:08:53.903840   10.19.18.8 -> 81.9.101.68  TCP 56351 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=33707912 TSER=0
20:08:53.904626  81.9.101.68 -> 10.19.18.8   TCP http > 56351 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
20:08:53.904737   10.19.18.8 -> 81.9.101.68  TCP 56351 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
[cut]

с локальной машины:
router# tshark -i rl0 -t a host 81.9.101.68
Capturing on rl1
20:10:20.403472  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
20:10:23.398363  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
20:10:29.392245  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460

где 81.9.101.68 - указанный сайт
rl0 - внешний интерфейс (не PPPOE)

"из-за NATа не видно часть спйтов"
Отправлено Leo , 27-Фев-09 09:13 
Чем делается pppoe ?
Во фре рекомендуется mpd, версия рекомендуется 5.х, в конфиге важную роль играет параметр
set iface enable tcpmssfix
(http://mpd.sourceforge.net/doc5/mpd28.html#28)
который disable по умолчанию.
"из-за NATа не видно часть спйтов"
Отправлено solariz , 27-Фев-09 23:57 
>Чем делается pppoe ?

с помощью ppp

ppp.conf:

default:
set log Phase LCP
ident user-ppp VERSION (built COMPILATIONDATE)

# Ensure that "device" references the correct serial port
# for your modem. (cuad0 = COM1, cuad1 = COM2)
#
set device /dev/cuad1

set speed 115200
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
           \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
set timeout 180                        # 3 minute idle timer (the default)
enable dns                             # request DNS info (for resolv.conf)

eltel-pppoe:
        delete all
        set device PPPoE:rl0
        set dial
        set login
        set authname xxxx
        set authkey xxxxx
        set crtscts off
        set speed sync
        enable lqr
        accept lqr
        set reconnect 5 999
        set ifaddr 0 0
        add default HISADDR
        set timeout 0
        set redial 5 0


"из-за NATа не видно часть спйтов"
Отправлено reader , 27-Фев-09 20:48 
>кстати вот с сервера:
>router# tshark -i rl0 -t a host 81.9.101.68
>Capturing on rl0
>20:08:53.903840   10.19.18.8 -> 81.9.101.68  TCP 56351 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=33707912 TSER=0
>20:08:53.904626  81.9.101.68 -> 10.19.18.8   TCP http > 56351 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
>20:08:53.904737   10.19.18.8 -> 81.9.101.68  TCP 56351 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
>[cut]

это с сервера , когда к сайту обращаетесь с сервера же или с клиента?

>
>с локальной машины:
>router# tshark -i rl0 -t a host 81.9.101.68

это с сервера при обращении к сайту с клиента?
может все же и c rl0 покажите, а не только с rl1
>Capturing on rl1
>20:10:20.403472  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>20:10:23.398363  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>20:10:29.392245  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>
>где 81.9.101.68 - указанный сайт
>rl0 - внешний интерфейс (не PPPOE)

"из-за NATа не видно часть спйтов"
Отправлено LS , 27-Фев-09 22:28 
>с локальной машины:
>router# tshark -i rl0 -t a host 81.9.101.68
>Capturing on rl1
>20:10:20.403472  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>20:10:23.398363  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>20:10:29.392245  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>

вывод-то по любому однин - запрос на соединение уходит, ответа нет.

я бы поискал сначало (на сервере), что они вообще во вне уходят, а потом бы стал искать где ответы теряются (трапы в пакетный фильтр где сброс пакетов идет и греп по логам - и все будет ясно в 5 минут)

"из-за NATа не видно часть спйтов"
Отправлено reader , 27-Фев-09 23:44 
>[оверквотинг удален]
>>20:10:23.398363  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>>20:10:29.392245  192.168.0.3 -> 81.9.101.68  TCP 49660 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>>
>
>вывод-то по любому однин - запрос на соединение уходит, ответа нет.
>
>я бы поискал сначало (на сервере), что они вообще во вне уходят,
>а потом бы стал искать где ответы теряются (трапы в пакетный
>фильтр где сброс пакетов идет и греп по логам - и
>все будет ясно в 5 минут)

именно, поэтому и хочется видеть что творится при этом на rl0

"из-за NATа не видно часть спйтов"
Отправлено solariz , 28-Фев-09 00:06 

>именно, поэтому и хочется видеть что творится при этом на rl0

23:56:59.016026  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
23:57:02.010820  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
23:57:08.015479  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460

на rl0 при запросе из внутренней сети (192.168.0.3)

"из-за NATа не видно часть спйтов"
Отправлено reader , 28-Фев-09 00:55 
>
>>именно, поэтому и хочется видеть что творится при этом на rl0
>
>23:56:59.016026  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>23:57:02.010820  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>23:57:08.015479  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>
>на rl0 при запросе из внутренней сети (192.168.0.3)

если это действительно на rl0, то NAT похоже не отработал, по моему тут уже должен быть 10.19.18.8, а не 192.168.0.3

"из-за NATа не видно часть спйтов"
Отправлено solariz , 28-Фев-09 02:14 
>если это действительно на rl0, то NAT похоже не отработал, по моему
>тут уже должен быть 10.19.18.8, а не 192.168.0.3

ага. так оно и есть (

причем только для этого сайта. (
а вот, например, пингуем ya.ru -- смотрим непосредственно на pppoe-интерфейсе:
router# tshark -i ng0 -t a host 213.180.204.8
Capturing on ng0
02:03:00.109992 81.222.235.35 -> 213.180.204.8 ICMP Echo (ping) request
02:03:00.119460 213.180.204.8 -> 81.222.235.35 ICMP Echo (ping) reply
02:03:01.120416 81.222.235.35 -> 213.180.204.8 ICMP Echo (ping) request


"из-за NATа не видно часть спйтов"
Отправлено reader , 28-Фев-09 03:16 
>[оверквотинг удален]
>
>ага. так оно и есть (
>
>причем только для этого сайта. (
>а вот, например, пингуем ya.ru -- смотрим непосредственно на pppoe-интерфейсе:
>router# tshark -i ng0 -t a host 213.180.204.8
>Capturing on ng0
>02:03:00.109992 81.222.235.35 -> 213.180.204.8 ICMP Echo (ping) request
>02:03:00.119460 213.180.204.8 -> 81.222.235.35 ICMP Echo (ping) reply
>02:03:01.120416 81.222.235.35 -> 213.180.204.8 ICMP Echo (ping) request

может все же правила pf?

pfctl -sn
pfctl -sr

а, через pfctl -ss смотрите текущие соединения, или pftop

"из-за NATа не видно часть спйтов"
Отправлено LS , 28-Фев-09 04:34 
>[оверквотинг удален]
>>02:03:00.109992 81.222.235.35 -> 213.180.204.8 ICMP Echo (ping) request
>>02:03:00.119460 213.180.204.8 -> 81.222.235.35 ICMP Echo (ping) reply
>>02:03:01.120416 81.222.235.35 -> 213.180.204.8 ICMP Echo (ping) request
>
>может все же правила pf?
>
>pfctl -sn
>pfctl -sr
>
>а, через pfctl -ss смотрите текущие соединения, или pftop

nat on $pppoe_if proto tcp from $int_if/24 to any port $nat_allowed_tcp_ports -> ($pppoe_if)
nat on $pppoe_if proto udp from $int_if/24 to any port $nat_allowed_udp_ports -> ($pppoe_if)

а как это прокоментируете? тут все нормально?

прилепил не туда вопрос ((. но если ответите буду очень благодарен.

кстати pppoe интерфейс - динамический. отсуда вопросы:
1)
$pppoe_if и $int_if - это адреса или названия интерфейсов?
2)
можешь ли ты контролировать названия динамических интерфейсов и, соотвественно опираться на них в своих правилах?

"из-за NATа не видно часть спйтов"
Отправлено solariz , 28-Фев-09 12:35 
>можешь ли ты контролировать названия динамических интерфейсов и, соотвественно опираться на них
>в своих правилах?

Вот, собственно, пакетфильтр в том виде, на котором все и тестируется:

router# more /etc/pf.conf
ext_if = "rl0"
# внешний интерфейс
int_if = "rl1"
# внутрений интерфейс
pppoe_if = "ng0"
# динамический интерфейс
lo_if = "lo0"
# lo0
lan_nets = "{ 192.168/16, 10/8, 172.16/12 }"
# разрешенные сети
nat_allowed_tcp_ports="{ 22, 25, 53, 80, 110, 443, 5190, 49155 }"
# разрешенные порты TCP
nat_allowed_udp_ports="{ 53 }"
# разрешенные порты UDP

nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
# якоря для работы FTP

no nat on $pppoe_if proto tcp from 192.168.0.3/32 to any port 5190
# не пускаем icq с определенного ip
nat on $pppoe_if proto tcp from $int_if/24 to any port $nat_allowed_tcp_ports -> ($pppoe_if)
# пробрасываем через NAT рапзрешенные порты TCP
nat on $pppoe_if proto udp from $int_if/24 to any port $nat_allowed_udp_ports -> ($pppoe_if)
# пробрасываем через NAT рапзрешенные порты UDP
nat on $pppoe_if proto icmp from $int_if/24 to any -> ($pppoe_if)
# тупо разрешаем ICMP


rdr pass on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021
# все, что приходит на 21 порт изнутри сети отправляем FTP-прокси


anchor "ftp-proxy/*"

pass in on $pppoe_if proto tcp from any to $pppoe_if port 22

pass quick on lo0 all
pass quick on $int_if all

pass in quick on $pppoe_if all

"из-за NATа не видно часть спйтов"
Отправлено solariz , 28-Фев-09 12:39 
>может все же правила pf?
>
>pfctl -sn
>pfctl -sr

router# pfctl -sn
nat-anchor "ftp-proxy/*" all
no nat on ng0 inet proto tcp from 192.168.0.3 to any port = aol
nat on ng0 inet proto tcp from 192.168.0.0/24 to any port = ssh -> (ng0) round-robin
nat on ng0 inet proto tcp from 192.168.0.0/24 to any port = smtp -> (ng0) round-robin
nat on ng0 inet proto tcp from 192.168.0.0/24 to any port = domain -> (ng0) round-robin
nat on ng0 inet proto tcp from 192.168.0.0/24 to any port = http -> (ng0) round-robin
nat on ng0 inet proto tcp from 192.168.0.0/24 to any port = pop3 -> (ng0) round-robin
nat on ng0 inet proto tcp from 192.168.0.0/24 to any port = https -> (ng0) round-robin
nat on ng0 inet proto tcp from 192.168.0.0/24 to any port = rdp -> (ng0) round-robin
nat on ng0 inet proto tcp from 192.168.0.0/24 to any port = aol -> (ng0) round-robin
nat on ng0 inet proto tcp from 192.168.0.0/24 to any port = 49155 -> (ng0) round-robin
nat on ng0 inet proto udp from 192.168.0.0/24 to any port = domain -> (ng0) round-robin
nat on ng0 inet proto icmp from 192.168.0.0/24 to any -> (ng0) round-robin
nat on rl1 inet all tagged RDP -> 192.168.0.1
rdr-anchor "ftp-proxy/*" all
rdr pass on rl1 inet proto tcp from any to any port = ftp -> 127.0.0.1 port 8021
rdr pass on ng0 inet proto tcp from any to (ng0) port = rdp tag RDP -> 192.168.0.3 port 3389

router# pfctl -sr
anchor "ftp-proxy/*" all
pass in on ng0 inet proto tcp from any to 81.222.235.35 port = ssh flags S/SA keep state
pass quick on lo0 all flags S/SA keep state
pass quick on rl1 all flags S/SA keep state
pass in quick on ng0 all flags S/SA keep state

"из-за NATа не видно часть спйтов"
Отправлено LS , 28-Фев-09 04:30 
>[оверквотинг удален]
>>>именно, поэтому и хочется видеть что творится при этом на rl0
>>
>>23:56:59.016026  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>>23:57:02.010820  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>>23:57:08.015479  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>>
>>на rl0 при запросе из внутренней сети (192.168.0.3)
>
>если это действительно на rl0, то NAT похоже не отработал, по моему
>тут уже должен быть 10.19.18.8, а не 192.168.0.3

однозначно не отработал. если это ловится снифером на выходе интерфейса. если ловится на уровне ядра... хотя нет - такой бред бсд бы не позволила... стало быть не работает нат

"из-за NATа не видно часть спйтов"
Отправлено LS , 28-Фев-09 04:26 
>
>>именно, поэтому и хочется видеть что творится при этом на rl0
>
>23:56:59.016026  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>23:57:02.010820  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>23:57:08.015479  192.168.0.3 -> 81.9.101.68  TCP 53931 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460
>
>на rl0 при запросе из внутренней сети (192.168.0.3)

я просто линуксоид. так что мне ориентироваться в названиях интерфейсов и правил пакетного фильтра только по интуиции приходится )

"из-за NATа не видно часть спйтов"
Отправлено LS , 27-Фев-09 22:21 

>В pf.conf:
>[cut]
>nat on $pppoe_if proto tcp from $int_if/24 to any port $nat_allowed_tcp_ports -> ($pppoe_if)
>nat on $pppoe_if proto udp from $int_if/24 to any port $nat_allowed_udp_ports -> ($pppoe_if)
>[cut]
>

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

"из-за NATа не видно часть спйтов"
Отправлено reader , 27-Фев-09 23:52 
>[оверквотинг удален]
>>В pf.conf:
>>[cut]
>>nat on $pppoe_if proto tcp from $int_if/24 to any port $nat_allowed_tcp_ports -> ($pppoe_if)
>>nat on $pppoe_if proto udp from $int_if/24 to any port $nat_allowed_udp_ports -> ($pppoe_if)
>>[cut]
>>
>
>а стесняюсь спросить , такое понятие как форвардинг пакетов во фре существует?
>то есть пропуск пакетов. которые серверу не предназначены? или если нат,
>форвард автоматом идет? я линуксоид просто

запись в rc.conf
gateway_enable="YES"

или через sysctl

но про это не спрашивал в надежде, что другие сайта открываются.

"из-за NATа не видно часть спйтов"
Отправлено LS , 27-Фев-09 23:58 
>[оверквотинг удален]
>>а стесняюсь спросить , такое понятие как форвардинг пакетов во фре существует?
>>то есть пропуск пакетов. которые серверу не предназначены? или если нат,
>>форвард автоматом идет? я линуксоид просто
>
>запись в rc.conf
>gateway_enable="YES"
>
>или через sysctl
>
>но про это не спрашивал в надежде, что другие сайта открываются.

я как я говорил уже - линухоид. gateway_enable="YES" мне не очем не говорит. просто в линухе есть такая штука, когда пакет адресован не серверу конкретно, то чтоб он прошел это надо разрешить. это и есть gateway_enable="YES" на фре?

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

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

сделай пинг, как я выше писал

"из-за NATа не видно часть спйтов"
Отправлено LS , 28-Фев-09 00:05 
>[оверквотинг удален]
>>а стесняюсь спросить , такое понятие как форвардинг пакетов во фре существует?
>>то есть пропуск пакетов. которые серверу не предназначены? или если нат,
>>форвард автоматом идет? я линуксоид просто
>
>запись в rc.conf
>gateway_enable="YES"
>
>или через sysctl
>
>но про это не спрашивал в надежде, что другие сайта открываются.

с виндового клиента ping -l 1406 -f сделай
а потом ping -l 500 -f

"из-за NATа не видно часть спйтов"
Отправлено LS , 28-Фев-09 00:07 
>[оверквотинг удален]
>>>форвард автоматом идет? я линуксоид просто
>>
>>запись в rc.conf
>>gateway_enable="YES"
>>
>>или через sysctl
>>
>>но про это не спрашивал в надежде, что другие сайта открываются.
>
>с виндового клиента ping -l 1406 -f сделай

ping -l 1460 -f
тоесть - именно так у тебя MSS с клиента в логах...

>а потом ping -l 500 -f

"из-за NATа не видно часть спйтов"
Отправлено solariz , 28-Фев-09 00:09 
>>с виндового клиента ping -l 1406 -f сделай
>
>ping -l 1460 -f
>тоесть - именно так у тебя MSS с клиента в логах...
>
>>а потом ping -l 500 -f

C:\Program Files\Far>ping -l 1406 -f media-portal.ru

Обмен пакетами с media-portal.ru [81.9.101.68] с 1406 байтами данных:
Превышен интервал ожидания для запроса.

Статистика Ping для 81.9.101.68:
    Пакетов: отправлено = 1, получено = 0, потеряно = 1
    (100% потерь)
Control-C
^C
C:\Program Files\Far>ping -l 1500 -f media-portal.ru

Обмен пакетами с media-portal.ru [81.9.101.68] с 1500 байтами данных:
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.

Статистика Ping для 81.9.101.68:
    Пакетов: отправлено = 4, получено = 0, потеряно = 4
    (100% потерь)

"из-за NATа не видно часть спйтов"
Отправлено LS , 28-Фев-09 00:27 
>[оверквотинг удален]
>Обмен пакетами с media-portal.ru [81.9.101.68] с 1500 байтами данных:
>Требуется фрагментация пакета, но установлен запрещающий флаг.
>Требуется фрагментация пакета, но установлен запрещающий флаг.
>Требуется фрагментация пакета, но установлен запрещающий флаг.
>Требуется фрагментация пакета, но установлен запрещающий флаг.
>
>Статистика Ping для 81.9.101.68:
>    Пакетов: отправлено = 4, получено = 0, потеряно
>= 4
>    (100% потерь)

ну и куда 1500 ставить если и тебя по логам с клиента MSS=1460 (я просто оипсался в посте - 1406 сказал)

пингуй с
l 1460
и
l 500
будет ясно - в этом проблема или нет. я же вроде в догонку пост слал, что 1460 надо. да почитай просто - механизм там прозрачный как две капли воды.

"из-за NATа не видно часть спйтов"
Отправлено LS , 28-Фев-09 00:42 
>пингуй с
>l 1460
>и
>l 500
>будет ясно - в этом проблема или нет. я же вроде в
>догонку пост слал, что 1460 надо. да почитай просто - механизм
>там прозрачный как две капли воды.

объясняю в чем суть. максимальный размер кадра ehternet 1518 байт. когда твой сервер подключается, который это соединение к прову делает, он видит, что он устанавливает соединение pppoe и сразу уменьшает максимальный объем полезной информации в пакете на величину заголовков/хвостов пакета ppp. потому что он знает об этом соединении. в результате объем кадра ethernet , который идет к прову не превышает допустимого размера.

теперь смотрим на твой виндовый клиент за сервером. он НИЧЕГО не знает про то, что ты его наружу выпускаешь по pppoe. он подключен к тебе по ethernet и считает (справедливо) что вполне может послать тебе кадр размером в 1518. теперь твой сервер делает nat, и запихивает пришедший кадр от клиента, обрамляя его заголовками/хвостами PPPOE. в резуьтате ты пытаешься своему прову но несущему протоколу ethernet передать кадр, который превышает допустимый по стандарту размер. как думаешь что пров сделает?

решение - в пакетном фильтре от всех клиентов ставить MSS-заголовки/хвосты_протокола_pppoe.

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

тут в работу ping для определения максимального размера пакетов, которые в этом направлении проходят, и ясно, что уже не ethernet, tcp/ip несущиц протоол и опять же  - просто ты к цели идешь (сайт посмотреть - тут никакой инкапсуляции не будет) или через другие протоколы (например ч/з vpn хочешь к такчке подцепиться - тут уж тогда вычитай заголовки хвосты сразу ppp+gre как минимум)

короче просто надо знать структуру пакетов сетевых протоколов. или иметь возможность ее в инете найти - там этого говна навалом ). счастливо

"из-за NATа не видно часть спйтов"
Отправлено solariz , 28-Фев-09 00:07 

>запись в rc.conf
>gateway_enable="YES"
>
>или через sysctl
>
>но про это не спрашивал в надежде, что другие сайта открываются.

В моем случае - gateway_enable="YES"
Другие сайты открываются.


"из-за NATа не видно часть спйтов"
Отправлено solariz , 28-Фев-09 13:23 
А вот пингуем media-portal.ru c опущенным(!!!!) динамическим интерфейсом!!! >=E

router# ping 81.9.101.68
PING 81.9.101.68 (81.9.101.68): 56 data bytes
64 bytes from 81.9.101.68: icmp_seq=0 ttl=62 time=0.746 ms
64 bytes from 81.9.101.68: icmp_seq=1 ttl=62 time=0.626 ms
64 bytes from 81.9.101.68: icmp_seq=2 ttl=62 time=0.702 ms
64 bytes from 81.9.101.68: icmp_seq=3 ttl=62 time=0.603 ms

отсюда делается ясно, почему пакеты не проходят через NAT.


"из-за NATа не видно часть спйтов"
Отправлено solariz , 28-Фев-09 13:40 
Итак, проблема решена.
Спасибо за помощь, друзья! )

добавил в пакетфильтр строку
nat on $ext_if proto tcp from $int_if/24 to 81.9.101.68/32 -> ($ext_if)

все работает. тема закрыта.