Приключения изневиделица

Приключения изневиделица

Как Spotify може да ви помогне да изучавате демони, RFC, мрежи и да популяризирате отворен код. Или какво се случва, ако не можете да платите, но наистина искате първокласни екстри.

Начало

На третия ден беше забелязано, че Spotify показва реклами въз основа на държавата на IP адреса. Също така беше отбелязано, че в някои страни рекламата изобщо не се внася. Например в Република Беларус. И тогава беше измислен „брилянтен“ план за деактивиране на рекламата в непремиум акаунт.

Малко за Spotify

Най-общо казано, Spotify има странна политика. Брат ни трябва доста да се завърти, за да купи премиум: смени местоположението в профила си на чужбина, потърси подходяща карта за подарък, която може да се плати само с PayPal, което напоследък е странно и иска куп документи. Като цяло, това също е приключение, но от различен порядък. Въпреки че повечето хора правят това в името на мобилната версия, аз не се интересувам от това. Следователно всичко по-долу ще помогне само в случай на настолна версия. Освен това няма да има разширяване на функциите. Просто отрязвам някои от допълнителните.

Защо е толкова сложно?

И аз си мислех така, когато регистрирах данните за socks-proxy в конфигурацията на Spotify. Проблемът се оказа, че удостоверяването в socks с потребителско име и парола не работи. Освен това разработчиците редовно правят нещо около проксито: или го разрешават, след това го забраняват, или го нарушават, което води до цели панели от дискусии извън сайта.

Беше решено да не се разчита на нестабилни функции и да се намери нещо по-надеждно и интересно.

Някъде тук читателят трябва да попита: защо да не вземе ssh с ключ -D и това е краят? И като цяло ще бъде прав. Но, първо, това все още трябва да се демонизира и да се сприятели с autossh, за да не мислим за разкъсани връзки. И второ: прекалено е просто и скучно.

По ред

Както обикновено, нека да отидем отляво надясно, отгоре надолу и да опишем всичко, от което се нуждаем, за да реализираме нашата „проста“ идея.

Първо имате нужда от прокси

И има много алтернативи наведнъж:

  • можете просто да отидете и да вземете от отворени списъци с прокси. Евтини (или по-скоро за нищо), но абсолютно ненадеждни и животът на такива проксита клони към нула. Следователно би било необходимо да се намери/напише парсер за списъци с прокси сървъри, да се филтрират по желания тип и държава, а въпросът за заместването на намерения прокси в Spotify остава отворен (е, може би чрез HTTP_PROXY прехвърляне и създаване на персонализирана обвивка за двоичния файл, така че целият друг трафик да не се изпраща там).
  • Можете да закупите подобно прокси и да се спасите от повечето проблеми, описани по-горе. Но на цената на прокси можете веднага да закупите премиум в Spotify и това не е практично за първоначалната задача.
  • Вдигнете вашите. Както вероятно се досещате, това е нашият избор.

Чисто случайно може да се окаже, че имате приятел със сървър в Република Беларус или друга малка държава. Трябва да използвате това и да разгърнете желания прокси на него. Специалните ценители могат да се задоволят с приятел с включен рутер DD-WRT или подобен софтуер. Но там негов прекрасен свят и този свят явно не се вписва в рамките на тази история.

И така, нашите възможности: Squid - не е вдъхновяващо и не искам HTTP прокси, вече има твърде много от този протокол. И в областта на SOCKS няма нищо разумно, освен Данте все още не са доставени. Затова, нека го вземем.

Не чакайте ръководството на Dante за инсталиране и конфигуриране. Той просто гугъл и не представлява особен интерес. В минималната конфигурация трябва да хвърлите всички видове client pass, socks pass, регистрирайте правилно интерфейсите и не забравяйте да добавите socksmethod: username. В тази форма, за удостоверяване, logopass ще бъде взет от потребителите на системата. А частта за сигурността: забрана на достъп до localhost, ограничаване на потребителите и т.н. - това е чисто индивидуално, зависи от личната параноя.

Разположете прокси към мрежата

Пиесата е в две действия.

Акт първи

Подредихме проксито, сега трябва да имаме достъп до него от глобалната мрежа. Ако имате машина с бял IP в желаната държава, тогава можете спокойно да пропуснете тази точка. Ние нямаме такъв (ние, както споменахме по-горе, сме хоствани в къщи на приятели) и най-близкият бял IP е някъде в Германия, така че ще проучим мрежите.

