URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 85429
[ Назад ]

Исходное сообщение
"Создание туннеля из одной сети в другую"

Отправлено eax0r , 27-Май-09 08:17 
Что-то лыжи совсем не едут...
Есть сервер на 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.
Застрял, какую технологию использовать, чтобы стуннелировать клиентов в интернет. подсткажите.

Содержание

Сообщения в этом обсуждении
"Создание туннеля из одной сети в другую"
Отправлено Pahanivo , 27-Май-09 08:55 
>Что-то лыжи совсем не едут...

мазь надо правильно подбирать (а не вазелин)
>Есть сервер на 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.
>Застрял, какую технологию использовать, чтобы стуннелировать клиентов в интернет. подсткажите.

а причем вообще сдесь туннели???


"Создание туннеля из одной сети в другую"
Отправлено eax0r , 27-Май-09 09:44 
Прокси не подходит по причине того, что множество софта не может ходить через прокси. а файрволл, где настроен NAT не в нашем ведении. проблематично в организационном плане будет прописать доп адреса для NAT'a. плюс мне самому уже принципиально интересно обойтись собственными силами.

При использовании VPN (я mpd рассматривал) пользователи будут подключаться к серверу по адресу 10.1.2.77, распределяться по виртуальным сетевым интерфейсам (которые в конфиге указал), и им (клиентам) будут выдаваться соответствующие IP-адреса для этих виртуальных интерфейсов. использовать в качестве IP-адреса клиента 10.1.2.77, как я понимаю, нельзя. а любой другой адрес через NAT не пройдет.

а туннелями я называю все, где пакеты одного протокола инкапсулируются в другой =). даже технология http-proxy по моему мнение туннелирование, в ней же простой http пакет "вкладывается" в пакет протокола прокси и передается.


"Создание туннеля из одной сети в другую"
Отправлено reader , 27-Май-09 10:57 
тут играем, тут не играем, тут рыбу заворачивали, а в целом в инет хочется , еще 5 таких объяснений и станем понятно что у вас есть и чем можете рулить.

на 10.1.2.77 делаете NAT и подымаете dns , gateway_enable="YES", прописываете 10.1.2.77 у клиентов как шлюз и DNS, и спокойно ждете проверяющих


"Создание туннеля из одной сети в другую"
Отправлено eax0r , 27-Май-09 12:03 
>тут играем, тут не играем, тут рыбу заворачивали, а в целом в
>инет хочется , еще 5 таких объяснений и станем понятно что
>у вас есть и чем можете рулить.
>
>на 10.1.2.77 делаете NAT и подымаете dns , gateway_enable="YES", прописываете 10.1.2.77 у
>клиентов как шлюз и DNS, и спокойно ждете проверяющих

Если можно было бы сделать на сервере NAT, уж поверьте, я бы такой вопрос не задавал =).
сервер и клиенты находятся в разных подсетях (я это указывал), т.е. в различных коллизионных доменах, объединенных маршрутизатором, поэтому в качестве шлюза указать сервер (10.1.2.77) невозможно.
чем можем рулить, то это тем, что я описал - сервером и, конечно, клиентскими машинами.
а с проверяющими проблем нет. сами себя не накажем =)


"Создание туннеля из одной сети в другую"
Отправлено Square , 27-Май-09 12:16 
>Если можно было бы сделать на сервере NAT, уж поверьте, я бы
>такой вопрос не задавал =).
>сервер и клиенты находятся в разных подсетях (я это указывал), т.е. в
>различных коллизионных доменах, объединенных маршрутизатором, поэтому в качестве шлюза указать сервер
>(10.1.2.77) невозможно.
>чем можем рулить, то это тем, что я описал - сервером и,
>конечно, клиентскими машинами.

Домен коллизий не существует на уровне IP протокола. Домен коллизий в свичеванной сети ограничен шнуром между вашим компьютером и портом свича. Это так.. к слову...

А маршрутизатором который между этими сетями, вы управлять можете? Достаточно указать на нем шлюз по умолчанию- ваш сервер, и можно спокойно поднимать на сервере нат .. ну как выше вам уже написали...

Вообще, я не понимаю в чем заключается ваша проблема с mpd сервером. Ну выдали клиенту адрес из еще одной подсети,  ну преобразовали его тут же, на этом же сервере натом в 10.1.2.77, клиент вашел в инет.. проблема то где?? Вы вообще в курсе что такое НАТ?


"Создание туннеля из одной сети в другую"
Отправлено eax0r , 27-Май-09 13:11 
>Домен коллизий не существует на уровне 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, только с возможностью перескакивать через марщрутизатор.


"Создание туннеля из одной сети в другую"
Отправлено Pahanivo , 27-Май-09 13:18 
>[оверквотинг удален]
>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 сервер передает его обратно по цепочке
>клиенту.

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


"Создание туннеля из одной сети в другую"
Отправлено Square , 27-Май-09 13:33 
>[оверквотинг удален]
>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, только с возможностью перескакивать через марщрутизатор.

Жжоте товарищь :)


"Создание туннеля из одной сети в другую"
Отправлено eax0r , 27-Май-09 13:42 
Тоже спасибо, именно так и буду делать.
>Я только не понял что вы называете "МЭ_NAT". Просто NAT...

МЭ - межсетевой экран ака firewall =)
>>т.е. нужно что-то похожее на NAT, только с возможностью перескакивать через марщрутизатор.
>
>Жжоте товарищь :)

стараюсь =)



"Создание туннеля из одной сети в другую"
Отправлено Pahanivo , 27-Май-09 14:11 
>МЭ - межсетевой экран

плакаль пад сталом .....


"Создание туннеля из одной сети в другую"
Отправлено eax0r , 27-Май-09 13:37 
>Вообще, я не понимаю в чем заключается ваша проблема с mpd сервером.
>Ну выдали клиенту адрес из еще одной подсети,  ну преобразовали
>его тут же, на этом же сервере натом в 10.1.2.77, клиент
>вашел в инет.. проблема то где?? Вы вообще в курсе что
>такое НАТ?

а вот это уже ближе к теме. натить выданные адреса как-то даже не подумал.

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


"Создание туннеля из одной сети в другую"
Отправлено Pahanivo , 27-Май-09 13:12 
>а туннелями я называю все, где пакеты одного протокола инкапсулируются в другой
>=). даже технология http-proxy по моему мнение туннелирование, в ней же
>простой http пакет "вкладывается" в пакет протокола прокси и передается.

мдааа с терией полный псдес
прокси к туннелированию не имеет никакова отношения и наоборот


"Создание туннеля из одной сети в другую"
Отправлено eax0r , 27-Май-09 13:19 
>прокси к туннелированию не имеет никакова отношения и наоборот

пусть будет так, не против. я бы поспорил, но не в этой теме.
а по существу?


"Создание туннеля из одной сети в другую"
Отправлено Pahanivo , 27-Май-09 14:10 
>>прокси к туннелированию не имеет никакова отношения и наоборот
>
>пусть будет так, не против. я бы поспорил, но не в этой
>теме.
>а по существу?

по существу - изучайте теорию