Вход:  Пароль:  
FreeSource: Статьи/НастройкаСети/ОрганизацияТуннелей ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Это старая версия Статьи/НастройкаСети/ОрганизацияТуннелей за 2005-08-19 15:42:29..

Оглавление документа

Оглавление документа Статьи/НастройкаСети/FirewallДляТуннелей?


Кстати, всё что здесь описано, делалось, если не сказано дополнительно, под altlinux sisyphus. И всё ещё работает на моих машинах :)

Вводная: для чего вообще нужны туннели?

Небольшое описание

Вообще туннель, это по сути отдельный виртуальный провод, протянутый от одного peer'а к другому.
Чем это хорошо: между peer'ами могут идти море маршрутизаторов, но в туннеле они не видны. Для машин-peer'ов туннель является физической средой передачи, а значит противоположный конец туннеля можно прописывать в таблицу маршрутизации. В итоге трафик, завёрнутый в туннель, может выходить где-нибудь в америке (смех смехом, а при спутниковом доступе так и происходит), а возвращаться обсолютно другим маршрутом – маршрут возврата зависит от ip-источника. В этом туннели очень похожи на прокси.

Отличия туннелей от прокси:


Схожесть:

Пример применения

Например задача: исходящий трафик посылать по земле, ответы принимать через спутник. (Для Настройки спутника см. Sky Star 2?)
То есть, трафик исходит с вашего интернет-интерфейса, идёт по одному маршруту к назначению, а приходит по другому и на другой интерфейс.


Как происходит маршрутизация? Трафик в одну сторону дойдёт по ip-назначению. Обратно он будет идти также по ip-назначения, только он будет уже вашим ip (при ответе ip сменяться местами). Значит надо послать пакет с ip-источником от провайдера, что зарулит трафик к вам. Какие могут быть здесь проблемы: провайдер не будет выдавать тысячи ip каждому, чтобы они ставили его для ответа. Да и те же продукты от MS тяжело будет таким образом отстроить.


Какая тут на самомо деле проблема: маршруты не прохдят через спутникового оператора, они могу идти как угодно. Если бы они проходили через него, то с помощью SNAT можно ответ получать на оператора а затем на пользователя. SANT там делается (не совсем удобно: в итоге с одного ip качают тысячи поьзователей, что не на всех сайтах разрешается :)


Вот для организации прохождения всего наземного трафика через спутникового оператора самое то использовать либо прокси, либо туннели. Поднимаем туннель, указываем его маршрутом по умолчанию – и всеь трафик будет сначала идти оператору, а потом куда надо. Ответ тоже пройдёт через него, а далее по спутнику.


Меня тут просили организовать success story по работе и настройке туннелей. Ну что ж, вот вам роман: примеры применения туннелей

Типы туннелей

Есть два типа туннелей:


Ну, если постараться, можно сваять туннель и прикладного уровня: через http протокол например через тот же прокси. google it: httptunnel, proxytunnel. Но, как и ssh port-forwaring, это не туннели 1 Хотя иного без них никуда :) 2


Где-то тут наверное можно прислонить и vlan, только с ними я пока не сталкивался, знаю лишь что ьам в существующей сетевой стреде организуется дополнительная вирутуальная. В отличие от туннелей позволяет организовать не только соединение точка-точка, но и реальную сеть с broadcast'ами и всем остальным. Рабоет на сетевом уровне


Есть туннели PPPoE – point-to-point over ethernet. Что это такое я так пока и не понял, наверное потому что опять не использовал. Куда их отнести – понятия не имею. Жду подсказки :)

Туннели сетевого уровня

Что ето такое

Это ipip и ip_gre туннели. Может и ещё что-то есть: я с ними пока не работал. Как они выглядят вживую:


Если посмотреть, то видно, что IP повторяется два раза, ip заголовки тоже. В принципе туннели так и работают: в ip пакет вместо tcp пакета (или udp, icmp, или что там ещё есть) заворачивается ещё один ip пакет, а в поле «протокол» в пакете вместо 6 для tcp, 1 для icmp ставится 47 для gre и 94 для ipip (номера протоколов находятся в файле /etc/protocols. если поискать под offtopic'ом, то там тоже наверняка найдтся такой файлик: services есть, почему бы и не быть protocols :)


Туннели транспортного уровня работают точно также, только туннельный ip пакет со всеми своими данными заворачивается в tcp пакет. То есть организуется обычное подключение и в tcp поток льется ip траффик.

Настройка

Ну, это наверно проще поискать.
Вкратце ручками это делается следующим образом:

ну, и осталось добавить нужные вам маршрутизаторы.
Для ipip тоже самое, только меняется mode

IPSEC туннель

ipsec, как я понял, может работать в двух режимах: простая шифрация нужного трафика (скажем от одного порта к дргому), и в туннельном, в котором нужно будет прописать отдельную подсеть.


Вообще ipsec это отдельный разговор?, я взялся за него только недавно, поэтому пока оставим так. пусть кто-нить опишет – буду благодарен. Всё равно мне его ещё реализовывать.

Туннели транспортного уровня

Туннели транспортного уровня работают точно также как и сетевого, только туннельный ip пакет со всеми своими данными заворачивается в tcp пакет. То есть организуется обычное подключение и в tcp поток льется ip траффик. Для udp, как всегда, подключение надо организовывать самому. Но принцип тот же.


В принципе туннель можно сделать хоть через icmp протокол, благо в ip заголовке указывается полная длина пакета с icmp + какие надо прописать данные. а ведь icmp пакеты обычно пропускаются на маршрутизаторах... Хотя могу обрадовать – никто не мешает в firewall'е настроить блокировку на длину icmp пакета :))


Какие есть реализации:


Требует написания :)

PPTP

PPPoE

PPP over SSH 

Прекрасно настраивается по VPN PPP-SSH Mini-HOWTO. Когда у меня встала задача выйти через прокси в irc, imap мне как раз пришлось настроить Ppp Туннель Через Proxy?, где и был реализован такой туннель.


Если вкратце, то мне оттуда понадобилась лишь команда

которую я и взял из этого HOWTO (The vpn-pppssh Script). Это была строчка


К этому времени всё, что описывалос предварительно в этом HOWTO у меня уже было готово:

vtund

Замечания

1 Рядом в Firewall Для Туннелей? мне отметили ещё и ssh port-forwarding. httptunnel, proxytunnel тоже реализуют port-forwarding. И это не более чем port-forwarding – в маршрут его не пропишешь, необходимо поднимать тот же ppp over cat по этим портам, icmp не проходит. То есть для каждого подключения придётся делать порт-форвардинг: imap, irc, и что мне ещё взбредёт в голову. А если я по nfs подключаюсь? тут даже не отфорвардишь: портов ипользуется разом несколько, да и ещё какая-то чать на udp.


Так что для защиты службы это – самое то (вместо того же stunnel), а вот для организации туннеля – нет :)


У меня была ещё ситуация, в которой бы никакой ssh port-forwarding не спас. Как и ppp over ssh – пришлось добавлять дополнительный транспорт :) 2


2 Ppp Туннель Через Proxy?



 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]