Така че да, внимателният читател отново ще попита: защо не вземете съществуваща услуга като ngrok или подобни? И пак ще е прав. Но това е услуга, тя отново трябва да бъде демонизирана, може и да струва пари и като цяло не е спортна. Затова ще създадем велосипеди от скрап материали.

Задача: има прокси някъде далеч зад NAT, трябва да го окачите на един от портовете на VPS, който има бял IP и се намира на края на света.

Логично е да се предположи, че това може да бъде решено чрез пренасочване на портове (което се реализира чрез гореспоменатия ssh), или чрез комбиниране на хардуер във виртуална мрежа чрез VPN. СЪС ssh знаем как да работим, autossh Скучно е да го вземем, така че нека вземем OpenVPN.

DigitalOcean има прекрасен манул по тази тема. Няма какво да добавя към него. И получената конфигурация може да бъде доста лесно свързана с OpenVPN клиента и systemd. Просто го поставете (конфигурация). /etc/openvpn/client/ и не забравяйте да промените разширението на .conf. След това издърпайте услугата [email protected]не забравяйте да го направите за нея enable и се радвай, че всичко отлетя.

Разбира се, трябва да деактивираме всяко пренасочване на трафик към новосъздадената VPN, защото не искаме да намаляваме скоростта на клиентската машина, като пропускаме трафика през половин топка.

И да, трябва да регистрираме статичен IP адрес на VPN сървъра за нашия клиент. Това ще е необходимо малко по-късно в историята. За да направите това, трябва да активирате ifconfig-pool-persist, редактиране ipp.txt, включен с OpenVPN и активирайте client-config-dir, плюс редактирайте конфигурацията на желания клиент, като добавите ifconfig-push с правилната маска и желания IP адрес.

Действие второ

Сега имаме машина в „мрежата“, която е обърната към Интернет и може да се използва за егоистични цели. А именно пренасочване на част от трафика през него.

И така, нова задача: трябва да изключите трафика, пристигащ към един от VPS портовете с бял IP, така че този трафик да отиде към новосвързаната виртуална мрежа и отговорът да може да се върне оттам.

Решение: разбира се iptables! Кога друг път ще имате такава прекрасна възможност да тренирате с него?

Необходимата конфигурация може да бъде намерена доста бързо, за три часа, сто псувни и шепа похабени нерви, защото отстраняването на грешки в мрежите е много специфична процедура.

Първо, трябва да активирате пренасочване на трафика в ядрото. Това нещо се нарича ipv4.ip_forward и се активира малко по-различно в зависимост от операционната система и мрежовия мениджър.

Второ, трябва да изберете порт на VPS и да обвиете целия трафик към него във виртуална подмрежа. Това може да стане, например, така:

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8080 -j DNAT --to-destination 10.8.0.2:8080

Тук пренасочваме целия TCP трафик, идващ към порт 8080 на външния интерфейс към машина с IP 10.8.0.2 и същия порт 8080.

За тези, които искат мръсните подробности от работата netfilter, iptables и маршрутизирането като цяло е абсолютно необходимо да се обмисли този или този.

И така, сега нашите пакети летят към виртуалната подмрежа и... остават там. По-точно, отговорът от socks проксито лети обратно през шлюза по подразбиране на машината с Dante и получателят го изпуска, защото в мрежите не е обичайно да се изпраща заявка до един IP и да се получава отговор от друг. Следователно трябва да продължим да магьосваме.

И така, сега трябва да пренасочите всички пакети от проксито обратно към виртуалната подмрежа към VPS с бял IP. Тук ситуацията е малко по-лоша, защото просто iptables няма да имаме достатъчно, защото ако коригираме адреса на местоназначението преди маршрутизиране (PREROUTING), тогава нашият пакет няма да лети до интернет и ако не го поправим, пакетът ще отиде до default gateway. Така че, трябва да направите следното: запомнете веригата mangle, за да маркирате пакети през iptables и ги увийте в персонализирана таблица за маршрутизиране, която ще ги изпрати там, където трябва да отидат.

Речено, сторено:

iptables -t mangle -A OUTPUT -p tcp --sport 8080 -j MARK --set-mark 0x80
ip rule add fwmark 0x80 table 80
ip route add default via 10.8.0.1 dev tun0 table 80

Взимаме изходящия трафик, маркираме всичко, което лети от порта, на който седи проксито (в нашия случай 8080), пренасочваме целия маркиран трафик към таблицата за маршрутизиране с номер 80 (като цяло номерът не зависи от нищо, просто искахме до) и добавете едно правило, според което всички пакети, включени в тази таблица, летят към VPN подмрежата.

