Итак, раньше у меня в качестве роутера стояла железка D-Link DSL500T на нем был проброшен порт 8080 в локалку для прокси.
В проксе при таком пробросе потра я видел реальный ип адрес пользователя и все нормально проходили авторизацию.Далее необходимость вынудила отказаться от использования в качестве роутера этой железки и теперь поднял роутер на старом писюке под управлением ubuntu.
Но вот беда, теперь я в проксе вижу вместо адреса пользователя адрес роутера.
Соответственно возникают проблемы с авторизацией пользователей.Порт пробрасываю следующей строчкой
iptables -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.10.4.90:8080как можно сделать чтобы на проксе был виден адрес не роутера а реальный адрес как это было при DSL500?
>[оверквотинг удален]
>теперь поднял роутер на старом писюке под управлением ubuntu.
>Но вот беда, теперь я в проксе вижу вместо адреса пользователя адрес
>роутера.
>Соответственно возникают проблемы с авторизацией пользователей.
>
>Порт пробрасываю следующей строчкой
>iptables -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.10.4.90:8080
>
>как можно сделать чтобы на проксе был виден адрес не роутера а
>реальный адрес как это было при DSL500?ИП адрес прокси не менялся? зачем нужен DNAT ?
просто убери его и всё
>ИП адрес прокси не менялся? зачем нужен DNAT ?
>просто убери его и всёА как люди попадут на прокси сервер тогда?
Тоесть каким образом настроить так чтобы люди ломясь на 172.16.25.71:8080 были проброшены на 10.10.4.90:8080
>>ИП адрес прокси не менялся? зачем нужен DNAT ?
>>просто убери его и всё
>
>А как люди попадут на прокси сервер тогда?
>
>Тоесть каким образом настроить так чтобы люди ломясь на 172.16.25.71:8080 были проброшены
>на 10.10.4.90:8080А почему бы людям не ломиться сразу на 10.10.4.90:8080 ?
стоп, не DNAT , у тебя там видимо маскарадинг включён
хотя не совсем непонятно с DNAT, у клиентов что прописан для прокси ИП твоего роутера?
покажи
iptables -t nat -L -vn
и
route -n
>стоп, не DNAT , у тебя там видимо маскарадинг включён
>хотя не совсем непонятно с DNAT, у клиентов что прописан для прокси
>ИП твоего роутера?
>покажи
>iptables -t nat -L -vn
>и
>route -ngloom@aist-router:~$ sudo iptables -L -vn -t nat
Chain PREROUTING (policy ACCEPT 10319 packets, 1840K bytes)
pkts bytes target prot opt in out source destination
494 31572 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4662 to:10.10.4.90:4662
179 9308 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4711 to:10.10.4.90:4711
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4672 to:10.10.4.90:4672
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4662 to:10.10.4.90:4662
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:6553 to:10.10.4.90:6553
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6553 to:10.10.4.90:6553
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1080 to:10.10.4.90:1080
80 4096 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:10.10.4.90:8080
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4671 to:10.10.4.90:4671
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4671 to:10.10.4.90:4671
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723 to:10.10.4.90:1723Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
3246 178K MASQUERADE 0 -- * * 0.0.0.0/0 0.0.0.0/0Chain OUTPUT (policy ACCEPT 141 packets, 18344 bytes)
pkts bytes target prot opt in out source destination
///////////////////////////////////////////////////////////////////////////////////Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
62.106.104.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.10.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
172.16.25.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
172.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
0.0.0.0 172.16.25.1 0.0.0.0 UG 0 0 0 eth0
////////////////////////////////////////////////////////////////////////////////У клиентов прописывается в качестве прокси адрес роутера
>А почему бы людям не ломиться сразу на 10.10.4.90:8080 ?Потомучто они туда не могут попасть. Им доступен только адрес роутера.
просто убери
MASQUERADE 0 -- * * 0.0.0.0/0 0.0.0.0/0и вместо него добавь
iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0а то у тебя маскарадит на всех интерфейсах
>>А почему бы людям не ломиться сразу на 10.10.4.90:8080 ?
>
>Потомучто они туда не могут попасть. Им доступен только адрес роутера.роутер - это 172.16...?
поднять на нем eth0:0 с ip из 10.10.4.0/24
>
>роутер - это 172.16...?
>поднять на нем eth0:0 с ip из 10.10.4.0/24Итак есть локалка 10.10.4.0/24 в ней есть 10.10.4.90:8080 прокся со спутниковым инетом.
Я хочу спутником дать попользоваться людям из сети провайдера 172.16.0.0/12
На роутере две сетевухи
1 - eth0 172.16.25.71 смотрит в сеть провайдера, оттуда приходят пользователи которые хотят юзать проксю
2 - eth1 10.10.4.99 смотрит в локалку, там где находится прокся 10.10.4.90Люди из сети провайдера в качестве прокси указывают адрес 172.16.25.71 и получают доступ к проксе.
Но прокся видит не адреса пользователей а адрес 10.10.4.99Но ранее когда был dsl500 все было нормально и прокся видела адреса юзеров (172.16.*)
////////////////////////////////////////////////////////////////////
>и вместо него добавь
>iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0Тогда локалка(10.10.4.0/24) не может вылезти в сеть провайдера(172.16.0.0/12).
Кстати, squid позволяет авторизироваться по именам, а не IP.
>Кстати, squid позволяет авторизироваться по именам, а не IP.Нет, прокся стоит под виндой - TrafficInspector
Первый кто авторизовался по имени и оплачивает трафик всех кто позже лезет без авторизации, а прокся думает что это тотже ип.Вопщем маленькая коробочка dsl500 могла сделать все нормально, какже это сделать на большом и мощьном компе? )
>Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
>pkts bytes target prot opt in out source destination
>3246 178K MASQUERADE 0 -- * * 0.0.0.0/0 0.0.0.0/0вот это маскарадит всё, т.е. любой пакет уходящий с любого интерфейса получает ИП интерфейса
именно поэтому на проксю все приходят с одним ИП>>и вместо него добавь
>>iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0с этим правилом маскарадится только то, что уходит с eth0
>Тогда локалка(10.10.4.0/24) не может вылезти в сеть провайдера(172.16.0.0/12).и для локалки(10.10.4.0/24) в принципе ни чего не меняется, странно что не работает
можно расписать SNAT отдельно для каждой подсети например:
iptables -t nat -A POSTROUTING -d 172.16.0.0/12 -j SNAT --to-source 172.16.25.XXX (IP роутера)ну и т.д.
Все, разобрался почему неработало в прошлый раз.
Я не поднял маскарадинг на ppp0Всем большое спасибо за помошь!
В продолжении стремительного перехода на linux )
Скажите как можео организовать ВПН (pptp) соединение с сервером который находится за роутером.
На данный момент процесс установки соединения зависает на проверки имени и пароля.
Помню в модеме это называлось pass-through
>В продолжении стремительного перехода на linux )
>Скажите как можео организовать ВПН (pptp) соединение с сервером который находится за
>роутером.
>На данный момент процесс установки соединения зависает на проверки имени и пароля.
>
>Помню в модеме это называлось pass-through-p tcp --dports 500,1000,1195,1723 -j SNAT
-p udp --dports 500,1000,1195,1723 -j SNAT+
-p 50 (51)
Воппем из сети провайдера ко мне на ВПН сервер попасть теперь могут.
Благодаря какомута из этих модулей =)
modprobe ip_tables
modprobe ipt_helper
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_conntrack_irc
modprobe iptable_nat
modprobe ip_nat_ftp
modprobe ip_nat_irc
modprobe ip_gre
modprobe ip_nat_pptpВот только теперь в обратную сторону некатит.
Пользователи из локалки немогут попасть на ВПН сервер провайдера.К вчерашнему конфигу добавил еще -A POSTROUTING -s 10.10.4.0/24 -j MASQUERADE
и ВПН у пользователей локалки начинает подниматься но не получается авторизоваться.
Выскакивает окно с просьбой ввести имя пароль и домен, хотя ранее такого окна никогда не видел.
Подскажите как быть.
>Вот только теперь в обратную сторону некатит.
>Пользователи из локалки немогут попасть на ВПН сервер провайдера.вот насчёт локалки ни чего не понял, что ты называешь "локалкой" и где она находится?
>
>К вчерашнему конфигу добавил еще -A POSTROUTING -s 10.10.4.0/24 -j MASQUERADEа смысл такого правила? все кто пойдёт на твой сервак 10.10.4.90 будут иметь один и тотже ИП
>и ВПН у пользователей локалки начинает подниматься но не получается авторизоваться.
>Выскакивает окно с просьбой ввести имя пароль и домен, хотя ранее такого
>окна никогда не видел.видимо там ещё и samba и wins
>Подскажите как быть.
а ни как, правильно настроить роутер
на eth1 у тебя локалка и в ней прокся есть, так из какой локалки теперь не могут авторизоваться?
у тебя сколько подсетей привязано к eth0?
там и локалка и провайдер?
>Таблица маршутизации ядра протокола IP
>Destination Gateway Genmask Flags Metric Ref Use Iface
>62.106.104.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
>10.10.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
>172.16.25.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
>192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
>172.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 eth0
>10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
>0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
>0.0.0.0 172.16.25.1 0.0.0.0 UG 0 0 0 eth0согласно твоей таблице маршрутов подсеть 10.10.4.0/24 вообще не поделу привязана
что здесь делает ррр0? это спутник? тогда прокся на этой же машине поднята? в этом случае твоё последнее правило просто абсурд
а какая запись правилная
>172.16.25.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0или
>172.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 eth0явно какая-то лишняя
я совсем запутался с твоей структурой сети
давай в студию
ifconfig
iproute
и опиши кто с каких подсетей куда должен попасть
адресное пространство 10.10.4.0/24 ты сам придумал или дал провайдер?
eth0 это интерфейс адсл модема, на нем получается адрес 172.16.25.71
Это адрес внутренней сети провайдера.
Также у него во внутренней сети адреса 10.0.0.0/255.0.0.0 192.168.0.0/255.255.0.0 и 172.16.0.0/255.240.0.0на eth1 локальная сеть из 10 компов. ИП адрес 10.10.4.0/255.255.255.0 выбран по той причине, что у провайдера нет этой подсети ,а т.к. провайдер все приватный диапазоны занял то ничего не остается как использовать эти адреса.
ppp0 это ВПН соединение к серверу провайдера, которое поднимается на роутере для доступа к пиринговым сетям других провайдеров, а также это соединение является наземкой для спутника.
Задача: чтобы пользователи 10.10.4.* могли поднять ВПН до сервера провайдера 192.168.0.1-4
Если нет правила -A POSTROUTING -s 10.10.4.0/24 -j MASQUERADE то ВПН вообще не поднимается, хотя и ВПН сервер провайдера пингуется.
Еслиже добавить это правило то ВПН соединение начинает подниматься но не авторизуется, уже писал выше как это происходит.
С этим правилом ип адреса на проксе отображаются верно.
>>172.16.25.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
>или
>>172.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 eth0
>явно какая-то лишняяПервая запись пишется автоматически, т.к. я получаю ип адрес и маску с дхцп провайдера.
А вторая это уже в ручном режиме добавлена, т.к. необходимо все эти адреса маршрутизировать именно туда.
>>>172.16.25.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
>>или
>>>172.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 eth0
>>явно какая-то лишняя
>
>Первая запись пишется автоматически, т.к. я получаю ип адрес и маску с
>дхцп провайдера.
>А вторая это уже в ручном режиме добавлена, т.к. необходимо все эти
>адреса маршрутизировать именно туда.тогда как я понимаю следующие маршруты тоже добавлены в ручную
>192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
>10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0это в корне не верно, провайдер выдал вам ИП и маску, это должно быть в маршруте,
а о маршрутах других подсетей заботится провайдер и пользователи этих (других) подсетей должны прийти к вам на 172.16.25.71следующее утверждение мне непонятно
>ppp0 это ВПН соединение к серверу провайдера, которое поднимается на роутере для доступа к
>пиринговым сетям других провайдеров, а также это соединение является наземкой для спутника.так как дефолтный маршрут у вас на eth0
>0.0.0.0 172.16.25.1 0.0.0.0 UG 0 0 0 eth0то все запросы не пренадлежащие подсети 62.106.104.1/32 будут отправлятся через eth0 а не через ррр0
и если это наземка для спутника - где интерфейс спутника? (видимо я что-то не догнал:))
зачит так, убирайте все маршруты добавленные в ручную (вы ж на железке их не добавляли?)
в таблицу НАТ
iptables -t nat -A POSTROUTING -o ! eth1 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -d 172.16.25.71 --dport 8080 -j DNAT --to-destination 10.10.4.90
таким образом мы маскарадим всё, что уходит от вас по eth0 и ррр0 т.е. ваша подсеть 10.10.4.0/24 сможет нормально ходить в сеть провайдера
и все кто придёт к вам на проксю из сети провайдера будут отправлены на внутренний (скрытый) сервер
пользователи подсети 10.10.4.0/24 должны ходить на проксю по прямому ИП - 10.10.4.90
так будет правильней
надеюсь что больше "подводных камней" нет
>это в корне не верно, провайдер выдал вам ИП и маску, это
>должно быть в маршруте,
>а о маршрутах других подсетей заботится провайдер и пользователи этих (других) подсетей
>должны прийти к вам на 172.16.25.71Какразтаки нет, эти адреса недоступны если их гнать через ВПН, провайдер об этом не заботится.
>так как дефолтный маршрут у вас на eth0
>>0.0.0.0 172.16.25.1 0.0.0.0 UG 0 0 0 eth0
>
>то все запросы не пренадлежащие подсети 62.106.104.1/32 будут отправлятся через eth0 а
>не через ррр0Чуть выше деволтный маршрут для ppp0 если приглядеться ;) и все ходит через ppp0
>и если это наземка для спутника - где интерфейс спутника? (видимо я
>что-то не догнал:))Если не имели дела со спутником то думаю безсмыссленно объяснять.
Спутник стоит на машине под виндой.>
>зачит так, убирайте всеСпасибо большое за этот ценный совет.
Оказывается бывает полезно убить все и выстроить заново.Вопщем виной всему оказалось правило
iptables -t nat -A PREROUTING -p tcp --dport 1723 -j DNAT --to-destination 10.10.4.90:1723
которое я использовал для того чтобы люди из сети провайдера могли установить ВПН с моим сервером.
>Вопщем виной всему оказалось правило
>iptables -t nat -A PREROUTING -p tcp --dport 1723 -j DNAT --to-destination
>10.10.4.90:1723
>которое я использовал для того чтобы люди из сети провайдера могли установить
>ВПН с моим сервером.Для корректной работы нужно было указать интерфейс.
iptables -t nat -A PREROUTING -i ! eth1 -p tcp --dport 1723 -j DNAT --to-destination 10.10.4.90:1723С таким правилом все замечательно работает.
Спасибо огромное всем за помощь, надеюсь больше не понадобится ;)
>С таким правилом все замечательно работает.
>Спасибо огромное всем за помощь, надеюсь больше не понадобится ;)ну дай бог, что б у вас в будующем всё работало
если вот это, тоже прикрученное в ручную, вы назаваете маршрутом.....
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
тагда понятно почему всё остальное прикручено в ручную
я смотрю у вас и спутник прикручен через задний проходвы такой умный, ... пришли сюда за такой мелочью, как правильно сделать нат\днат, извините нас тупоголовых
>[оверквотинг удален]
>0.0.0.0 0.0.0.0
> 0.0.0.0
> U 0
> 0
> 0 ppp0
>тагда понятно почему всё остальное прикручено в ручную
>я смотрю у вас и спутник прикручен через задний проход
>
>вы такой умный, ... пришли сюда за такой мелочью, как правильно сделать
>нат\днат, извините нас тупоголовыхОткуда столько гнева?
Спутник стоит на винде только по тому что провайдер skydsl не может работать под другими ОС.
Ваще зря я про него сказал наверно, у меня инет через ppp0 заблокирован для всех и разрешен только для 10,10,4,90 чтобы у спутника был исходящий канал.По поводу ВПН ваще не стал разибираться почему не сработал defaultoute в конфиге, просто дописал в скрипт поднятия еще прописываение маршрута.
ПС: Дистрибутив ubuntu так если че ))
>Ваще зря я про него сказал наверно, у меня инет через ppp0
>заблокирован для всех и разрешен только для 10,10,4,90 чтобы у спутника
>был исходящий канал.
>
>По поводу ВПН ваще не стал разибираться почему не сработал defaultoute в
>конфиге, просто дописал в скрипт поднятия еще прописываение маршрута.
>
>ПС: Дистрибутив ubuntu так если че ))вы б с этого начали, это какраз корень вашей проблемы
можете не разбираться почему не сработал defaultoute а сделать это в ручную, но правильно
после поднятия ВПН удалить тот, что увас есть
route del default gw 172.16.25.1 dev eth0добавить нужный
route add default gw 62.106.104.1 dev ppp0
если не ошибаюсь, то именно этот ИПдля того что б ваша подсеть могла ходить в провайдерскую делаем маршрут
route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.16.25.71 dev eth0
этим мы рассказали, что подсети в указанном диапазоне искать за eth0 с ИП 172.16.25.71
и ваша подсеть пойдёт не по дефолтному маршруту через ВПН, а через eth0
тоже сделайте для 192.168.0.0 и 10.0.0.0
правила нат/днат я уже писалдля того, что б через ррр0 не могли ходить чужие а только те кто вам нужен
рулите через iptables в цепочке FORWARD
http://www.opennet.me/docs/RUS/iptables/index.htmlя подозреваю у вас там по дефолту политика всё разрешено, это необходимо изменить
пожалуйста растолкуйте мне, дураку, зачем поднимать ВПН сервер у себя в подсети
зачем нужна ета дополнительная заморочка, когда без него всё довольно просто решается
>
>пожалуйста растолкуйте мне, дураку, зачем поднимать ВПН сервер у себя в подсети
>
>зачем нужна ета дополнительная заморочка, когда без него всё довольно просто решается
>Почитал ваш разговор и вот мне тоже стало непонятно зачем поднимать ВПН сервер, для доступа разных подсетей на один прокси? Мне тоже объясните! %)
Нет я серьезно! Не могу понять какие данные вы будете шифровать, если у вы просто делаете доступ к вашему прокси? Или вы собрались шифровать IP пакеты на стадии "ASK SYN"? Но тогда зачем? Чтобы их никто не мог перехватить? Если так, то это не возможно т.к. пакеты проходящие "ASK SYN" не шифруются т.к. это не имееет смысла... И вообще както у вас все странно особенно та таблица о которой говорил Oyyo "0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0" -- типа маршрут ИЗ ВСЕГО ВО ВСЕ и ДЛЯ ВСЕГО ?? %))
В общем я загнан в тупик, черт помогите! %)