Пользователь
18,9
рейтинг
27 апреля 2014 в 20:13

Разработка → Изолирование приложения с IP-адресом из VPN другой страны на примере Steam tutorial

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

Традиционно, большая часть статьи будет посвящена теории, а скучные скрипты — в конце статьи. В качестве субъекта для экспериментов будет использоваться Steam, хотя написанное применимо к любому приложению, включая веб-браузеры.

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces


Традиционно, приложение, запускающееся даже с правами пользователя, имеет полный доступ в сеть. Оно может использовать любой сетевой адрес, существующий в системе для отправки пакетов.

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

В этих условиях возникает большое желание оставить один на один конкретное приложение и заданный сетевой интерфейс. Один. Сконфигурированный для нужд только этого приложения.

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:


Подобное изобилие конфигураций, конечно, не совсем десктоп, но зато позволит объяснить происходящее в чистом виде.

Разные namespace'ы выделены разными цветами. Указанные интерфейсы доступны только из указанных неймспейсов и никак иначе. Например, красный namespace имеет доступ только к tap1, veth1 и lo, синий — к eth1, eth2, lo и veth0, зелёный — к tun0 и lo. За пределами namespace'ов остаются eth0, собственный интерфейс br1, tap0 и lo.

Заметим, в каждом namespace'е свой lo! Если в синем namespace'е на lo будет слушать mysql, то из зелёного (и любого другого, кроме синего) namespace'а получить к нему доступ не удастся. Пожалуй, это самая приятная особенность. Вторая особенность — мы можем использовать один и тот же IP адрес в разных пространствах имён на разных интерфейсах, и нам за это ничего не будет. Разумеется, таблица маршрутизации у каждого пространства имён — своя.

Внимательный читатель почуял дух виртуализации. Разумеется, да. Network namespaces (вместе с остальными технологиями такого уровня) являются важной частью LXC (контейнерной виртуализации в линуксе). Но, в отличие от openvz и многих других схожих технологий, компоненты LXC настолько общие, что позволяют использовать их как самостоятельные инструменты. И это правильный unix-way: каждый делает только одну вещь, но хорошо; хотя пуристы могут сказать, что «пихать всё в ядро — плохо».

Наиболее интересной картинка получается, если оставить приложение с tun/tap интерфейсом, который ведёт за пределы текущей сети (на картинке выше — зелёный namespace c одиноким tun'ом). Если tun приземляется где-то за пределами компьютера (например, на vpn-сервере), то приложение не будет иметь никакой возможности понять, какие сетевые настройки реально у компьютера. Если VPN, например, ведёт с Кипра в Россию, то любое запущенное в зелёном namespace'е приложение будет получать адрес из России и выходить в сеть так, как будто оно находится в России. Собственно, это нам и требуется для того, чтобы Steam поверил, что у нас русский IP и согласился продавать игры за пол-цены.

С определением страны у Стима всё несколько странно. Без VPN Стим иногда показывает мне цены в евро, иногда в рублях, и понять закономерности я не смог. Русский VPN снял все вопросы — цены всегда в рублях.

Краткая подсказка по работе с network namespaces (практические советы ближе к концу статьи):
ip netns — список network namespaces (во всех командах ip netns можно сокращать до ip net)
ip netns add/delete foo — создать/удалить network namespace с именем foo
ip netns exec foo /usr/bin/bin — запустить программу в заданном network namespace (заметим, перетаскивать уже запущенные приложения нельзя)
ip link set eth99 netns foo — засунуть интерфейс в заданное пространство

И несколько трюков:

ip netns exec foo ip link — список интерфейсов внутри пространства foo
ip netns exec foo tcpdump -ni eth99 — tcpdump на нём. Внимание, из-за специфичной работы exec'а, вывод на экран появится только после нажатия Ctrl-C. Если раздражает — см ниже.
sudo ip netns exec foo login -f username — запустить логин внутри namespace'а. Залогинившийся пользователь будет работать уже в заданном пространстве имён с отлично сконфигурированными настройками терминала/лидера группы и т.д.

Организация VPN'а через SSH


Я не люблю openvpn, openswan и прочие приложения за избыточность. Я признаю их необходимость в некоторых ситуациях, но когда могу, я стараюсь использовать SSH. Причин несколько:
1) SSH есть из коробки на любом сервере.
2) SSH использует TCP, а не gre/udp, и если надо подключиться из экзотического места с хреновым WiFi, то ssh на 22 и 443 портах наше всё. Если 22ой порт ещё могут закрыть, то 443 — точно нет, т.к. его использует HTTPS (и в случае его блокировки негодующие хомячки снесут всё на своём пути к гуглу/фейсбуку и т.д.)
3) SSH-клиент есть на любой машине в пределах достягаемости, то есть я могу поднять нужный мне туннель с любой unix-машины. В 3-5 шагов — с windows.
4) Настройки степени туннелирования легко регулировать. Если мне нужны только socks-proxy, то я не буду изобретать l2-туннели.
5) Без дополнительного шаманства можно иметь несколько параллельных подключений, причём в любой комбинации — к одному серверу с разных клиентов, к разным серверам с одного клиента и т.д. Совсем долбанутые на голову увлечённые могут вообще связывать в единый L2-сегмент континенты и сети посредством одинокой замухрышки, сидящей на 3g где-то в пятой точке мира за хардкорным натом с закрытыми портами. И это даже будет работать (в той степени, в которой 3g в пятой точке мира будет способно переварить пролетающие через L3 бродкасты/мультикасты).

