Äventyr ur det blå

Hur Spotify kan hjälpa dig att studera demoner, RFC:er, nätverk och främja öppen källkod. Eller vad händer om du inte kan betala, men du verkligen vill ha premiumgodis.

börjar

På den tredje dagen märktes det att Spotify visade annonser baserade på landet för IP-adressen. Det noterades också att reklam inte importerades alls i vissa länder. Till exempel i Republiken Vitryssland. Och sedan skapades en "lysande" plan för att inaktivera annonsering på ett icke-premiumkonto.

Lite om Spotify

Generellt sett har Spotify en konstig policy. Vår bror måste bli ganska skruvad för att köpa premium: ändra platsen i sin profil till utomlands, leta efter ett passande presentkort som bara kan betalas med PayPal, som har agerat konstigt på sistone och vill ha en massa dokument. I allmänhet är det också ett äventyr, men av en annan ordning. Även om de flesta gör detta för mobilversionens skull, är jag inte intresserad av det. Därför kommer allt nedan bara att hjälpa i fallet med skrivbordsversionen. Dessutom kommer det inte att ske någon utbyggnad av funktioner. Bara att klippa bort några av de extra.

Varför är det så komplicerat?

Och jag trodde det när jag registrerade socks-proxy-data i Spotify-konfigurationen. Problemet visade sig vara att autentisering i strumpor med inloggning och lösenord inte fungerar. Dessutom gör utvecklare regelbundet något kring proxyn: antingen tillåta den, sedan förbjuda den eller bryta den, vilket ger upphov till hela paneler med diskussioner på off-site.

Det beslutades att inte förlita sig på instabila funktioner och att hitta något mer pålitligt och intressant.

Någonstans här måste läsaren fråga: varför inte ta ssh med en nyckel -D och det är slutet på det? Och i allmänhet kommer han att ha rätt. Men för det första måste detta fortfarande demoniseras och bli vän med autossh, för att inte tänka på trasiga förbindelser. Och för det andra: det är för enkelt och tråkigt.

I ordning

Låt oss som vanligt gå från vänster till höger, uppifrån och ned och beskriva allt vi behöver för att implementera vår "enkla" idé.

Först behöver du en proxy

Och det finns många alternativ samtidigt:

• du kan bara gå och ta från öppna proxylistor. Billigt (eller snarare för ingenting), men absolut opålitligt och livslängden för sådana proxyservrar tenderar till noll. Därför skulle det vara nödvändigt att hitta/skriva en parser för proxylistor, filtrera dem efter önskad typ och land, och frågan om att ersätta den hittade proxyn i Spotify förblir öppen (nåja, kanske genom HTTP_PROXY överföra och skapa ett anpassat omslag för binären så att all annan trafik inte skickas dit).
• Du kan köpa en liknande proxy och rädda dig själv från de flesta problem som beskrivs ovan. Men till priset av en proxy kan du direkt köpa premium på Spotify, och detta är inte praktiskt för den ursprungliga uppgiften.
• Höj din. Som du säkert gissat är detta vårt val.

En ren slump kan det visa sig att du har en vän med en server i Republiken Vitryssland eller ett annat litet land. Du måste använda denna och rulla ut önskad proxy på den. Särskilda finsmakare kan nöja sig med en vän med en router på DD-WRT eller liknande programvara. Men där hans underbar värld och den här världen passar uppenbarligen inte in i denna berättelses ram.

Så våra alternativ: Bläckfisk - inte inspirerande, och jag vill inte ha en HTTP-proxy, det finns redan för många av det här protokollet. Och inom SOCKS-området finns det inget vettigt förutom Dante har inte levererat ännu. Därför, låt oss ta det.

Vänta inte på Dantes manual om installation och konfiguration. han bara googla och är inte av särskilt intresse. I den minsta konfigurationen måste du kasta in alla möjliga client pass, socks pass, registrera gränssnitten korrekt och glöm inte att lägga till socksmethod: username. I detta formulär, för autentisering, kommer logopasset att tas från systemanvändarna. Och delen om säkerhet: att förbjuda åtkomst till localhost, begränsa användare, etc. - detta är rent individuellt, beroende på personlig paranoia.

Distribuera en proxy vänd mot nätverket

Pjäsen är i två akter.

Akt ett

Vi har sorterat ut proxyn, nu måste vi komma åt den från den globala webben. Om du har en maskin med vit IP i önskat land kan du säkert hoppa över denna punkt. Vi har ingen (vi, som nämnt ovan, är värd hemma hos vänner) och den närmaste vita IP-adressen finns någonstans i Tyskland, så vi kommer att studera nätverk.

