Avonturen uit het niets

Hoe Spotify u kan helpen daemons, RFC's en netwerken te bestuderen en open source te promoten. Of wat er gebeurt als je niet kunt betalen, maar wel graag wat premium goodies wilt.

begin

Op de derde dag viel het op dat Spotify advertenties vertoonde op basis van het land van het IP-adres. Er werd ook opgemerkt dat in sommige landen reclame helemaal niet werd geïmporteerd. Bijvoorbeeld in de Republiek Wit-Rusland. En toen werd er een ‘briljant’ plan bedacht om advertenties in een niet-premium account uit te schakelen.

Iets over Spotify

Over het algemeen heeft Spotify een vreemd beleid. Onze broer moet behoorlijk in de war raken om premium te kunnen kopen: verander de locatie in zijn profiel naar het buitenland, zoek een geschikte cadeaubon die alleen betaald kan worden met PayPal, die zich de laatste tijd raar gedraagt ​​en een heleboel documenten wil. Over het algemeen is het ook een avontuur, maar van een andere orde. Hoewel de meeste mensen dit doen omwille van de mobiele versie, ben ik er niet in geïnteresseerd. Daarom helpt alles hieronder alleen in het geval van de desktopversie. Bovendien vindt er geen uitbreiding van functies plaats. Gewoon een paar van de extra afsnijden.

Waarom is het zo ingewikkeld?

En dat dacht ik ook toen ik de sokken-proxygegevens in de Spotify-configuratie registreerde. Het probleem bleek te zijn dat authenticatie in sokken met login en wachtwoord niet werkt. Bovendien doen ontwikkelaars regelmatig iets om de proxy heen: deze toestaan, vervolgens verbieden of verbreken, wat aanleiding geeft tot hele panels met discussies buiten de site.

Er werd besloten om niet te vertrouwen op onstabiele functies en iets betrouwbaarder en interessanter te vinden.

Ergens hier moet de lezer zich afvragen: waarom niet nemen ssh met een sleutel -D en dat is het einde? En over het algemeen zal hij gelijk hebben. Maar in de eerste plaats moet dit nog steeds worden gedemoniseerd en bevriend worden gemaakt met autossh, om niet aan gescheurde verbindingen te denken. En ten tweede: het is te simpel en saai.

In volgorde

Laten we, zoals gewoonlijk, van links naar rechts en van boven naar beneden gaan en alles beschrijven wat we nodig hebben om ons “eenvoudige” idee te implementeren.

Eerst heb je een proxy nodig

En er zijn veel alternatieven tegelijk:

• u kunt gewoon gaan en nemen van open proxylijsten. Goedkoop (of liever gezegd voor niets), maar absoluut onbetrouwbaar en de levensduur van dergelijke proxy's neigt naar nul. Daarom zou het nodig zijn om een ​​parser voor proxylijsten te vinden/schrijven, deze te filteren op het gewenste type en land, en de kwestie van het vervangen van de gevonden proxy in Spotify blijft open (nou ja, misschien via HTTP_PROXY overbrengen en een aangepaste wrapper voor het binaire bestand maken, zodat al het andere verkeer daar niet naartoe wordt gestuurd).
• U kunt een soortgelijke proxy kopen en uzelf redden van de meeste van de hierboven beschreven problemen. Maar voor de prijs van een proxy kun je meteen premium kopen op Spotify, en dit is niet praktisch voor de oorspronkelijke taak.
• Verhoog de jouwe. Zoals je waarschijnlijk al geraden hebt, is dit onze keuze.

Puur toevallig kan het blijken dat je een vriend hebt met een server in de Republiek Wit-Rusland of een ander klein land. Deze dien je te gebruiken en daarop de gewenste proxy uit te rollen. Speciale kenners kunnen tevreden zijn met een vriend met een router aan DD-WRT of soortgelijke software. Maar daar zijn prachtige wereld en deze wereld past duidelijk niet in het kader van dit verhaal.

Dus onze opties: Inktvis - niet inspirerend, en ik wil geen HTTP-proxy, er zijn al te veel van dit protocol in omloop. En op het gebied van SOCKS is er niets zinnigs behalve Dante nog niet afgeleverd. Laten we het daarom nemen.

Wacht niet op Dante's handleiding over installeren en configureren. Hij gewoon googlen en is niet van bijzonder belang. In de minimale configuratie moet je er allerlei soorten in gooien client pass, socks pass, registreer de interfaces correct en vergeet niet toe te voegen socksmethod: username. In dit formulier wordt ter authenticatie de logopas van de systeemgebruikers afgenomen. En het gedeelte over beveiliging: toegang tot localhost verbieden, gebruikers beperken, enz. - dit is puur individueel, afhankelijk van persoonlijke paranoia.

Implementeer een proxy die naar het netwerk is gericht

Het stuk bestaat uit twee bedrijven.

Acteer een

