>В отличии от Tor, Tarzan основан на peer-to-peer архитектуре.
Вот этой разницы я не уловил. В Tor центральные серверы используются только для подтверждения подлинности ключей, а путь всё равно определяется инициатором соединения от начала до конца.
Если бы первая задача была бы сформулирована навроде «какие карточки нужно перевернуть, что бы проверить, что карта с гласной буквой имеет на обороте чётное число», тоесть синтаксически идентично втрой задаче, то возможно, здесь бы и не всплыла такая армада людей, не понимающих условия задачи из-за запутанной формулировки. С таким же успехом, можно было сформулировать вторую задачу в терминах говорящих кактусов, и дальше пудрить людям мозг, что на самом деле нам проще решать задачи, в которых есть говорящие кактусы.
Представляю как трансляцию адреса назначения GRE пакета, идущего из outside в inside. В в ситуации, когда трансляцию надо осуществлять только для PPTP сервера ничего сложного нет, создаётся просто одно правило и всё, проблемы возникают когда появляются PPTP клиенты, которые из inside в outside подключаются. Для наглядности немного графики — PPTP_server---+
|
+--router----- |
PPTP_client----+
Так вот, допустим адрес PPTP сервера в локальной сети 10.1.0.2, а адрес клиента 10.1.0.3. Пускай, существует правило для NAT, транслирующие внешний адрес маршрутизатора(в данном случае он осуществляет трансляцию) на адрес 10.1.0.2. Пока всё работает, клиенты из outside вполне могут работать с данным сервером.
Теперь клиент PPTP инициирует подключение к некоему серверу из outside, этот сервер посылает ответный GRE пакет, но когда данный пакет достигает маршрутизатора, адрес назначения транслируется не в адрес PPTP клиента, а в адрес PPTP сервера, поэтому клиент не получает ответа, а сервер получает неожиданный для себя ответ откуда-то.
Вот такая ситуация возникла у меня при использовании iptables в линуксе, но она решилась установкой специально для этой ситуации разработанного драйвера(не мной разработанного, разумеется). В устройствах Linksys, такая проблема решается какой-то специальной опцией, связанной с PPTP, но у неё есть свои недоработки — если сервер из outside — это зеркальное отображение нашей локальной сети, тесть то же содержит PPTP сервер и клиентов, которые подключаются к нашей inside сети, то маршрутизатору тут сносит крышу. Вооооот. Поэтому и интересно, что для решения данной проблемы есть у IOS в рукаве.
Спасибо за статью, но у меня тут вопрос не по теме:
Можно ли в IOS 12.3(в частности) настроить NAT для протокола GRE таким образом, что бы нормально сосуществовали PPTP сервер(inside global адрес транслируется) и PPTP клиентами из этой же локальной сети, подключающимися к внешним PPTP серверам?
Причём тут BSD. Xen построен на концепции гипервизора — для него любая ОС виртуальная. Dom0 просто имеет возможность обращаться к устройствам ввода/вывода. Через запросы к гипервизору(hypercalls), кстати.
Есть достаточно старое исследование(2003 год) The Art of Virtualization там Xen в одном из тестов успешно справлялся с 128-ю доменами.
Наличие аппаратной виртуализации ещё не значит наличие VT-d. Плюс поддержка чипсета должна быть, есть у Q35 и ещё каких-то. Читать про pci passthrough. И повторяю, возможность чисто теоретическая, о успехах на практике я не слышал.
С другой стороны, зачем использовать Xen, можно просто на Windows поставить либо VMware Workstation/Server или VirtualBox и запускать на нём что угодно, но уже без аппаратного ускорения видео. На Windows оно останется, и не надо никаких дополнительных видеокарт.
Продвижения в сторону поддержки виртуальной машиной DirectX, кажется(кажется) есть только у VMware в Fusion(OS X) и Workstation 6.5. Для Xen есть ещё хитрый патч для виртуалки с Linux для поддержки OpenGL, но он для Linux.
Для BSD есть какие-то патчи на ядро, но официально это не поддерживается. В принципе, какая разница какая ОС является хостовой — единственная её задача предоставлять виртуальным машинам доступ к устройствам ввода/вывода.
VMware Server и Workstation устанавливается только на Linux или Windows.
1. Разворачивай VNC на весь рабочий стол.
2. Выше писал — теоретически возможно, но виртуальной машине надо отдавать в пользование видяху. Значит, она не будет доступна ни хостовой операционке, ни другим виртуальным машинам. Плюс нужно иметь процессор с VT-d(IOMMU у AMD, но появится только в конце 2009), и чипсет материнской платы, поддерживающей данную технологию.
3. Если нет специфических требований к железу — любая подойдёт.
Вывод — если тяга к играм непреодолима — купи консоль.
Вполне внятная документация поставляется с каждым из названных здесь продуктов, прочитав её можно без проблем создать рабочую виртуальную машину.
На производительность виртуальных машин можно глядеть с разных сторон. Производительность процессора и памяти практически не падает. Основная проблема — это устройства ввода/вывода. Основные представители — сетевые адаптеры и дисковые накопители. Если образ жёсткого диска создаётся как объект файловой системы хостовой виртуальной машины, то потери будут весьма значительными. Ситуация улучшается при использовании паравиртуальных драйверов для виртуальных машин, в продуктах VMware это VMware Tools, в Xen для Windows существуют драйвера для диска и сетевой карты которые разрабатываются под GPL. Практически нулевые потери при использовании паравиртуализации, но это возможно только на модифицированных ОС. На хостовой операционке нет нужды оставлять dns и dhcp — прекрасно будут работать и на виртуальной машине. Чем меньше будет задач на ней, тем надёжнее будет вся система.
Мы год назад начинали.
У нас кроме дружеских связей еще анализируется количество сообщений на стенах (жирностью линий отмечено в графе).
Проект тоже открытый.
В Питере есть такой стартап — Green Light
Вот этой разницы я не уловил. В Tor центральные серверы используются только для подтверждения подлинности ключей, а путь всё равно определяется инициатором соединения от начала до конца.
|
+--router----- |
PPTP_client----+
Так вот, допустим адрес PPTP сервера в локальной сети 10.1.0.2, а адрес клиента 10.1.0.3. Пускай, существует правило для NAT, транслирующие внешний адрес маршрутизатора(в данном случае он осуществляет трансляцию) на адрес 10.1.0.2. Пока всё работает, клиенты из outside вполне могут работать с данным сервером.
Теперь клиент PPTP инициирует подключение к некоему серверу из outside, этот сервер посылает ответный GRE пакет, но когда данный пакет достигает маршрутизатора, адрес назначения транслируется не в адрес PPTP клиента, а в адрес PPTP сервера, поэтому клиент не получает ответа, а сервер получает неожиданный для себя ответ откуда-то.
Вот такая ситуация возникла у меня при использовании iptables в линуксе, но она решилась установкой специально для этой ситуации разработанного драйвера(не мной разработанного, разумеется). В устройствах Linksys, такая проблема решается какой-то специальной опцией, связанной с PPTP, но у неё есть свои недоработки — если сервер из outside — это зеркальное отображение нашей локальной сети, тесть то же содержит PPTP сервер и клиентов, которые подключаются к нашей inside сети, то маршрутизатору тут сносит крышу. Вооооот. Поэтому и интересно, что для решения данной проблемы есть у IOS в рукаве.
Можно ли в IOS 12.3(в частности) настроить NAT для протокола GRE таким образом, что бы нормально сосуществовали PPTP сервер(inside global адрес транслируется) и PPTP клиентами из этой же локальной сети, подключающимися к внешним PPTP серверам?
Есть достаточно старое исследование(2003 год) The Art of Virtualization там Xen в одном из тестов успешно справлялся с 128-ю доменами.
С другой стороны, зачем использовать Xen, можно просто на Windows поставить либо VMware Workstation/Server или VirtualBox и запускать на нём что угодно, но уже без аппаратного ускорения видео. На Windows оно останется, и не надо никаких дополнительных видеокарт.
VMware Server и Workstation устанавливается только на Linux или Windows.
2. Выше писал — теоретически возможно, но виртуальной машине надо отдавать в пользование видяху. Значит, она не будет доступна ни хостовой операционке, ни другим виртуальным машинам. Плюс нужно иметь процессор с VT-d(IOMMU у AMD, но появится только в конце 2009), и чипсет материнской платы, поддерживающей данную технологию.
3. Если нет специфических требований к железу — любая подойдёт.
Вывод — если тяга к играм непреодолима — купи консоль.
На производительность виртуальных машин можно глядеть с разных сторон. Производительность процессора и памяти практически не падает. Основная проблема — это устройства ввода/вывода. Основные представители — сетевые адаптеры и дисковые накопители. Если образ жёсткого диска создаётся как объект файловой системы хостовой виртуальной машины, то потери будут весьма значительными. Ситуация улучшается при использовании паравиртуальных драйверов для виртуальных машин, в продуктах VMware это VMware Tools, в Xen для Windows существуют драйвера для диска и сетевой карты которые разрабатываются под GPL. Практически нулевые потери при использовании паравиртуализации, но это возможно только на модифицированных ОС. На хостовой операционке нет нужды оставлять dns и dhcp — прекрасно будут работать и на виртуальной машине. Чем меньше будет задач на ней, тем надёжнее будет вся система.