Så ja, den uppmärksamma läsaren kommer igen att fråga: varför tar du inte en befintlig tjänst som ngrok eller liknande? Och han kommer att få rätt igen. Men det här är en tjänst, den måste återigen demoniseras, den kan också kosta pengar och i allmänhet är den inte sportig. Därför kommer vi att skapa cyklar av skrotmaterial.

Uppgift: det finns en proxy någonstans långt bakom NAT, du måste hänga den på en av portarna på en VPS som har en vit IP och ligger i världens utkant.

Det är logiskt att anta att detta kan lösas antingen genom port forwarding (som implementeras genom ovan nämnda ssh), eller genom att kombinera hårdvara till ett virtuellt nätverk via VPN. MED ssh vi vet hur man arbetar, autossh Det är tråkigt att ta, så låt oss ta OpenVPN.

DigitalOcean har underbar manul i denna fråga. Jag har inget att tillägga. Och den resulterande konfigurationen kan ganska enkelt kopplas till OpenVPN-klienten och systemd. Lägg bara in den (config). /etc/openvpn/client/ och glöm inte att ändra tillägget till .conf. Efter det, dra tjänsten [email protected]glöm inte att göra det åt henne enable och gläds åt att allt flög iväg.

Naturligtvis måste vi inaktivera all omdirigering av trafik till den nyskapade VPN, eftersom vi inte vill minska hastigheten på klientdatorn genom att skicka trafik genom en halv boll.

Och ja, vi måste registrera en statisk IP-adress på VPN-servern för vår klient. Detta kommer att behövas lite längre fram i berättelsen. För att göra detta måste du aktivera ifconfig-pool-persist, redigera ipp.txt, ingår i OpenVPN och aktivera client-config-dir, plus redigera konfigurationen för den önskade klienten genom att lägga till ifconfig-push med rätt mask och önskad IP-adress.

Akt två

Nu har vi en maskin på "nätverket" som är vänd mot Internet och som kan användas i själviska syften. Omdirigera nämligen en del av trafiken genom den.

Så, en ny uppgift: du måste stänga av trafiken som kommer till en av VPS-portarna med en vit IP så att denna trafik går till det nyligen anslutna virtuella nätverket och svaret kan återvända därifrån.

Lösning: självklart iptables! När annars får du en sådan underbar möjlighet att träna med honom?

Den nödvändiga konfigurationen kan hittas ganska snabbt, på tre timmar, hundra svordomar och en handfull bortkastade nerver, eftersom felsökning av nätverk är en mycket specifik procedur.

Först måste du aktivera trafikomdirigering i kärnan. Den här saken heter ipv4.ip_forward och aktiveras något annorlunda beroende på operativsystem och nätverkshanterare.

För det andra måste du välja en port på VPS:en och slå in all trafik som går till den i ett virtuellt subnät. Detta kan till exempel göras så här:

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

Här omdirigerar vi all TCP-trafik som kommer till port 8080 i det externa gränssnittet till en maskin med IP 10.8.0.2 och samma port 8080.

För dig som vill ha de smutsiga detaljerna i jobbet netfilter, iptables och routing i allmänhet är det absolut nödvändigt att överväga detta eller detta.

Så nu flyger våra paket till det virtuella undernätet och... de stannar där. Mer exakt, svaret från socks proxy flyger tillbaka genom standardgatewayen på maskinen med Dante och mottagaren tappar det, eftersom det i nätverk inte är vanligt att skicka en förfrågan till en IP och få ett svar från en annan. Därför måste vi fortsätta trolla.

Så nu måste du omdirigera alla paket från proxyn tillbaka till det virtuella subnätet mot VPS med en vit IP. Här är situationen lite värre, för det är bara iptables vi kommer inte att ha tillräckligt, för om vi korrigerar destinationsadressen före routing (PREROUTING), då kommer vårt paket inte att flyga till Internet, och om vi inte fixar det kommer paketet att gå till default gateway. Så du måste göra följande: kom ihåg kedjan mangle, för att markera paket igenom iptables och slå in dem i en anpassad rutttabell som skickar dem dit de ska gå.

Inte tidigare sagt än gjort:

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

Vi tar utgående trafik, markerar allt som flyger från porten som proxyn sitter på (8080 i vårt fall), omdirigerar all markerad trafik till routingtabellen med nummer 80 (i allmänhet beror antalet inte på någonting, vi ville bara till) och lägg till en enda regel , enligt vilken alla paket som ingår i denna tabell flyger till VPN-undernätet.