Хотя главная причина ещё проще: SSH — штатный инструментарий, и он умеет всё, что нужно. Зачем ещё что-то?

Итак, теория SSH-туннелей

TUN-интерфейсы


TUN-интерфейс устроен очень просто: он создаёт в системе виртуальный сетевой интерфейс (tun0, tun1 и т.д.), который другим своим «концом» смотрит в fd (файловый дескриптор) у той программы, которая его создала. Что делать с трафиком из fd программа решает сама. А приложения в системе сами решают, что делать с сетевым интерфейсом.

В случае с SSH мы говорим SSH-клиенту создать tun-интерфейс со своей стороны, SSH-серверу со своей стороны, и соединить их. Получается, что трафик с одной стороны (с клиента) вошёл, с другой стороны (с сервера) вышел. И наоборот. Чем не туннель? Чем не vpn? С учётом, что SSH ещё и шифровать трафик умеет, получаем готовый VPN. Внутри SSH это называются channel, и он их мультиплексирует, но нас это особо и не волнует.

Вот простенький рисунок того, что происходит:


Заметим, нам требуется кооперация со стороны SSH-сервера. Разрешение создавать туннели на сервере мы обсудим в секции с ниже Там же будут подробности настройки NAT'а, адресации и прочих вещей, чтобы стрелка Freedom заработала.

Примечание на полях: помимо tun-интерфейсов бывают ещё tap-интерфейсы. Они позволяют объединять L2-сегменты. Это ад, ужас, содомия и угар, но если кому-то очень хочется, то он может попробовать объединить пару сетей из разных дата-центров посредством SSH-коннекта на домашнюю заначенную машину. Это даже будет работать (за последствия не ручаюсь).

Практические действия



Подготовка:
  1. Скопировать SSH ключ к root'у на сервер (если ключа нет, сгенерировать: sudo ssh-keygen). Я обычно делаю ключ локальному root'у, чтобы не путать его со своим ключом. Ключ копируется командой sudo ssh-copy-id root@server.
  2. Проверить, что у SSH на удалённом сервере разрешено использовать туннели. В файле /etc/ssh/sshd_config переменная PermitTunnel должна быть раскомментирована и выставлена в yes.
  3. Выбрать произвольное число (echo $RANDOM). Это будет наш номер туннеля. Запомним его (или возьмём другое любимое число, например, 42).
  4. Настроим удалённый сервер. Я пишу для debian/ubuntu, процесс для других дистрибутивов/ОС — см в документации по настройке сети к ним. В файле /etc/networking/interfaces создаём следующие строчки:
    allow-hotplug tun42
    auto tun42
    iface tun42 inet static
            address 100.64.42.1
            netmask 255.255.255.0
            pre-up iptables -A POSTROUTING -t nat  -s 100.64.42.0/24 -j MASQUERADE
            post-down iptables -D POSTROUTING -t nat  -s 100.64.42.0/24 -j MASQUERADE
    

    Это позволит нам автоматически получать сконфигурированный интерфейс каждый раз, когда на сервере появится интерфейс tun42. Заодно мы включаем NAT для трансляции наших пакетов из туннеля, и выключаем его как только интерфейс пропадает.
  5. Разрешим маршрутизацию на сервере. /etc/sysctl.d/enable_routing.conf
    net.ipv4.conf.all.forwarding = 1
    


