Кстати, всё что здесь описано, делалось, если не сказано дополнительно, под 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 это отдельный разговор?, я взялся за него только недавно, поэтому пока оставим так. пусть кто-нить опишет – буду благодарен. Всё равно мне его ещё реализовывать.
Туннели транспортного уровня работают точно также как и сетевого, только туннельный ip пакет со всеми своими данными заворачивается в tcp пакет. То есть организуется обычное подключение и в tcp поток льется ip траффик. Для udp, как всегда, подключение надо организовывать самому. Но принцип тот же.
В принципе туннель можно сделать хоть через icmp протокол, благо в ip заголовке указывается полная длина пакета с icmp + какие надо прописать данные. а ведь icmp пакеты обычно пропускаются на маршрутизаторах... Хотя могу обрадовать – никто не мешает в firewall'е настроить блокировку на длину icmp пакета :))
Какие есть реализации:
Требует написания :)
Прекрасно настраивается по VPN PPP-SSH Mini-HOWTO. Когда у меня встала задача выйти через прокси в irc, imap мне как раз пришлось настроить Ppp Туннель Через Proxy?, где и был реализован такой туннель.
Если вкратце, то мне оттуда понадобилась лишь команда
которую я и взял из этого HOWTO (The vpn-pppssh Script). Это была строчка
К этому времени всё, что описывалос предварительно в этом HOWTO у меня уже было готово:
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