Bra! Nu flyger paketen tillbaka mot VPS... och dör där. Eftersom VPS inte vet vad de ska göra med dem. Därför, om du inte bryr dig, kan du helt enkelt omdirigera all trafik som kommer från det virtuella undernätet tillbaka till Internet:

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

Här är allt som kommer från subnätet 10.8.0.0 med en mask på 255.255.255.000 insvept i käll-NAT och flyger till standardgränssnittet, som vänds till Internet. Det är viktigt att notera att denna sak bara kommer att fungera om vi transparent vidarebefordrar porten, det vill säga den inkommande porten på VPS matchar porten för vår proxy. Annars får du lida lite mer.

Någonstans borde nu allt börja fungera. Och bara lite kvar: glöm inte att se till att alla konfigurationer iptables и route fortsatte inte efter omstarten. För iptables det finns speciella filer som /etc/iptables/rules.v4(i fallet med Ubuntu), men för rutter är allt lite mer komplicerat. Jag tryckte in dem up/down OpenVPN-skript, även om jag tycker att de kunde ha gjorts mer anständigt.

Radbryt trafik från applikationen i proxy

Så vi har en proxy med autentisering i önskat land, tillgänglig via en statisk vit IP-adress. Allt som återstår är att använda den och dirigera om trafik från Spotify dit. Men det finns en nyans, som nämnts ovan, inloggningslösenordet för proxyn i Spotify fungerar inte, så vi kommer att leta efter hur vi kan komma runt det.

Till att börja med, låt oss komma ihåg om ombud. Fantastiska grejer, men det kostar lika mycket som ett rymdskepp ($40). Med dessa pengar kan vi återigen köpa premium och vara klara med det. Därför kommer vi att leta efter fler gratis och öppna analoger på Mac (ja, vi vill lyssna på musik på Mac). Låt oss upptäcka ett helt verktyg: proximac. Och vi går gärna och petar honom.

Men glädjen kommer att vara kortvarig, eftersom det visar sig att du måste aktivera felsökningsläge och anpassade kärntillägg i MacOS, arkivera en enkel konfiguration och förstå att det här verktyget har exakt samma problem som Spotify: det kan inte passera autentisering med hjälp av login-lösenord på socks-proxy.

Någonstans häromkring är det dags att flippa ut och köpa en premium... men nej! Låt oss försöka be om att det åtgärdas, det är öppen källkod! Låt oss göra biljett. Och som svar får vi en hjärtskärande historia om hur den enda underhållaren inte längre har en MacBook och åt helvete med det, inte en fix.

Vi kommer att bli upprörda igen. Men då kommer vi att minnas vår ungdom och C, slå på felsökningsläget i Dante, gräva igenom hundratals kilobyte loggar, gå till RFC1927 för information om SOCKS5-protokollet, låt oss titta på Xcode och hitta problemet. Det räcker med att korrigera ett tecken i listan över metodkoder som klienten erbjuder för autentisering och allt börjar fungera som en klocka. Vi gläds, vi samlar ut den binära versionen, det gör vi pull begäran och vi går in i solnedgången och går till nästa punkt.

Automatisera det

När Proximac väl fungerar måste den demoniseras och glömmas bort. Det finns ett helt initieringssystem som är lämpligt för detta, som finns i MacOS, nämligen lansera.

Vi hittar det snabbt manuell och vi förstår att det inte alls är det systemd och här är det nästan en skopa och xml. Inga snygga konfigurationer för dig, inga kommandon som status, restart, daemon-reload. Endast hardcore sort start-stop, list-grep, unload-load och många fler konstigheter. Att övervinna allt detta skriver vi plist, läser in. Fungerar inte. Vi studerar metoden för att felsöka demonen, felsöka den, förstå vad som finns där ENV även PATH vi levererade inte den normala, vi argumenterar, vi tar in den (tillägger /sbin и /usr/local/bin) och slutligen är vi nöjda med autostart och stabil drift.

Andas ut

Vad är resultatet? En äventyrsvecka, en knästående djurpark från tjänster som ligger varmt om hjärtat och gör vad som krävs av det. Lite kunskap inom tvivelaktiga tekniska områden, lite öppen källkod och ett leende på läpparna från tanken "jag gjorde det!"

PS: detta är inte en uppmaning till en bojkott av kapitalister, för att spara på tändstickor eller för total list, utan bara en indikation på möjligheterna till forskning och utveckling där man generellt sett inte förväntar sig dem.

Källa: will.com