We hebben de proxy uitgezocht, nu moeten we er toegang toe krijgen via het wereldwijde web. Als u in het gewenste land een machine met een wit IP-adres heeft, kunt u dit punt gerust overslaan. We hebben er geen (we worden, zoals hierboven vermeld, gehost bij vrienden thuis) en het dichtstbijzijnde witte IP-adres bevindt zich ergens in Duitsland, dus we zullen netwerken bestuderen.

Dus ja, de oplettende lezer zal zich opnieuw afvragen: waarom neem je niet een bestaande dienst zoals ngok of vergelijkbaar? En hij krijgt weer gelijk. Maar dit is een dienst, het moet weer gedemoniseerd worden, het kan ook geld kosten en is over het algemeen niet sportief. Daarom gaan we fietsen maken van restmaterialen.

Taak: er zit ergens ver achter NAT een proxy, deze moet je ophangen aan een van de poorten van een VPS die een wit IP heeft en zich aan de rand van de wereld bevindt.

Het is logisch om aan te nemen dat dit kan worden opgelost door port forwarding (wat wordt geïmplementeerd via de bovengenoemde ssh), of door hardware te combineren tot een virtueel netwerk via VPN. MET ssh wij weten hoe we moeten werken, autossh Het is saai om te nemen, dus laten we OpenVPN nemen.

DigitalOcean heeft prachtige manul hierover. Ik heb er niets aan toe te voegen. En de resulterende configuratie kan vrij eenvoudig worden verbonden met de OpenVPN-client en systemd. Voer het gewoon in (config). /etc/openvpn/client/ en vergeet niet de extensie te wijzigen in .conf. Trek daarna de service eruit [email protected]Vergeet niet om het voor haar te doen enable en wees blij dat alles wegvloog.

Natuurlijk moeten we elke omleiding van verkeer naar de nieuw gemaakte VPN uitschakelen, omdat we de snelheid op de clientmachine niet willen verlagen door verkeer door een halve bal te laten gaan.

En ja, we moeten een statisch IP-adres registreren op de VPN-server voor onze klant. Dit zal iets later in het verhaal nodig zijn. Om dit te doen moet u inschakelen ifconfig-pool-persist, bewerking ipp.txt, meegeleverd met OpenVPN en schakel client-config-dir in, plus bewerk de configuratie van de gewenste client door toe te voegen ifconfig-push met het juiste masker en het gewenste IP-adres.

Akte twee

Nu hebben we een machine op het “netwerk” die uitkijkt op internet en die voor egoïstische doeleinden kan worden gebruikt. Leid namelijk een deel van het verkeer er doorheen.

Een nieuwe taak dus: je moet het verkeer dat binnenkomt op een van de VPS-poorten met een wit IP-adres uitschakelen, zodat dit verkeer naar het nieuw verbonden virtuele netwerk gaat en de reactie van daaruit kan terugkeren.

Oplossing: natuurlijk iptables! Wanneer krijg je anders zo’n geweldige kans om met hem te oefenen?

De benodigde configuratie is vrij snel te vinden, in drie uur, honderd scheldwoorden en een handvol verspilde zenuwen, want het debuggen van netwerken is een heel specifieke procedure.

Eerst moet u verkeersomleiding in de kernel inschakelen. Dit ding heet ipv4.ip_forward en wordt enigszins anders ingeschakeld, afhankelijk van het besturingssysteem en de netwerkbeheerder.

Ten tweede moet je een poort op de VPS selecteren en al het verkeer dat daarheen gaat in een virtueel subnet inpakken. Dit kan bijvoorbeeld als volgt:

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

Hier leiden we al het TCP-verkeer dat naar poort 8080 van de externe interface komt, om naar een machine met IP 10.8.0.2 en dezelfde poort 8080.

Voor degenen die de smerige details van het werk willen netfilter, iptables en routering in het algemeen is het absoluut noodzakelijk om erover na te denken het of het.

Dus nu vliegen onze pakketten naar het virtuele subnet en... ze blijven daar. Om precies te zijn, het antwoord van de sokkenproxy vliegt terug via de standaardgateway op de machine met Dante en de ontvanger laat het vallen, omdat het in netwerken niet gebruikelijk is om een ​​verzoek naar het ene IP-adres te sturen en een antwoord van een ander te ontvangen. Daarom moeten we blijven toveren.

Nu moet je dus alle pakketten van de proxy terugsturen naar het virtuele subnet naar de VPS met een wit IP-adres. Hier is de situatie een beetje erger, omdat het gewoon zo is iptables we zullen niet genoeg hebben, want als we het bestemmingsadres corrigeren voordat we routeren (PREROUTING), dan vliegt ons pakket niet naar internet, en als we het niet repareren, gaat het pakket naar default gateway. Je moet dus het volgende doen: onthoud de ketting mangle, om pakketten door te markeren iptables en verpak ze in een aangepaste routeringstabel die ze naar de juiste bestemming stuurt.

Zo gezegd zo gedaan:

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

We nemen uitgaand verkeer, markeren alles dat vliegt vanaf de poort waarop de proxy zit (8080 in ons geval), leiden al het gemarkeerde verkeer om naar de routeringstabel met nummer 80 (in het algemeen is het nummer nergens van afhankelijk, we wilden gewoon to) en voeg een enkele regel toe, volgens welke alle pakketten in deze tabel naar het VPN-subnet vliegen.