Мы практически закончили. Осталось только запустить steam. Всё ниженаписанное на локальной машине.
  1. Выключить все предыдущие копии steam'а, включая иконку в трее
  2. Установить соединение с сервером: sudo ssh -w 42:42 root@server. Опция -w говорит создать tun42 локально и связать его (создав) с удалённым tun42.
  3. В соседней консоли:
    xhost +
    sudo ip net add steam
    sudo ip link set netns steam dev tun42
    sudo ip net exec steam ip addr add  100.64.42.2/24 dev tun42
    sudo ip net exec steam ip link set up dev tun42
    sudo ip net exec steam ip route add default via 100.64.42.1
    sudo ip net exec steam login -f $USER
    export DISPLAY=:0
    steam
    

    xhost + разрешает подключаться к вашему X-серверу кому угодно (будте осторожны). Параноики могут изучить man xhost для указания более точных правил.

    ip net add и ip net exec — это сокращения от ip netns add и ip netns exec — создать network namespace, и запустить новую сессию пользователя из под которого мы работаем. export DISPLAY=:0 говорит «использовать первый X-сервер. По умолчанию эта переменная сбрасывается при логине, а без неё steam не сможет подключиться к X-серверу



Собственнно, всё. На выходе имеем русские цены в Стиме и русскую цензуру. К счастью, защищать она будет только steam, а браузер в соседнем окне будет пользоваться не очень быстрым, но весьма свбодным кипрским интернетом.

В следующих частях:
  • Как запустить 32-битный steam на x86_64 машине
  • Как изолировать steam полностью, так, чтобы он работал, но при этом ни разу не запускался от рута или основного пользователя. Любовь и нанависть с пульсадуио, dri, методы определения нехватающих библиотек, отладка самого Steam'а
