Ретрансляторы Tor / узлы выхода под виртуальные машины
У меня есть платная подписка на Google Cloud Platform, и я хочу запустить ретранслятор Tor и выходить из узлов. Я использую квантовый объект / docker-tor-exit-relay изображения Docker, просто подключи и играй.
Вкратце, согласно полученным ответам:
- Конфигурация виртуальной машины g1-micro - самая дешевая альтернатива, но она может не работать так, как я хочу предложить при высокой производительности.
- Пользовательская виртуальная машина с 1 виртуальным ЦП и 1 ГБ ОЗУ, с обязательным использованием в течение 3 лет, представляется наиболее удобной и доступной.
- Выжимающий ВМ класс бесполезен.
- Несколько примеров за балансировщиком нагрузки - плохая идея.
Мое оригинальное обоснование
Поскольку виртуальные машины с упреждением намного дешевле, я хотел использовать группы экземпляров с виртуальными машинами с преимуществом. Затем, чтобы иметь узлы высокой доступности, я планирую использовать балансировщик нагрузки GCP, чтобы в любой момент времени работал только один IP-адрес и хотя бы одна виртуальная машина.
Кроме того, я изначально планировал использовать тип виртуальной машины g1-small (1/2 совместно используемого vCPU и 1,7 ГБ ОЗУ) для затрат, и я сравниваю его с другими альтернативами, такими как обычные виртуальные машины класса с "обязательным использованием" (которые применяют скидки).
инвестиции
Ниже приведены ориентировочные затраты на виртуальные машины (согласно калькулятору):
Config. | Class | vCPU | RAM | C. usage | Price/Mo
----------------------------------------------------------------
g1-micro | Regular | 0.2 | 600MB | Not set | US$3.88
g1-small | Preemptible | 0.5 | 1.70GB | Not set | US$5.11
g1-small | Regular | 0.5 | 1.70GB | Not set | US$13.80
n1-standard | Regular | 1 | 3.75GB | 3 years | US$15.60
Custom | Regular | 1 | 1GB | 3 years | US$11.78
Custom | Regular | 1 | 2GB | 3 years | US$13.17
vCPU - это Intel Xeon с частотой 2,3 ГГц, микроархитектура Haswell.
Кроме того, нам нужны расчетные затраты на исходящий трафик (с ежемесячной потребляемой пропускной способностью) (полезно для групп, а не для отдельных виртуальных машин):
BW | Zone 1 | Zone 2 | Zone 3 | Zone 4 | Price
-----------------------------------------------------
70GB | 40GB | 15GB | 5GB | 10GB | US$9.42
80GB | 80GB | 30GB | 10GB | 20 GB | US$19.27
350GB | 200GB | 75GB | 25GB | 50 GB | US$48.82
700GB | 400GB | 150GB | 50GB | 100 GB | US$98.07
Zone 1: Americas/EMEA
Zone 2: Asia/Pacific
Zone 3: Australia
Zone 4: China
Характеристики виртуальной машины
В настоящее время я тестирую виртуальную машину со следующей конфигурацией:
- 1 vCPU Inten Xeon @ 2,30 ГГц (Haswell)
- 1 ГБ ОЗУ
- Образ ОС: cos-stable-71-11151-71-0
- Ядро: ChromiumOS-4.14.74
- Кубернетес: 1.11.5
- Докер: 18.06.1
- Семья: cos-stable
- Образ докера: квантовый объект / докер-тор-выход-реле
- Скрипт запуска:
run -d -p 2222:22 -p 80:80 -p 9050:9050 -p 9001:9001 quantumobject/docker-tor-exit-relay
- ВМ класс: обычный
- Регион: США-Центральный1
Совет: Перейдите в сеть VPC > Брандмауэр и создайте правило под названием "allow-tor" и установите:
- Приоритет: 500 (что-либо ниже, чем по умолчанию 1000)
- Цели: указанные целевые теги
- Целевые теги: allow-tor
- Протоколы и порты: указанные протоколы и порты: "tcp:22,80,443,9001,9050"
При создании ВМ / шаблона перейдите в раздел "Управление", "Безопасность", "Диски", " Сеть", " Единоличное владение", выберите " Сеть" и установите тег, заданный в настройках брандмауэра.
эталонный тест
Также я запустил тест openssl (openssl speed aes
в течение 3 секунд каждый cbc) в экземпляре g1-small и Custom 1 GB RAM 1 vCPU, и я получил следующие результаты:
g1-мала:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128 cbc 102714.85k 114937.26k 118729.12k 119713.45k 120548.01k 120684.54k
aes-192 cbc 87781.72k 96917.15k 99274.67k 100145.83k 100463.96k 100515.84k
aes-256 cbc 76597.38k 83198.89k 84709.38k 85080.02k 85516.29k 85859.83k
Таможня:
aes-128 cbc 100811.34k 114144.42k 116054.50k 117985.42k 119586.42k
aes-192 cbc 85914.78k 95220.79k 98367.39k 98994.68k 99095.15k
aes-256 cbc 76171.38k 82969.05k 84497.50k 85145.08k 84728.69k
Производительность практически одинакова, возможно, потому что совместно используемый виртуальный ЦП получает полную мощность в определенные моменты времени, когда это необходимо, но не всегда, по сравнению с выделенным 1 виртуальным ЦП.
Мои вопросы:
Какой объем полосы пропускания рекомендуется для каждого экземпляра?
Безопасно ли запускать один или несколько узлов ретрансляции / выхода Tor за одним балансировщиком нагрузки в GCP?Нету.Безопасно / полезно ли запускать вытесняемые узлы, которые отключаются через 24 часа работы или меньше?(Назначение IP-адреса является динамическим, и тот же IP для нового узла не гарантируется)Безопасно, но бесполезно.Достаточно ли спецификаций виртуальных машин g1-micro или g1-small для работы узла с достойной производительностью?Кастомная 1 ГБ ОЗУ ВМ дешевле и мощнее.
Заранее спасибо.
2 ответа
Запуск нескольких вытесняемых узлов для избыточности - плохой план. Если приоритетные узлы работают в одном и том же регионе, они, скорее всего, будут закрыты одновременно из-за растущего спроса в этом регионе.
Скорее всего, вытесняющие узлы в разных регионах будут закрыты одновременно, но риск все еще существует и может зависеть от того, что делают другие клиенты GCE, что полностью находится вне вашего контроля.
Не используйте выгружаемые узлы, если вы заботитесь о доступности. Они подходят для пакетной обработки, где прерывание не представляет большой проблемы, и вы можете просто выполнить обработку позже.
Безопасно ли запускать вытесняемые узлы, которые отключаются через 24 часа работы или меньше? (Назначение IP-адреса является динамическим, и тот же IP для нового узла не гарантируется)
Безопасный? Конечно. Но вы никогда не увидите трафик к ним. Tor проверяет новые реле и выходные узлы здесь: жизненный цикл нового реле
По сути, любое новое реле "тестируется" более 60 дней, прежде чем оно увидит реальный трафик. Я могу ручаться, что это точно, поскольку я управлял эстафетой Tor около 2 лет. Вы вряд ли увидите какой-либо реальный трафик, если ваши узлы не будут использовать одни и те же идентификаторы при каждом перезапуске, и если ваш узел не сможет быть надежным, он, вероятно, будет размещен ниже в пищевой цепочке.
Кроме того, если узел переходит в автономный режим на длительное время, вам, возможно, придется пересмотреть эти периоды ожидания. Мое реле было в автономном режиме в течение 3 месяцев, так как я переехал в другие страны, и мне еще предстоит увидеть возвращение трафика к тому, что было раньше.
Вы можете увидеть, что Tor думает о вашем реле, посмотрев его на странице их метрик. Например, вот мой.
Достаточно ли спецификаций виртуальной машины g1 для работы высокопроизводительного узла?
Идея Tor о высокой производительности отличается от общего Интернета в целом. Например, я использую мой на довольно старом Intel NUC с довольно старым процессором Intel Celeron и большим количеством оперативной памяти, и он работает со скоростью около 70 Мбит / с - потому что это все, что OpenSSL может протолкнуть через процессор. 70 Мбит / с очень велико для ретранслятора Tor (возможно, не выходного узла). Я предполагаю, что даже обычная полу-современная небольшая виртуальная машина сможет опередить ее.