Страхотен! Сега пакетите летят обратно към VPS... и умират там. Защото VPS не знае какво да прави с тях. Следователно, ако не се притеснявате, можете просто да пренасочите целия трафик, пристигащ от виртуалната подмрежа обратно към Интернет:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 172.42.1.10

Тук всичко, което пристига от подмрежата 10.8.0.0 с маска 255.255.255.000, е обвито в source-NAT и лети към интерфейса по подразбиране, който е обърнат към Интернет. Важно е да се отбележи, че това нещо ще работи само ако прозрачно препращаме порта, тоест входящият порт на VPS съвпада с порта на нашия прокси. В противен случай ще трябва да страдате още малко.

Някъде сега всичко трябва да започне да работи. И остава само малко: не забравяйте да се уверите, че всички конфигурации iptables и route не продължи след рестартирането. За iptables има специални файлове като /etc/iptables/rules.v4(в случая на Ubuntu), но за маршрутите всичко е малко по-сложно. Натиснах ги вътре up/down OpenVPN скриптове, въпреки че мисля, че можеха да бъдат направени по-прилично.

Обвийте трафика от приложението в прокси

И така, имаме прокси с удостоверяване в желаната държава, достъпен чрез статичен бял IP адрес. Остава само да го използвате и да пренасочите трафика от Spotify там. Но има нюанс, както бе споменато по-горе, паролата за вход за проксито в Spotify не работи, така че ще потърсим как да го заобиколим.

Като начало, нека си припомним за проксификатор. Страхотни неща, но струват колкото звезден кораб ($40). С тези пари можем отново да купим премия и да приключим с това. Затова ще търсим повече безплатни и отворени аналози на Mac (да, искаме да слушаме музика на Mac). Нека открием един цял инструмент: проксимак. И ние с радост ще отидем да го намушкаме.

Но радостта ще бъде краткотрайна, защото се оказва, че трябва да активирате режима за отстраняване на грешки и персонализираните разширения на ядрото в MacOS, да подадете проста конфигурация и да разберете, че този инструмент има точно същия проблем като Spotify: не може да премине удостоверяване чрез вход-парола на socks-прокси.

Някъде тук е време да се побъркате и да купите премия... но не! Нека се опитаме да поискаме да се поправи, това е с отворен код! Нека да направим билет. И в отговор получаваме сърцераздирателна история за това как единственият поддържащ вече няма MacBook и по дяволите, не е поправка.

Пак ще се разстроим. Но тогава ще си спомним нашата младост и C, ще включим режима за отстраняване на грешки в Dante, ще копаем в стотици килобайти регистрационни файлове, ще отидем на RFC1927 за информация относно протокола SOCKS5, нека да разгледаме Xcode и да открием проблема. Достатъчно е да коригирате един знак в списъка с кодове на методите, които клиентът предлага за удостоверяване и всичко започва да работи като часовник. Ние се радваме, ние събираме двоичния файл на изданието, ние го правим заявка за изтегляне и отиваме в залеза и отиваме до следващата точка.

Автоматизирайте го

След като Proximac работи, той трябва да бъде демонизиран и забравен. Има една цяла система за инициализация, която е подходяща за това, която се намира в MacOS, а именно launchd.

Намираме го бързо наръчник и разбираме, че това изобщо не е така systemd и тук е почти лъжичка и xml. Без фантастични конфигурации за вас, без команди като status, restart, daemon-reload. Само хардкор вид start-stop, list-grep, unload-load и много други странности. Преодолявайки всичко това, ние пишем plist, Зареждане. Не работи. Ние изучаваме метода за отстраняване на грешки на демона, отстраняваме грешки, разбираме какво има ENV дори PATH не доставихме нормалното, караме се, вкарваме го (добавя /sbin и /usr/local/bin) и накрая сме доволни от автоматичното стартиране и стабилната работа.

Издишайте

какъв е резултатът Седмица на приключения, коленичила зоологическа градина от услуги, които са скъпи на сърцето и правят това, което се изисква от него. Малко познания в съмнителни технически области, малко отворен код и усмивка на лицето от мисълта „Направих го!“

PS: това не е призив за бойкот на капиталистите, за спестяване на мачове или за тотална хитрост, а просто индикация за възможностите за научноизследователска и развойна дейност там, където по принцип не ги очаквате.

Източник: www.habr.com

Добавяне на нов коментар