Георгий Шуклин @amarao
карма
271,0
рейтинг 18,9
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (84)

  • +3
    Шикарно!
    Я лет 5 назад на freebsd решал похожие задачи с помощью множественных таблиц маршрутизации и утилиты setfib.
    Спасибо за статью!
    • +1
      fib'ы — это несколько не то. fib-ы — это эквивалент нескольких таблиц роутинга.

      внутри неймспейсов возможно:
      1)множество таблиц роутинга(т.е. можно считать что fib'ы внутри fib'ов).
      2)свои правила iptables & ipset(на новых ядрах его сделали namespace aware)
      3)свои интерфейсы и даже кое-какие настройки conntrack, вроде net.netfilter.nf_conntrack_max и net.netfilter.nf_conntrack_buckets
      4)терминировать pppoe
      5)держать phy от wifi-карточки и создавать свои wlan-интерфейсы

      Вообще, можно много всякого делать, например как в моём примере
      • 0
        Ну, я вообще и написал, что это множественные таблицы маршрутизации.
        С помощью утилиты setfib, модуля setfib для ipfw можно:
        1)множество таблиц роутинга
        2)свои правила ipfw & ipfw table & ipfw nat
        3)свои интерфейсы
        4)терминировать pppoe, openvpn, ipip, gre,…
        5)по wlan не в курсе но, отдельные интервейсы загонятьв fib — элементарно.
        Так что ;)
        • +1
          вы не правы.

          1)множество таблиц роутинга

          это да.

          2)свои правила ipfw & ipfw table & ipfw nat

          это не так. на старте:
          root@laptus:~ # setfib 0 ipfw show
          65535 3127 321815 allow ip from any to any
          добавим правило:
          root@laptus:~ # setfib 0 ipfw add 100 allow ip from any to any
          00100 allow ip from any to any

          теперь мы его видим не только в fib 0:
          root@laptus:~ # setfib 0 ipfw show
          00100 18 1536 allow ip from any to any
          65535 3302 335611 allow ip from any to any
          но и в fib 1:
          root@laptus:~ # setfib 1 ipfw show
          00100 62 5384 allow ip from any to any
          65535 3302 335611 allow ip from any to any

          3)свои интерфейсы
          это тоже не так.

          PS: имхо, вы путаете с VIMAGE, который даже в CURRENT
          WARNING: VIMAGE (virtualized network stack) is a highly experimental feature.
          • 0
            По ipfw:
            Да, попутал, свои правила ipfw делать было нельзя.
            По поводу NAT — один NAT у меня был ipfw nat, остальные — растыканные natd по разным fib.
            По поводу интерфесов — виртуальные можно любые распихивать по разным fib'ам, к примеру
            setfib 10 ifconfig tun0…
            По поводу вообще любых интерфейсов можно было сделать так:
            ipfw add setfib 5 ip from any to any via em10
  • +2
    Главное не забывать что играть тоже придется через тунель, потому что игры купленные в одном регионе ( СНГ ) нельзя играть с европейских IP.
    • 0
      Можно. По крайней мере у меня ни разу отказа в запуске не было. Если будет — не велика потеря, туннель так же работать позволит.
      • +3
        Если это мультиплеер, то задержка может стать решающим препятствием.
        • +4
          На Кипре средний пинг — от 50 до 100мс. Лишние 10мс от Питера ничего не решают.

          В Питере был лучший интернет в мире. До момента введения цензуры.

          Дешёвый, без лимитов, с практически идеальным аптаймом, с субмилисекундными пингами по городу и 12мс до Нидерландов, с поддержкой IPv6, белым IP без фильтров и дискриминации трафика, с снятием лимитов по скорости в моменты низкой загрузки сети (читай — 100Мб всегда, кроме вечера; вечером столько, сколько по тарифу положено).
    • +1
      Я бы наоборот покупал за дорогую цену, чтобы в очередной деловой поездке не обнаружить, что у меня биошок или каловсдутие не работает :(
      • 0
        каловсдутие не работает

        не велика потеря имхо
    • 0
      Очень немногие игры не заведутся, если куплены в России, а играете где-то еще. Из того, что есть у меня это Skyrim и Borderlands 2.
  • +1
    Полуофф: а есть технология, аналогичная «network namespaces» для Windows?
    • +1
      Я в новых изобретениях MS не разбираюсь, гугль говорит вот: msdn.microsoft.com/en-us/library/windows/apps/windows.networking.aspx хотя я не понимаю, что такое «network isolation» по мнению MS.
    • +1
      Уже некоторое время пытаюсь найти способ разделять траффик в windows именно по приложениям и ничего не удаётся найти. Если само приложение не имеет интерфейса выбора сетевой карты или прокси, то видимо никак. Или не правильно формирую запросы или не существует способа выделить траффик приложения или как-то пометить его пакеты, только маршруты по IP.
      • +4
        ProxyCap была утилита, когда-то была полезна.
        • 0
          Судя по описанию то, что нужно.

          Версия для Windows — 30 USD.
          • +1
            Можете еще на proxyfier взгялнуть.
      • +4
        SocksCap. Работала на подсовывании своей DLL, выдающей себя за WinSock, а дальше уже дёргающая реальный винсок в свой позе.
        • +1
          Я пробовал tsocks под линукс (скрипт, подменяющий с помощью LD_PRELOAD so'шки). Для обычных программ прокатывает, для Стима — нет, т.к. стим сам очень сильно злоупотребляет LD_PRELOAD и переуказанием библиотек.
      • +3
        Нашлась викистатья со списком программ для этой цели: https://en.wikipedia.org/wiki/Comparison_of_proxifiers
        • 0
          И хоть кто-то из них со стимом работает?
          • 0
            Неизвестно, но это список софта который можно попробовать ;)
            • 0
              ИМХО, это на отдельную статью потянет…
        • 0
          Спасибо за ссылку. Моего гугль-фу как-то не хватило, чтобы найти, хотя искал.

          Правда, ни одна из перечисленных софтин не умеет делать правила per-user basis. Написал паре авторов, может, добавят — теоретически должно быть несложно.
      • 0
        Для браузера (они все могут SOCKS proxy) удобно использовать Bitvise SSH Client (Tunnelier) совместно с FoxyProxy.
        • +1
          Чтобы использовать socks-proxy достаточно просто ssh:

          ssh -CD 1080 user@server.
      • 0
        Я тут в свете борьбы с Великим российским Файрволлом задался этим вопросом, хотя моя задача чуть проще — пускать через американский VPN всё, кроме торрентов. На stackexchange подсказали — serverfault.com/a/594509/219402 — средствами файрволла Windows для указанного приложения (в моём случае — uTorrent) блокируется доступ к VPN IP и оно вынуждено подключаться напрямую.
  • +2
    Хорошая статья!
    А не проще сделать еще один аккаунт Steam, и покупать через VPN, после чего отправлять игру подарком на основной аккаунт, а там уже активировать и играть, ничего не боясь? :)
    • 0
      не все игры можно дарить.
    • +1
      Если раньше гифты не имели региональных ограничений, то теперь у издателей появилась возможность накладывать эти самые региональные ограничения и на гифты. Видимо очень активно торговать гифтами стали (особенно после появления возможности не только принимать средства на paypal и выводить их). А до этого была введена возможность издателям установки запрета на покупку гифтов.
    • 0
      Я и так ничего не боюсь. Благодаря SSH и профессии, уж SSH с рутовым доступом я для себя всегда и везде найду.
    • 0
      Сейчас даже паки в CIS многие издатели не продают т.е. и на этом не сэкономить.
  • +1
    pre-up iptables -D POSTROUTING -t nat -s 100.64.42.0/24 -j MASQUERADE
    post-down iptables -D POSTROUTING -t nat -s 100.64.42.0/24 -j MASQUERADE

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

    Вопрос номер два: debian 6, например, из коробки не знает, что такое ip netns. Неплохо было бы указать, что за пакет используется для network namespaces.
    • +1
      Ман говорит, что утилита поставляется вместе с iproute2.
    • 0
      Опечатка, поправил.
    • +2
      debian6 — oldstable. Вы хотите запускать steam на oldstable? Удачи с libc, так сказать.
  • +1
    Я делал похожее для приложения через iptables owner match extension, рулил все для группы, например «tunnel» через socks/vpn/etc.
    Правда, приложение приходилось запускать как-то так:
    sudo -g tunnel app
    • 0
      уж лучше cgroups тогда использовать.
  • 0
    За рассказ про ssh -w спасибо, я как-то обычно просто всех кто движется загоняю в носки до моей виртуалки в Нидерландах и так получаю безцензурный инет в России.
    Вместо xhost + лучше конечно использовать указание чему вы +, а то + всему это как-то брутальненько.

    Для изоляции стима от всего прочего рекомендую глянуть в LXC 1.0 запуск графических приложений, www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/ хорошо все описано, я так скайп отсадил. При таком отсаживании соответственно можно просто из lxc-таза поднимать ssh -w.
    • 0
      Городить полные контейнеры, имхо, перебор. У меня steam работает из-под отдельного пользователя (я просто не отладил процесс до уровня публикации пока что), устанавливался методом распаковки dpkg, то есть ни разу рута не получил. Таким образом он в ~steam весь болтается, то есть ничего за пределами своего каталога не увидит. Как только отлажу процесс, опубликую.

      А если ssh внутри контейнера сделать, то как steam поймёт что надо tun юзать, а не тот интерфейс, через который ssh работает?
  • 0
    Не совсем понял смысла этого действия.

    «Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.»

    Буквально вчера покупал дополнение для игры за рубли, находясь при этом в Англии, с английским айпишником. Если поставить регион как «Россия» в настройках, то оплата тоже происходит в рублях, независимо от того, где вы. Мультиплеер конкретно в «Цивилизации 5» (сама игра купленна как описано мною выше) работает корректно что в России, что в Англии, хотя за все игры не ручаюсь (хотя, rust, купленный таким же способом, проблем не вызывает).

    Что я упускаю?
    • 0
      Иногда он показывает рубли, иногда евро. Я закономерности не понял, но на второй или третьей попытки стрясти с меня -цать евро я полез крутить ssh.
      • 0
        У меня так было один раз всего, я перезашел в профиль, и появились рубли.
        Впрочем, допускаю, что у каждого по своему цена проявляется.
      • 0
        Если аккаунт считается российским, то достаточно подставить в URL параметр cc, равный ru, чтобы перестали пытаться стрясти евро, которые с российского акка всё равно не должны стрястись (будет ругаться на неверную валюту).

        Тот же портал:
        store.steampowered.com/app/620/?cc=DE
        store.steampowered.com/app/620/?cc=RU

        Пока не сменить страну проживания через суппорт (они попросят документ и, например, счета за свет) — валюта неизменно будет рублями, где бы вы ни были.
        • 0
          Эм, ясно. Это для веб-морды. А для /usr/bin/steam? В смысле, для его встроенной штуки.
          • 0
            В клиенте — разве что в оверлее: в браузере по шифт+табу в играх.

            Кстати, использование VPN для игры/покупки, вроде как, нарушает ToS стима и, кажется, за это даже банят. Будьте осторожны ;)
            • +2
              You agree that you will not use IP proxying or other methods to disguise the place of your residence, whether to circumvent geographical restrictions on game content, to purchase at pricing not applicable to your geography, or for any other purpose. If you do this, we may terminate your access to your Account.


              У меня штампик в паспорте есть с пропиской, с доказательством residence. А на Кипре я так, заездом.
  • 0
    Спасибо за статью.

    Можно тупой вопрос :)?

    когда SSH-клиенты организуют Socks-SSH прокси (Putty, например, так умеет), на стороне сервера организуется tun-интерфейс, так?

    (никогда об этом не задумывался)
    • 0
      Нет, socks-proxy не использует туннели и маршрутизацию. Когда клиенту говорят «создай socks-proxy», он просто создаёт соответствующий порт со своей стороны и создаёт канал (channel) до сервера. Когда приложение обращается на порт, его трафик передаётся серверу. Тот открывает соединение согласно заголовков и отдаёт ответ обратно.

      Табличка простая:

      Тип   уровень     Что передаётся
      tap        2         Передаются ethernet-кадры, включая бродкасты и ARP (свитч/бридж)
      tun        3         Передаются IP-пакеты (маршрутизатор)
      socks      4         Передаются запросы транспортного уровня TCP (прокси-сервер)
      

      (злой хабр не разрешает table в комментах -_-')

      Как-то так.
  • +1
    Так это можно и i2p роутер изолировать?
    • 0
      Да.
    • 0
      Да. Более того, я со стимом играюсь как раз в рамках концепции полной изоляции i2p. В принципе, socks-proxy для практических нужд хватает, но хочется более серьёзной изоляции. Всё осложняется адской jav'ой самого i2p, с которой не хочется разбираться.
  • 0
    На заметку — есть еще github.com/apenwarr/sshuttle

    > Я не люблю openvpn, openswan

    Для вас есть tinc :) www.tinc-vpn.org/
    • 0
      Это означает ещё одну программу? Зачем, когда ssh решает все проблемы?
      • 0
        openssh — это dirty vpn.

        sshuttle — позволяет где угодно, быстро и легко поднять vpn через ssh. ./sshuttle -r username@sshserver 0/0 -vv
        • 0
          Не понимаю, что такое «dirty».

          Шифрует? Шифрует. Трафик передаёт? Передаёт. В каком-то смысле даже обеспечивает стеганографию, потому что с пол-пинка даже не разобраться, «просто ssh» это, или туннель.
  • –1
    За технологию я бы поставил плюс, а за попытку наебать тех, на кого пека-геймерам молиться надо — минус.
    • +3
      То есть покупать айфончики в США, чтобы не платить в русском ретейле это ок, а покупать (внимание, покупать) в РФ для того, чтобы не платить втридорога в ЕС — это не ок?

      Чем отличается поездка в Италию за одеждой от VPN'а?
  • 0
    Спасибо! Отличная статья. Все думаю завести специальную машинку для того, чтобы поднять на ней всякие i2p, cjdns, tor и прочие демоны. Постоянная работа будет держать демоны в боевой готовности и давать пользу сетям, а на ноуте будет меньше тяжелых процессов. Наверное так же можно делать тунеть на такую машинку с жестким перенаправлением в эти сети и пользоваться благамираспределенности.
  • 0
    Пожалуйста, не используйте auto и allow-hotplug одновременно. Либо одно, либо другое, не вместе.
    • +1
      Почему?

      auto говорит «поднимать всегда при старте», allow-hotplug говорит «поднимать, когда интерфейс стал up».
      • 0
        Ну потому что эти вещи взаимоисключающие как правило. hotplug-интерфейсы не обрабатываются вообще до поднятия loopback-интерфейса, который поднимается в процессе обработки auto. Более того, в текущей реализации в этот самый момент могут возникнуть гонки, если интерфейс объявлен как allow-hotplug.
        • 0
          Заставляете старого человека маны перечитывать.

          Lines beginning with the word «auto» are used to identify the physical
          interfaces to be brought up when ifup is run with the -a option. (This
          option is used by the system boot scripts.) Physical interface names
          should follow the word «auto» on the same line. There can be multiple
          «auto» stanzas. ifup brings the named interfaces up in the order
          listed.

          Lines beginning with «allow-» are used to identify interfaces that
          should be brought up automatically by various subsytems. This may be
          done using a command such as «ifup --allow=hotplug eth0 eth1», which
          will only bring up eth0 or eth1 if it is listed in an «allow-hotplug»
          line. Note that «allow-auto» and «auto» are synonyms.


          В упор не вижу, откуда тут конфликт будет. Если есть источники, с интересом посмотрю.
          • +1
            А Вы исходники почитайте — поймёте.

            Я же написал, интерфейсы с hotplug поднимаются не раньше поднятия lo. Loopback поднимается при старте системы в момент обработки auto. Если интерфейс уже есть к этому моменту (в случае eth* это так), то сразу же при появлении интерфейса lo его начинает поднимать udev, и тут же он поднимается самим ifupdown. Кто первый поднимет — того и тапки. А если этого интерфейса нету, конечно же udev его поднимать не станет, но его всё равно поднимет ifupdown из-за auto. Т.е. в обоих случаях auto + allow-hotplug на старте системы дают результат эквивалентный auto, но иногда сбоящий.

            Теперь к опусканию интерфейса. До недавней версии ifupdown ошибки при опускании интерфейса были фатальными. Т.е. если мы пытаемся отобрать адрес у несуществующего интерфейса, и ip addr вывалился с ошибкой, то остальные команды даже не пытались бы обрабатываться, потому единственное валидное применение allow-hotplug вместе с auto — корректная деконфигурация интерфейса при его внезапном исчезновении — не было бы реализовано. В тестинге сейчас находится версия, которая игнорирует ошибки при деконфигурации, потому эта проблема сейчас актуальна для меньшего числа пользователей, но в стейбле сказанное выше still applies.

            Проблема с гонками заключается ещё в том, что на данный момент нет простого её решения, т.е. скрипт, реализующий allow-hotplug на стороне udev находится в пакете udev, потому я не могу его просто взять и исправить, надо задействовать помощь других людей.

            Но пока проблема не исправлена, я не рекомендую эти возможности сочетать.
  • 0
    Касательно Steam'а:
    1) Валюта кошелька определяется либо при заведении аккаунта (по IP) либо при первом платеже, в зависимости от валюты платежа и не меняется никогда, через какой бы IP адрес клиент не заходил в дальнейшем.
    1.1) Если валюта кошелька, например, доллары, то, даже если зайти через российский IP, валюта кошелька так и останется в долларах.
    1.2) Цена на игры станут в рублях, но купить игру Стим не позволит. Или позволит, но непосредственно при оплате пересчитает в доллары
    2) Покупка игры через другой регион (обход определения региона через прокси или vpn) прямо запрещена соглашением, так что я очень не рекомендую так покупать игры. Гораздо правильнее попросить друга в нужном регионе купить игру в инвентарь и переслать (гифт (gift) — подарочную версию) игру Вам.
    2.1) Некоторые игры «залочены» на регион и купить из в подарок нельзя.
    • 0
      Не соглашусь с пунктом 1.
      Первая сотня игр куплены в РФ, потом переехал в Швейцарию. Все цены сейчас в евро, никогда с support-ом не общался.
      • 0
        Возможно, что саппорт сам поменял Вам валюту из-за того, что Вы _длительное_ время выходили в Стим с европейского IP и при покупке ставили галочку «Подтверждаю, что моей страной является <some_country>».
        При единоразовых сменах IP валюта не меняется.
        • 0
          Посторонних галочек я не ставил. Более того я ща запустил стим (без VPN), мне показали в заглавных евро, а в wishlist — рубли. Более того, пару раз система кривилась настолько, что показывала, что за игрушку списывает €249, хотя внутрях там было 249 рублей.

          Глючит и корёжит их.
  • 0
    По-моему удобней поднимать VPN(ы) на домашнем роутере, а на клиентах только маркировать пакеты которые надо загнать в определенный интерфейс. Для этого хорошо подходит поле DSCP которое все равно никакой роли в домашней сети не играет.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Как подсказывают ораторы выше, счёт у меня все равно в рублях, и в евро списан не будет, так что это, скорее, фикс, а не хак.
      • 0
        Моральный аспект: На самом деле, это таки хак. Важно не в какой валюте счет, а какова стоимость продукта. Стим выставляет разные цены для разных регионов не случайно. Более того, при оплате, например, пейпелом в стиме требуется галочка «Я подтверждаю, что проживаю в <название_страны>». Так что действия, описанные в статье, нарушают ToS Стима.

        Технический вопрос: По поводу ssh vs openvpn. Во-первых openvpn можно перевесить на любой порт (в т.ч. 443). Во-вторых, насколько мне известно, TCP-пакеты (HTTP) очень неохотно ходят внутри других TCP-пакетов (SSH) из-за оверхеда таймаутов в то время, как openvpn запаковывает в UDP. Но конечно в контексте данной проблемы это неактуально, так как скорость не критична
        • 0
          Я не оплачиваю пейпалом что-либо в стиме. Аккаунт я заводил в РФ, на рублёвую карточку российского банка. Почему что-то должно меняться? Тем паче, см комментарий выше, это всего лишь глюки интерфейса, а внутри там всё равно рубли.

          А вот обязательства оповещать стим о _смене_ места проживания я в TOC'е не нашёл.
        • 0
          Кстати про UDP.
          Если делать vpn на ssh, то мы тут будем инкапсулировать udp в ssh которая по tcp :) Если будет что то потоковое, где потеря двух — трех пакетов допустимо, то в ssh они будут гарантировано доставлены, те будут запрошены. Пакет, который в норме мог бы быть безболезненно потерян, посылается снова. Это может привести к замедлению работы VPN. Просто об этом надо помнить.
          • 0
            Это — да, есть такое. Но в нормальном режиме перепосыл будет относительно быстрым, плюс потеря пакетов на не очень загруженном канале — редкое событие.
            • 0
              Яркий пример у меня. Канал 100 в интернет. Есть сервера в разных странах с гарантированной скоростью 20. Если мы поднимаем vpn через ssh /0, и пытаемся замереть скорость (пусть будет тот же speedtest) то мы получим 5 — в хорошем случаи.
              Если мы поднимаем нормальный vpn (l2tp, ipsec,tinc) то мы выжимаем около 19. Да, можно заняться тюнингом и прочей ерисью, но надо понимать — что ssh vpn — это временное решение, которое не должно быть постоянным.

              проще поднять через tinc vpn, всего править два файла :) Не такой замороченный как openvpn. Вообще не понимаю, почему он не популярен?
  • 0
    Спасибо за статью. Некоторое время назад стояла похожая задача. Выделенное приложение на Linux сервере должно было выходить в сеть через VPN, чтобы при этом всё остальное работало через локалку. Поискал в сети, спросил на форумах, в том числе на лоре — ответы сводились к тому что так сделать нельзя. В итоге запустил этот софт на отдельной железке :)

    Сообщите пожалуйста, где искать в будущем такого рода информацию?
    • 0
      Только лор, там самые граммотные люди.
  • 0
    Заметим, в каждом namespace'е свой lo!

    А ifconfig должен показывать интерфейс lo в каждом неймспейсе? У меня не показывает:
    root@htpc:~# ip netns exec vpn ifconfig
    tun42     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              inet addr:10.169.1.6  P-t-P:10.169.1.5  Mask:255.255.255.255
              UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
              RX packets:246810 errors:0 dropped:0 overruns:0 frame:0
              TX packets:60845 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:100
              RX bytes:332284095 (316.8 MiB)  TX bytes:6638116 (6.3 MiB)
    
    • 0
      Проехали, его руками поднять надо: ip netns exec vpn ip link set up dev lo
    • +1
      root@rgs0:~# ip netns exec vx0 ifconfig
      root@rgs0:~# ip netns exec vx0 ifconfig -a
      lo Link encap: Локальная петля (Loopback)
      LOOPBACK MTU:65536 Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0
      RX bytes:0 (0.0 B) TX bytes:0 (0.0 B


      потому что без ключа -a ifconfig покатывает только то что в UP.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.