Не работает redirect_port
FreeBSD 4.9
Правила ipfw:ipfw add divert natd ip from any to any via tun0
ipfw add allow tcp from any 3389 to any
ipfw add allow tcp from any to any 3389
ipfw add allow icmp from any to any
ipfw add allow udp from any 53 to any
ipfw add allow udp from any to any 53
ipfw add allow ip from any to anyNAT поднят, ping проходит , но когда пытаешься зайти на терминал- долго думает и выдает что не может законектиться
Подскажите пожалуйста как поправить.
как выглядит у тя запись для redirect_port?
>как выглядит у тя запись для redirect_port?
redirect_port 192.168.1.4:3389 3389
>>как выглядит у тя запись для redirect_port?
>redirect_port 192.168.1.4:3389 3389
и где ты прописал этот redirect_port ???
надо в /etc/natd.conf прописать
redirect_port tcp 192.168.1.4:3389 3389
>>>как выглядит у тя запись для redirect_port?
>>redirect_port 192.168.1.4:3389 3389
>
>
>и где ты прописал этот redirect_port ???
>надо в /etc/natd.conf прописать
>redirect_port tcp 192.168.1.4:3389 3389
natd.conflog yes
log_denied no
use_sockets yes
same_ports yes
unregistered_only yes
dynamic yesredirect_port tcp 192.168.1.4:3389 3389
в /etc/rc.conf _должна_ быть такая строчка:
natd_flags="-f /etc/natd.conf"
есть?
>в /etc/rc.conf _должна_ быть такая строчка:
>natd_flags="-f /etc/natd.conf"
>есть?
есть такая строчка.
Nat работает из локалки есть выход в inet
странно, у меня с такой конфигурацие работает...
разве что - машина с nat является шлюзом по умолчанию для терминального сервера?
>странно, у меня с такой конфигурацие работает...
>разве что - машина с nat является шлюзом по умолчанию для терминального
>сервера?Шлюз по умолчанию не прописан
Суть в том, что после ната пакетики приходят к внутреннему хосту с внешним адресом отправителя и если в присоединенных или в статических маршрутах этот самый внутренний хост не находит отправителя, то тупенько кидает его в маршрут по умолчанию. В твоем же случае....
Короче смотри через tcpdump приходят ли пакеты к твоему внутреннему хосту и каким макаром они пытаются вернуться.
Кстати, а почему нельзя назначить шлюз по умолчанию?
>Суть в том, что после ната пакетики приходят к внутреннему хосту с
>внешним адресом отправителя и если в присоединенных или в статических маршрутах
>этот самый внутренний хост не находит отправителя, то тупенько кидает его
>в маршрут по умолчанию. В твоем же случае....
>Короче смотри через tcpdump приходят ли пакеты к твоему внутреннему хосту и
>каким макаром они пытаются вернуться.
>Кстати, а почему нельзя назначить шлюз по умолчанию?Напиши пожалуйста ключи с которыми запускать tcpdump
боюсь ошибиться
убери из natd.conf "yes"
log
use_sockets
same_ports
unregistered_only
dynamic
>боюсь ошибиться
>убери из natd.conf "yes"
>log
>use_sockets
>same_ports
>unregistered_only
>dynamic
убрал - не помогло
>убрал - не помогло
и не должно было помочь :-) верни
раз по ключам tcpdump возникают вопросы, повторяю свой - какие причины заставляют не дать шлюз по умолчанию терминальному серверу? по установке default должна связь появиться. Какие действительно весомы причины не дают это сделать?
>>убрал - не помогло
>и не должно было помочь :-) верни
>раз по ключам tcpdump возникают вопросы, повторяю свой - какие причины заставляют
>не дать шлюз по умолчанию терминальному серверу? по установке default должна
>связь появиться. Какие действительно весомы причины не дают это сделать?Поставил default. Все заработало. Спасибо за помощь!!!
Объясни , если не сложно, почему не работает без default
>
>Поставил default. Все заработало. Спасибо за помощь!!!
>
>Объясни , если не сложно, почему не работает без defaultПотому что приняв пакет с адресом отправителя например 212.83.44.101, он в любом случае должен ему ответить (TCP: на SYN должен ответить SYN+ACK, и т.п.). При этом в пакете ответа IP адреса отправителя и получателя меняются местами и далее делается поиск в таблице маршрутизации для адреса получателя. В ответе это 212.83.44.101; а у тебя в таблице маршрутизации (можешь проверить route print) есть маршруты только для локальной сети. Приложение при этом получает destination unreachable. А если есть маршрут по умолчанию - то пакет уходит по нему и все работает.
Вообще, маршруты должны быть! А защита должна производится средствами пакетных фильтров. Имхо конечно же.
Здесь я полностью согласен с oppofan - вряд ли найдутся причины НЕ делать маршрут по умолчанию для windows сервера; хотя бы из соображений работоспособности DNS.
>Объясни , если не сложно, почему не работает без default
рад :-)
о причинах писал выше
>>>убрал - не помогло
>>и не должно было помочь :-) верни
>>раз по ключам tcpdump возникают вопросы, повторяю свой - какие причины заставляют
>>не дать шлюз по умолчанию терминальному серверу? по установке default должна
>>связь появиться. Какие действительно весомы причины не дают это сделать?
>
>Поставил default. Все заработало. Спасибо за помощь!!!прошло 2 года и на 6.3 почему-то не работает!!
при этом с локальной машины наружу даже пинг не идёт
если это кто-то услышит - ответьте пожалуйста
>прошло 2 года и на 6.3 почему-то не работает!!
>при этом с локальной машины наружу даже пинг не идёт
>если это кто-то услышит - ответьте пожалуйстаТо что пинг наружу не идет и нат не работает скорее всего дело не в нате, а в ipfw там есть особые тонкости в прописании правил.
Посмотри примеры в хандбук. Там теперь через скипту делается. Могу привести свой конфиг.
Но вот редирект портов у меня тоже не работает.