Geweldig! Nu vliegen de pakketten terug naar de VPS... en sterven daar. Omdat VPS niet weet wat ze ermee moeten doen. Daarom kunt u, als u er geen moeite mee heeft, eenvoudigweg al het verkeer dat van het virtuele subnet komt, terug naar internet leiden:

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

Hier wordt alles wat binnenkomt vanuit het 10.8.0.0-subnet met een masker van 255.255.255.000 verpakt in source-NAT en vliegt naar de standaardinterface, die naar internet is gericht. Het is belangrijk op te merken dat dit ding alleen werkt als we de poort transparant doorsturen, dat wil zeggen dat de inkomende poort op de VPS overeenkomt met de poort van onze proxy. Anders zul je nog een beetje meer moeten lijden.

Ergens zou alles nu moeten werken. En er blijft nog een klein beetje over: vergeet niet ervoor te zorgen dat alle configs iptables и route ging niet verder na de herstart. Voor iptables er zijn speciale bestanden zoals /etc/iptables/rules.v4(in het geval van Ubuntu), maar voor routes is alles iets ingewikkelder. Ik duwde ze erin up/down OpenVPN-scripts, hoewel ik denk dat ze fatsoenlijker hadden kunnen worden gedaan.

Verpak verkeer van de toepassing in proxy

We hebben dus een proxy met authenticatie in het gewenste land, toegankelijk via een statisch wit IP-adres. Het enige dat overblijft is om het te gebruiken en het verkeer van Spotify daarheen om te leiden. Maar er is een nuance, zoals hierboven vermeld: het login-wachtwoord voor de proxy in Spotify werkt niet, dus we zullen zoeken naar hoe we dit kunnen omzeilen.

Laten we om te beginnen eens onthouden volmacht. Geweldig spul, maar het kost net zoveel als een ruimteschip ($ 40). Met dit geld kunnen we weer premium kopen en daarmee klaar zijn. Daarom zullen we op zoek gaan naar meer gratis en open analogen op de Mac (ja, we willen naar muziek luisteren op de Mac). Laten we een hele tool ontdekken: proximac. En we gaan hem graag porren.

Maar de vreugde zal van korte duur zijn, want het blijkt dat je de debug-modus en aangepaste kernelextensies in MacOS moet inschakelen, een eenvoudige configuratie moet indienen en moet begrijpen dat deze tool precies hetzelfde probleem heeft als Spotify: het kan de authenticatie niet doorstaan ​​met behulp van de login-wachtwoord op sokken-proxy.

Ergens hier in de buurt is het tijd om in paniek te raken en een premium te kopen... maar nee! Laten we proberen te vragen om het te repareren, het is open source! Laten we doen ticket. En als reactie krijgen we een hartverscheurend verhaal over hoe de enige beheerder geen MacBook meer heeft en er verdomd geen oplossing voor heeft.

We zullen weer boos zijn. Maar dan zullen we onze jeugd en C herinneren, de debug-modus in Dante inschakelen, honderden kilobytes aan logs doorzoeken, naar RFC1927 Laten we voor informatie over het SOCKS5-protocol naar Xcode kijken en het probleem vinden. Het volstaat om één teken te corrigeren in de lijst met methodecodes die de client aanbiedt voor authenticatie en alles begint op rolletjes te lopen. We zijn blij, we verzamelen het binaire bestand, dat doen we trek verzoek en we gaan de zonsondergang in en gaan naar het volgende punt.

Automatiseer het

Zodra Proximac werkt, moet het worden gedemoniseerd en vergeten. Er is één heel initialisatiesysteem dat hiervoor geschikt is, namelijk in MacOS launchd.

Wij vinden het snel handmatig en we begrijpen dat dit helemaal niet zo is systemd en hier is het bijna een primeur en xml. Geen ingewikkelde configuraties voor jou, geen commando's zoals status, restart, daemon-reload. Alleen hardcore soort start-stop, list-grep, unload-load en nog veel meer eigenaardigheden. We overwinnen dit allemaal, schrijven we plist, bezig met laden. Werkt niet. We bestuderen de methode om de demon te debuggen, debuggen, begrijpen wat er is ENV zelfs PATH we hebben niet de normale geleverd, argumenteren we, we brengen hem binnen (toevoegend /sbin и /usr/local/bin) en uiteindelijk zijn we blij met autostart en stabiele werking.

Uitademen

Wat is het resultaat? Een week vol avontuur, een knielende dierentuin van dienstverlening die ons nauw aan het hart ligt en doet wat ervan wordt verlangd. Een beetje kennis op dubieuze technische gebieden, een stukje open source en een glimlach op je gezicht bij de gedachte “Ik heb het gedaan!”

PS: dit is geen oproep tot een boycot van kapitalisten, tot besparingen op lucifers of tot totale sluwheid, maar slechts een indicatie van de mogelijkheden van onderzoek en ontwikkeling waar je ze over het algemeen niet verwacht.

Bron: www.habr.com