Что-то лыжи совсем не едут...
Есть сервер на FreeBSD 6.2. Находится он в подсети, назовем, 10.1.2.0/24. Данный сервер имеет доступ в интернет через NAT. У этого сервера всего один интерфейс - 10.1.2.77.
Есть простые рабочие станции в подсети 10.2.1.0/24, которые через NAT в интернет ходить не могут. Задача выпустить эти рабочие станции через сервер в интернет.
Конечно, перевое, что можно сделать, поставить proxy-сервер, но не хочется ограничиваться одним прикладным уровнем сети. Сконфигурировать NAT и разрешить рабочим станциям через него ходить нельзя! Если поднимать VPN, то придется же выдавать какие-то новые IP-адреса клиентам, а адрес, которому разрешено ходить через NAT только один - 10.1.2.77.
Застрял, какую технологию использовать, чтобы стуннелировать клиентов в интернет. подсткажите.
>Что-то лыжи совсем не едут...мазь надо правильно подбирать (а не вазелин)
>Есть сервер на FreeBSD 6.2. Находится он в подсети, назовем, 10.1.2.0/24. Данный
>сервер имеет доступ в интернет через NAT. У этого сервера всего
>один интерфейс - 10.1.2.77.
>Есть простые рабочие станции в подсети 10.2.1.0/24, которые через NAT в интернет
>ходить не могут.why not?
>Задача выпустить эти рабочие станции через сервер в
>интернет.
>Конечно, перевое, что можно сделать, поставить proxy-сервер, но не хочется >ограничиваться одним прикладным уровнем сети. Сконфигурировать NAT и разрешить рабочим >станциям через него
>ходить нельзя!why why why not?
>Если поднимать VPN, то придется же выдавать какие-то новые
>IP-адреса клиентам, а адрес, которому разрешено ходить через NAT только один
>- 10.1.2.77.
>Застрял, какую технологию использовать, чтобы стуннелировать клиентов в интернет. подсткажите.а причем вообще сдесь туннели???
Прокси не подходит по причине того, что множество софта не может ходить через прокси. а файрволл, где настроен NAT не в нашем ведении. проблематично в организационном плане будет прописать доп адреса для NAT'a. плюс мне самому уже принципиально интересно обойтись собственными силами.При использовании VPN (я mpd рассматривал) пользователи будут подключаться к серверу по адресу 10.1.2.77, распределяться по виртуальным сетевым интерфейсам (которые в конфиге указал), и им (клиентам) будут выдаваться соответствующие IP-адреса для этих виртуальных интерфейсов. использовать в качестве IP-адреса клиента 10.1.2.77, как я понимаю, нельзя. а любой другой адрес через NAT не пройдет.
а туннелями я называю все, где пакеты одного протокола инкапсулируются в другой =). даже технология http-proxy по моему мнение туннелирование, в ней же простой http пакет "вкладывается" в пакет протокола прокси и передается.
тут играем, тут не играем, тут рыбу заворачивали, а в целом в инет хочется , еще 5 таких объяснений и станем понятно что у вас есть и чем можете рулить.на 10.1.2.77 делаете NAT и подымаете dns , gateway_enable="YES", прописываете 10.1.2.77 у клиентов как шлюз и DNS, и спокойно ждете проверяющих
>тут играем, тут не играем, тут рыбу заворачивали, а в целом в
>инет хочется , еще 5 таких объяснений и станем понятно что
>у вас есть и чем можете рулить.
>
>на 10.1.2.77 делаете NAT и подымаете dns , gateway_enable="YES", прописываете 10.1.2.77 у
>клиентов как шлюз и DNS, и спокойно ждете проверяющихЕсли можно было бы сделать на сервере NAT, уж поверьте, я бы такой вопрос не задавал =).
сервер и клиенты находятся в разных подсетях (я это указывал), т.е. в различных коллизионных доменах, объединенных маршрутизатором, поэтому в качестве шлюза указать сервер (10.1.2.77) невозможно.
чем можем рулить, то это тем, что я описал - сервером и, конечно, клиентскими машинами.
а с проверяющими проблем нет. сами себя не накажем =)
>Если можно было бы сделать на сервере NAT, уж поверьте, я бы
>такой вопрос не задавал =).
>сервер и клиенты находятся в разных подсетях (я это указывал), т.е. в
>различных коллизионных доменах, объединенных маршрутизатором, поэтому в качестве шлюза указать сервер
>(10.1.2.77) невозможно.
>чем можем рулить, то это тем, что я описал - сервером и,
>конечно, клиентскими машинами.Домен коллизий не существует на уровне IP протокола. Домен коллизий в свичеванной сети ограничен шнуром между вашим компьютером и портом свича. Это так.. к слову...
А маршрутизатором который между этими сетями, вы управлять можете? Достаточно указать на нем шлюз по умолчанию- ваш сервер, и можно спокойно поднимать на сервере нат .. ну как выше вам уже написали...
Вообще, я не понимаю в чем заключается ваша проблема с mpd сервером. Ну выдали клиенту адрес из еще одной подсети, ну преобразовали его тут же, на этом же сервере натом в 10.1.2.77, клиент вашел в инет.. проблема то где?? Вы вообще в курсе что такое НАТ?
>Домен коллизий не существует на уровне IP протокола. Домен коллизий в свичеванной
>сети ограничен шнуром между вашим компьютером и портом свича. Это так..
>к слову...Никто с этим и не спорит.
>Если у вас есть физическая возможность включения сервера в вашу подсеть
>рабочих станций - то на него можно повесить алиасы - несколько
>адресов из разных подсетей на один сетевой интерфейс. Это первый момент.
>Второй момент заключается в том, что если вы, используете маршрутизатор - то
>значит необходимо настроить его так, чтобы шлюз по умолчанию
>был указан как адрес вашего сервера. На котором будет происходить преобразование
>нат, и выход в инет.Опять же. поверьте наслово, за рамки поставленных условий, к сожалению, выйти нельзя. не возможности что-либо менять кроме настроек сервера и клиентов.
я себе схему представляю так:
клиент <---> роутер <---> сервер <---> МЭ_NAT <---> Интернет.
Клиент соединяется с mail.ru:
1. формирует IP-пакет. src_IP - client_ip, dest_IP - mail.ru_ip
2. этот пакет запаковывается в другой IP-пакет, где src_IP - client_ip, dest_IP - 10.1.2.77
3. пакет из п. 2 отправляет к серверу (10.1.2.77) через роутер естественно
4. сервер принимает пакет, распаковывает (получается IP-пакет как в п. 1)
5. сервер подменяет src_IP в полученном пакете на свой и отправляет на mail.ru_IP
6. далее через МЭ_NAT и в интернет
7. при получении ответа от mail.ru сервер передает его обратно по цепочке клиенту.т.е. нужно что-то похожее на NAT, только с возможностью перескакивать через марщрутизатор.
>[оверквотинг удален]
>2. этот пакет запаковывается в другой IP-пакет, где src_IP - client_ip, dest_IP
>- 10.1.2.77
>3. пакет из п. 2 отправляет к серверу (10.1.2.77) через роутер естественно
>
>4. сервер принимает пакет, распаковывает (получается IP-пакет как в п. 1)
>5. сервер подменяет src_IP в полученном пакете на свой и отправляет на
>mail.ru_IP
>6. далее через МЭ_NAT и в интернет
>7. при получении ответа от mail.ru сервер передает его обратно по цепочке
>клиенту.из всего понятно одно - автор понабрался умных слов, а что они означают узнать к сожалению не удосужился ...
>[оверквотинг удален]
>2. этот пакет запаковывается в другой IP-пакет, где src_IP - client_ip, dest_IP
>- 10.1.2.77
>3. пакет из п. 2 отправляет к серверу (10.1.2.77) через роутер естественно
>
>4. сервер принимает пакет, распаковывает (получается IP-пакет как в п. 1)
>5. сервер подменяет src_IP в полученном пакете на свой и отправляет на
>mail.ru_IP
>6. далее через МЭ_NAT и в интернет
>7. при получении ответа от mail.ru сервер передает его обратно по цепочке
>клиенту.Если вы поднимите на сервере нат и mpd - оно примерно так и будет работать.
Только src_IP - client_ip в пункте 1- это виртуальный адрес выданный мпд сервером,
а в пункте 2 src_IP - client_ip - это адрес физический, интерфейса сети 10.2.1.0/24
а src_IP в 5 пункте - это опять же виртуальный адрес вашего клиента которы йон получил как уже было сказано выше- от МПД...Я только не понял что вы называете "МЭ_NAT". Просто NAT...
>т.е. нужно что-то похожее на NAT, только с возможностью перескакивать через марщрутизатор.
Жжоте товарищь :)
Тоже спасибо, именно так и буду делать.
>Я только не понял что вы называете "МЭ_NAT". Просто NAT...МЭ - межсетевой экран ака firewall =)
>>т.е. нужно что-то похожее на NAT, только с возможностью перескакивать через марщрутизатор.
>
>Жжоте товарищь :)стараюсь =)
>МЭ - межсетевой экранплакаль пад сталом .....
>Вообще, я не понимаю в чем заключается ваша проблема с mpd сервером.
>Ну выдали клиенту адрес из еще одной подсети, ну преобразовали
>его тут же, на этом же сервере натом в 10.1.2.77, клиент
>вашел в инет.. проблема то где?? Вы вообще в курсе что
>такое НАТ?а вот это уже ближе к теме. натить выданные адреса как-то даже не подумал.
И убедительная прозьба ко всем. внимательно! читайте, что другие пишут. и все четкие замечания оставляйте с аргументами, пожалуйста.
>а туннелями я называю все, где пакеты одного протокола инкапсулируются в другой
>=). даже технология http-proxy по моему мнение туннелирование, в ней же
>простой http пакет "вкладывается" в пакет протокола прокси и передается.мдааа с терией полный псдес
прокси к туннелированию не имеет никакова отношения и наоборот
>прокси к туннелированию не имеет никакова отношения и наоборотпусть будет так, не против. я бы поспорил, но не в этой теме.
а по существу?
>>прокси к туннелированию не имеет никакова отношения и наоборот
>
>пусть будет так, не против. я бы поспорил, но не в этой
>теме.
>а по существу?по существу - изучайте теорию