Jak vám Spotify může pomoci studovat démony, RFC, sítě a propagovat open source. Nebo co se stane, když nemůžete zaplatit, ale opravdu chcete nějaké prémiové dobroty.
začátek
Třetí den bylo zjištěno, že Spotify zobrazuje reklamy na základě země IP adresy. Bylo také poznamenáno, že v některých zemích se reklama vůbec nedováží. Například v Běloruské republice. A pak se vymyslel „skvělý“ plán na deaktivaci reklamy na neprémiovém účtu.
Něco málo o Spotify
Obecně řečeno, Spotify má zvláštní politiku. Náš bratr se musí pěkně zvrtnout, aby si mohl koupit prémii: změnit umístění v profilu na zámoří, hledat vhodnou dárkovou kartu, kterou lze zaplatit pouze přes PayPal, který se poslední dobou chová divně a chce hromadu dokumentů. Obecně je to také dobrodružství, ale jiného řádu. Ačkoli to většina lidí dělá kvůli mobilní verzi, mě to nezajímá. Vše níže tedy pomůže pouze v případě desktopové verze. Navíc nedojde k rozšíření funkcí. Jen odříznout některé z těch navíc.
Proč je to tak složité?
A myslel jsem si to při registraci dat socks-proxy v konfiguraci Spotify. Problém se ukázal v tom, že nefunguje autentizace v ponožkách pomocí loginu a hesla. Navíc vývojáři pravidelně něco kolem proxy dělají: někdy to povolí, někdy zakážou, někdy poruší, což dává vzniknout celým panelům diskuzí na off-site.
Bylo rozhodnuto nespoléhat na nestabilní funkce a najít něco spolehlivějšího a zajímavějšího.
Někde se zde čtenář musí ptát: proč nevzít ssh s klíčem -D a tím to končí? A obecně bude mít pravdu. Ale za prvé je to stále potřeba démonizovat a spřátelit se s autossh, aby se nemyslelo na přetrhané souvislosti. A za druhé: je to příliš jednoduché a nudné.
V pořádku
Pojďme jako obvykle zleva doprava, shora dolů a popišme si vše, co potřebujeme k realizaci našeho „jednoduchého“ nápadu.
Nejprve potřebujete proxy
A existuje mnoho alternativ najednou:
- můžete prostě jít a vzít z otevřených seznamů proxy. Levné (nebo spíš na nic), ale absolutně nespolehlivé a životnost takových proxy bývá nulová. Bylo by tedy potřeba najít/zapsat parser pro seznamy proxy, vyfiltrovat je podle požadovaného typu a země a otázka náhrady nalezeného proxy ve Spotify zůstává otevřená (no, možná přes
HTTP_PROXYpřenést a vytvořit vlastní obal pro binární soubor, aby se tam neposílal veškerý další provoz). - Můžete si koupit podobnou proxy a zachránit se od většiny výše popsaných problémů. Ale za cenu proxy si můžete okamžitě koupit prémii na Spotify, a to není pro původní úkol praktické.
- Zvedněte své. Jak asi tušíte, je to naše volba.
Čistě náhodou se může ukázat, že máte přítele se serverem v Běloruské republice nebo jiné malé zemi. Musíte to použít a nasadit na něj požadovaný proxy. Zvláštní fajnšmekři se mohou spokojit s kamarádem se zapnutým routerem nebo podobný software. Ale tam a tento svět zjevně nezapadá do rámce tohoto příběhu.
Takže naše možnosti: Squid - není inspirativní a nechci HTTP proxy, tohoto protokolu je již příliš mnoho. A v oblasti SOCKS není nic rozumného kromě ještě nedoručili. Proto si to vezměme.
Nečekejte na Danteho manuál o instalaci a konfiguraci. On a není zvláštní zájem. V minimální konfiguraci je potřeba hodit všemožné client pass, socks pass, správně zaregistrujte rozhraní a nezapomeňte přidat socksmethod: username. V této podobě bude pro autentizaci převzat logopass od uživatelů systému. A část o bezpečnosti: zákaz přístupu na localhost, omezení uživatelů atd. - to je čistě individuální, záleží na osobní paranoie.
Nasaďte proxy směřující k síti
Hra je ve dvou dějstvích.
Jednej
Proxy jsme vyřešili, teď k němu potřebujeme přistupovat z globálního webu. Pokud máte stroj s bílou IP v požadované zemi, pak můžete tento bod bez obav přeskočit. My žádnou nemáme (jak je uvedeno výše, jsme hostováni u přátel) a nejbližší bílá IP je někde v Německu, takže budeme studovat sítě.
Takže ano, pozorný čtenář se znovu zeptá: proč nevezmete existující službu jako nebo podobné? A bude mít zase pravdu. Ale to je služba, tu je zase potřeba démonizovat, taky to může stát peníze a celkově to není sportovní. Kola proto vytvoříme z odpadových materiálů.
Úkol: někde daleko za NATem je proxy, musíte ho zavěsit na jeden z portů VPS, které má bílou IP a nachází se na kraji světa.
Je logické předpokládat, že to lze vyřešit buď přesměrováním portů (které je implementováno prostřednictvím výše uvedeného ssh), nebo kombinací hardwaru do virtuální sítě přes VPN. S ssh víme, jak pracovat, autossh Je to nudné, takže si vezmeme OpenVPN.
DigitalOcean má v této věci. Nemám k tomu co dodat. A výslednou konfiguraci lze celkem snadno propojit s klientem OpenVPN a systemd. Prostě to vložte (config). /etc/openvpn/client/ a nezapomeňte změnit příponu na .conf. Poté stáhněte službu [email protected]nezapomeň to pro ni udělat enable a radovat se, že všechno odletělo.
Samozřejmě musíme zakázat jakékoli přesměrování provozu na nově vytvořenou VPN, protože nechceme snižovat rychlost na klientském počítači průchodem provozu přes půl míče.
A ano, musíme zaregistrovat statickou IP adresu na serveru VPN pro našeho klienta. To bude potřeba o něco později v příběhu. Chcete-li to provést, musíte povolit ifconfig-pool-persist, Upravit ipp.txt, který je součástí OpenVPN a povolte client-config-dir, plus upravte konfiguraci požadovaného klienta přidáním ifconfig-push se správnou maskou a požadovanou IP adresou.
Druhé dějství
Nyní máme v „síti“ stroj, který čelí internetu a lze jej použít pro sobecké účely. Totiž přesměrovat přes něj část provozu.
Takže nový úkol: musíte vypnout provoz přicházející na jeden z portů VPS s bílou IP, aby tento provoz šel do nově připojené virtuální sítě a odtud se mohla vracet odpověď.
Řešení: Samozřejmě iptables! Kdy jindy budete mít tak úžasnou příležitost si s ním zacvičit?
Požadovaná konfigurace se dá najít celkem rychle, za tři hodiny, stovku nadávek a hrst promarněných nervů, protože ladění sítí je velmi specifický postup.
Nejprve musíte povolit přesměrování provozu v jádře. Tato věc se nazývá ipv4.ip_forward a je povoleno mírně odlišně v závislosti na operačním systému a správci sítě.
Za druhé, musíte vybrat port na VPS a zabalit veškerý provoz, který k němu směřuje, do virtuální podsítě. To lze provést například takto:
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8080 -j DNAT --to-destination 10.8.0.2:8080Zde přesměrujeme veškerý TCP provoz přicházející na port 8080 externího rozhraní na stroj s IP 10.8.0.2 a stejným portem 8080.
Pro ty, kteří chtějí špinavé detaily práce netfilter, iptables a směrování obecně, je bezpodmínečně nutné uvažovat nebo .
Takže teď naše pakety létají do virtuální podsítě a... tam zůstanou. Přesněji řečeno, odpověď od socks proxy letí zpět výchozí bránou na stroji s Dantem a příjemce ji zahodí, protože v sítích není zvykem posílat požadavek na jednu IP a přijímat odpověď od druhé. Proto musíme pokračovat v kouzlení.
Nyní tedy musíte přesměrovat všechny pakety z proxy zpět do virtuální podsítě směrem k VPS s bílou IP. Tady je situace trochu horší, protože prostě iptables nebudeme mít dost, protože pokud před směrováním opravíme cílovou adresu (PREROUTING), pak náš balíček neodletí na internet, a pokud to neopravíme, balíček půjde do default gateway. Takže musíte udělat následující: zapamatujte si řetěz mangle, za účelem označení paketů skrz iptables a zabalte je do vlastní směrovací tabulky, která je pošle tam, kam mají jít.
Sotva řečeno, než uděláno:
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 80Vezmeme odchozí provoz, označíme vše, co letí z portu, na kterém sedí proxy (8080 v našem případě), veškerý označený provoz přesměrujeme do směrovací tabulky s číslem 80 (obecně číslo nezávisí na ničem, jen jsme chtěli do) a přidejte jedno pravidlo , podle kterého všechny pakety zahrnuté v této tabulce létají do podsítě VPN.
Skvělý! Nyní pakety létají zpět směrem k VPS... a umírají tam. Protože VPS neví, co s nimi. Pokud se tedy neobtěžujete, můžete jednoduše přesměrovat veškerý provoz přicházející z virtuální podsítě zpět na internet:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 172.42.1.10Zde je vše, co přichází z podsítě 10.8.0.0 s maskou 255.255.255.000, zabaleno do source-NAT a letí do výchozího rozhraní, které je otočeno na internet. Je důležité si uvědomit, že tato věc bude fungovat pouze tehdy, pokud transparentně přepošleme port, to znamená, že příchozí port na VPS odpovídá portu našeho proxy. Jinak budete muset trpět trochu víc.
Někde by teď mělo všechno začít fungovat. A zbývá jen málo: nezapomeňte se ujistit, že všechny konfigurace iptables и route po restartu nepokračovalo. Pro iptables existují speciální soubory jako /etc/iptables/rules.v4(v případě Ubuntu), ale u tras je vše trochu složitější. Strčil jsem je dovnitř up/down OpenVPN skripty, i když si myslím, že mohly být provedeny slušněji.
Zabalte provoz z aplikace do proxy
Máme tedy proxy s autentizací v požadované zemi, přístupnou přes statickou bílou IP adresu. Nezbývá než to využít a přesměrovat tam provoz ze Spotify. Existuje však nuance, jak je uvedeno výše, přihlašovací heslo pro proxy ve Spotify nefunguje, takže budeme hledat, jak to obejít.
Pro začátek si připomeňme o . Skvělé věci, ale stojí to tolik jako hvězdná loď (40 dolarů). Za tyto peníze si můžeme opět koupit prémii a být s tím hotový. Proto budeme hledat více bezplatných a otevřených analogů na Macu (ano, chceme poslouchat hudbu na Macu). Pojďme objevit jeden celý nástroj: . A my do něj s radostí půjdeme píchnout.
Ale radost bude krátkodobá, protože se ukázalo, že musíte povolit režim ladění a vlastní rozšíření jádra v MacOS, zadat jednoduchou konfiguraci a pochopit, že tento nástroj má úplně stejný problém jako Spotify: nemůže projít autentizací pomocí přihlašovací-heslo na socks-proxy.
Někde tady je čas se zbláznit a koupit si prémii... ale ne! Zkusme požádat o opravu, je to open source! Udělejme . A v reakci na to dostáváme srdceryvný příběh o tom, jak jediný správce už nemá MacBook a k čertu s ním, bez opravy.
Zase budeme naštvaní. Ale pak si vzpomeneme na mládí a C, zapneme režim ladění v Dante, prohrabeme se stovkami kilobajtů protokolů, přejdeme na pro informace o protokolu SOCKS5 se podíváme na Xcode a najdeme problém. Stačí opravit jeden znak v seznamu kódů metod, které klient nabízí k autentizaci a vše začne fungovat jako hodinky. Radujeme se, sbíráme binární vydání, děláme a jdeme do západu slunce a jdeme k dalšímu bodu.
Automatizujte to
Jakmile Proximac funguje, je potřeba ho démonizovat a zapomenout na něj. K tomu je vhodný jeden celý inicializační systém, který se nachází v MacOS, totiž .
Najdeme to rychle a chápeme, že to tak vůbec není systemd a tady je to skoro kopeček a xml. Žádné ozdobné konfigurace pro vás, žádné podobné příkazy status, restart, daemon-reload. Pouze hardcore typ start-stop, list-grep, unload-load a mnoho dalších zvláštností. O překonání toho všeho píšeme plist, načítání. Nefunguje. Studujeme metodu ladění démona, ladíme ho, chápeme, co tam je ENV dokonce PATH nedodali jsme normální, hádáme se, přinášíme (dodáváme /sbin и /usr/local/bin) a nakonec jsme spokojeni s autostartem a stabilním provozem.
Vydechněte
jaký je výsledek? Týden dobrodružství, zoologická zahrada na kolenou od služeb, která je srdcovka a dělá, co se od ní vyžaduje. Trochu znalostí v pochybných technických oblastech, trochu open source a úsměv na tváři z myšlenky „Dokázal jsem to!“
PS: nejde o výzvu k bojkotu kapitalistů, k šetření na sirkách nebo k totální mazanosti, ale jen naznačení možností výzkumu a vývoje tam, kde je obecně nečekáte.
Zdroj: www.habr.com