Come Spotify può aiutarti a studiare demoni, RFC, reti e promuovere l'open source. O cosa succede se non puoi pagare, ma vuoi davvero dei gadget premium.
Inizio
Il terzo giorno si è notato che Spotify mostrava annunci pubblicitari in base al paese dell'indirizzo IP. È stato inoltre notato che in alcuni paesi la pubblicità non veniva affatto importata. Ad esempio, nella Repubblica di Bielorussia. E poi è stato escogitato un piano "brillante" per disabilitare la pubblicità in un account non premium.
Un po' di Spotify
In generale, Spotify ha una politica strana. Nostro fratello deve comportarsi in modo piuttosto contorto per acquistare premium: cambiare la posizione nel suo profilo in Oltreoceano, cercare una carta regalo adatta che può essere pagata solo con PayPal, che ultimamente si comporta in modo strano e vuole un sacco di documenti. In generale, è anche un'avventura, ma di un ordine diverso. Anche se la maggior parte delle persone lo fa per il bene della versione mobile, non mi interessa. Pertanto, tutto ciò che segue sarà di aiuto solo nel caso della versione desktop. Inoltre, non ci sarà alcuna espansione delle funzioni. Basta tagliare alcuni di quelli in più.
Perché è così complicato?
E l'ho pensato quando ho registrato i dati del proxy calzini nella configurazione di Spotify. Il problema si è rivelato che l'autenticazione nei calzini tramite login e password non funziona. Inoltre, gli sviluppatori fanno regolarmente qualcosa riguardo al proxy: lo consentono, poi lo vietano o lo interrompono, il che dà origine a interi gruppi di discussioni fuori sede.
Si è deciso di non affidarsi a funzioni instabili e di trovare qualcosa di più affidabile e interessante.
Da qualche parte qui il lettore deve chiedersi: perché non prendere ssh con una chiave -D e questa è la fine? E, in generale, avrà ragione. Ma, in primo luogo, questo deve ancora essere demonizzato e fare amicizia con autossh, in modo da non pensare a connessioni strappate. E in secondo luogo: è troppo semplice e noioso.
Al fine
Come al solito andiamo da sinistra a destra, dall'alto verso il basso e descriviamo tutto ciò che ci occorre per realizzare la nostra “semplice” idea.
Per prima cosa hai bisogno di un proxy
E ci sono molte alternative contemporaneamente:
- puoi semplicemente andare a prendere dagli elenchi di proxy aperti. Economici (o meglio per niente), ma assolutamente inaffidabili e la durata di tali proxy tende a zero. Pertanto, sarebbe necessario trovare/scrivere un parser per gli elenchi di proxy, filtrarli in base al tipo e al paese desiderati, e rimane aperta la questione di sostituire il proxy trovato in Spotify (beh, forse attraverso
HTTP_PROXYtrasferire e creare un wrapper personalizzato per il binario in modo che tutto il resto del traffico non venga inviato lì). - Puoi acquistare un proxy simile e salvarti dalla maggior parte dei problemi sopra descritti. Ma al prezzo di un proxy puoi acquistare immediatamente il premium su Spotify, e questo non è pratico per il compito originale.
- Alza il tuo. Come probabilmente avrai intuito, questa è la nostra scelta.
Per puro caso potrebbe succedere che tu abbia un amico con un server nella Repubblica di Bielorussia o in un altro piccolo paese. È necessario utilizzarlo e implementare su di esso il proxy desiderato. Gli intenditori speciali possono accontentarsi di un amico con un router acceso o software simile. Ma lì e questo mondo chiaramente non rientra nel quadro di questa storia.
Quindi, le nostre opzioni: Squid: non entusiasmante e non voglio un proxy HTTP, ce ne sono già troppi di questo protocollo in giro. E nell'area dei CALZINI non c'è niente di sensato tranne non hanno ancora consegnato. Pertanto, prendiamolo.
Non aspettare il manuale di Dante sull'installazione e la configurazione. Lui e non è di particolare interesse. Nella configurazione minima è necessario inserire tutti i tipi di client pass, socks pass, registra correttamente le interfacce e non dimenticare di aggiungere socksmethod: username. In questo modulo, per l'autenticazione, verrà prelevato il logopass agli utenti del sistema. E la parte relativa alla sicurezza: vietare l'accesso a localhost, limitare gli utenti, ecc. - questo è puramente individuale, dipende dalla paranoia personale.
Distribuisci un proxy rivolto verso la rete
La commedia è in due atti.
Atto primo
Abbiamo risolto il proxy, ora dobbiamo accedervi dal web globale. Se hai una macchina con IP bianco nel paese desiderato, puoi tranquillamente saltare questo punto. Noi non ne abbiamo uno (noi, come detto sopra, siamo ospitati a casa di amici) e l’IP bianco più vicino è da qualche parte in Germania, quindi studieremo le reti.
Quindi sì, il lettore attento si chiederà ancora: perché non prendere un servizio già esistente come o simili? E avrà di nuovo ragione. Ma questo è un servizio, va demonizzato ancora una volta, può anche costare e in generale non è sportivo. Pertanto, creeremo biciclette da materiali di scarto.
Compito: c'è un proxy da qualche parte molto dietro NAT, devi agganciarlo a una delle porte di un VPS che ha un IP bianco e si trova all'estremità del mondo.
È logico supporre che ciò possa essere risolto tramite il port forwarding (che viene implementato tramite il suddetto ssh) o combinando l'hardware in una rete virtuale tramite VPN. CON ssh sappiamo come lavorare, autossh È noioso da prendere, quindi prendiamo OpenVPN.
DigitalOcean ha riguardo questo argomento. Non ho nulla da aggiungere. E la configurazione risultante può essere connessa abbastanza facilmente con il client OpenVPN e systemd. Basta inserirlo (config). /etc/openvpn/client/ e non dimenticare di cambiare l'estensione in .conf. Successivamente, ritira il servizio [email protected]non dimenticare di farlo per lei enable e rallegrarmi che tutto sia volato via.
Ovviamente dobbiamo disabilitare qualsiasi reindirizzamento del traffico alla VPN appena creata, perché non vogliamo ridurre la velocità sulla macchina client facendo passare il traffico attraverso una mezza palla.
E sì, dobbiamo registrare un indirizzo IP statico sul server VPN per il nostro client. Ciò sarà necessario un po’ più avanti nella storia. Per fare ciò è necessario abilitare ifconfig-pool-persist, modificare ipp.txt, incluso con OpenVPN e abilita client-config-dir, oltre a modificare la configurazione del client desiderato aggiungendo ifconfig-push con la maschera corretta e l'indirizzo IP desiderato.
Atto secondo
Ora abbiamo una macchina sulla “rete” che si affaccia su Internet e può essere utilizzata per scopi egoistici. Vale a dire, reindirizzare parte del traffico attraverso di esso.
Quindi, un nuovo compito: è necessario disattivare il traffico in arrivo su una delle porte VPS con IP bianco in modo che questo traffico vada alla rete virtuale appena connessa e la risposta possa tornare da lì.
Soluzione: ovviamente iptables! In quale altro momento avrai un'opportunità così meravigliosa di esercitarti con lui?
La configurazione richiesta può essere trovata abbastanza rapidamente, in tre ore, un centinaio di parolacce e una manciata di nervi sprecati, perché il debug delle reti è una procedura molto specifica.
Innanzitutto è necessario abilitare il reindirizzamento del traffico nel kernel. Questa cosa si chiama ipv4.ip_forward ed è abilitato in modo leggermente diverso a seconda del sistema operativo e del gestore di rete.
In secondo luogo, è necessario selezionare una porta sul VPS e racchiudere tutto il traffico ad essa diretto in una sottorete virtuale. Questo può essere fatto, ad esempio, in questo modo:
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8080 -j DNAT --to-destination 10.8.0.2:8080Qui reindirizziamo tutto il traffico TCP in arrivo sulla porta 8080 dell'interfaccia esterna su una macchina con IP 10.8.0.2 e la stessa porta 8080.
Per coloro che vogliono conoscere i dettagli sporchi del lavoro netfilter, iptables e il routing in generale, è assolutamente necessario tenerne conto o .
Quindi ora i nostri pacchetti volano nella sottorete virtuale e... rimangono lì. Più precisamente, la risposta del proxy calzini ritorna attraverso il gateway predefinito sulla macchina con Dante e il destinatario la rilascia, perché nelle reti non è consuetudine inviare una richiesta a un IP e ricevere una risposta da un altro. Pertanto, dobbiamo continuare a evocare.
Quindi, ora devi reindirizzare tutti i pacchetti dal proxy alla sottorete virtuale verso il VPS con un IP bianco. Qui la situazione è un po’ peggiore, perché è giusto iptables non ne avremo abbastanza, perché se correggiamo l'indirizzo di destinazione prima dell'instradamento (PREROUTING), il nostro pacchetto non volerà su Internet e, se non lo aggiustiamo, il pacchetto andrà a default gateway. Quindi, devi fare quanto segue: ricordare la catena mangle, per contrassegnare i pacchetti iptables e avvolgerli in una tabella di routing personalizzata che li invierà dove dovrebbero andare.
Detto fatto:
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 80Prendiamo il traffico in uscita, contrassegniamo tutto ciò che vola dalla porta su cui si trova il proxy (8080 nel nostro caso), reindirizziamo tutto il traffico contrassegnato alla tabella di routing con il numero 80 (in generale, il numero non dipende da nulla, volevamo solo a) e aggiungi un'unica regola, secondo la quale tutti i pacchetti inclusi in questa tabella volano verso la sottorete VPN.
Grande! Ora i pacchetti tornano verso il VPS... e lì muoiono. Perché VPS non sa cosa farne. Pertanto, se non ti preoccupi, puoi semplicemente reindirizzare tutto il traffico in arrivo dalla sottorete virtuale su Internet:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 172.42.1.10Qui tutto ciò che arriva dalla sottorete 10.8.0.0 con la maschera 255.255.255.000 viene avvolto nel source-NAT e vola all'interfaccia predefinita, che è rivolta a Internet. È importante notare che questa cosa funzionerà solo se inoltriamo la porta in modo trasparente, cioè la porta in entrata sul VPS corrisponde alla porta del nostro proxy. Altrimenti dovrai soffrire un po' di più.
Da qualche parte ora tutto dovrebbe iniziare a funzionare. E ne rimane solo una piccola cosa: non dimenticare di assicurarti che tutti i file configs iptables и route non è continuato dopo il riavvio. Per iptables ci sono file speciali come /etc/iptables/rules.v4(nel caso di Ubuntu), ma per i percorsi tutto è un po' più complicato. Li ho spinti dentro up/down Script OpenVPN, anche se penso che avrebbero potuto essere realizzati in modo più decente.
Avvolgi il traffico dall'applicazione nel proxy
Abbiamo quindi un proxy con autenticazione nel paese desiderato, accessibile tramite un indirizzo IP statico bianco. Non resta che usarlo e reindirizzare lì il traffico da Spotify. Ma c'è una sfumatura, come accennato in precedenza, la password di accesso per il proxy in Spotify non funziona, quindi cercheremo come aggirare il problema.
Per cominciare, ricordiamolo . Roba fantastica, ma costa quanto un'astronave ($ 40). Con questi soldi possiamo acquistare nuovamente il premio e farla finita. Pertanto, cercheremo analoghi più gratuiti e aperti su Mac (sì, vogliamo ascoltare musica su Mac). Scopriamo un intero strumento: . E andremo volentieri a stuzzicarlo.
Ma la gioia sarà di breve durata, perché si scopre che è necessario abilitare la modalità debug e le estensioni del kernel personalizzate in MacOS, archiviare una semplice configurazione e capire che questo strumento ha esattamente lo stesso problema di Spotify: non può superare l'autenticazione utilizzando il password di accesso su calzini-proxy.
Da queste parti è ora di dare di matto e comprare un premio... ma no! Proviamo a chiedere che venga risolto, è open source! Facciamolo . E in risposta riceviamo una storia straziante su come l'unico manutentore non abbia più un MacBook e al diavolo, non è una soluzione.
Saremo sconvolti di nuovo. Ma poi ricorderemo la nostra giovinezza e C, attiveremo la modalità debug in Dante, scaveremo tra centinaia di kilobyte di registri, andremo a per informazioni sul protocollo SOCKS5, diamo un'occhiata a Xcode e troviamo il problema. Basta correggere un carattere nell'elenco dei codici dei metodi che il client offre per l'autenticazione e tutto inizia a funzionare come un orologio. Ci rallegriamo, raccogliamo il binario di rilascio, lo facciamo e andiamo verso il tramonto e andiamo al punto successivo.
Automatizzalo
Una volta che Proximac funzionerà, dovrà essere demonizzato e dimenticato. Esiste un intero sistema di inizializzazione adatto a questo, che si trova in MacOS .
Lo troviamo rapidamente e capiamo che non è affatto così systemd e qui è quasi uno scoop e xml. Nessuna configurazione fantasiosa per te, nessun comando come status, restart, daemon-reload. Solo tipo hardcore start-stop, list-grep, unload-load e molte altre stranezze. Superando tutto questo scriviamo plist, caricamento. Non funziona. Studiamo il metodo per eseguire il debug del demone, eseguirne il debug, capire cosa c'è ENV anche PATH non abbiamo consegnato quello normale, discutiamo, lo portiamo dentro (aggiungendo /sbin и /usr/local/bin) e infine siamo soddisfatti dell'avvio automatico e del funzionamento stabile.
Espira
Qual è il risultato? Una settimana di avventure, uno zoo in ginocchio dai servizi che ci sta a cuore e che fa ciò che gli viene richiesto. Un po’ di conoscenza in ambiti tecnici dubbi, un po’ di open source e un sorriso stampato in faccia al pensiero “ce l’ho fatta!”
PS: questo non è un appello al boicottaggio dei capitalisti, al risparmio sui fiammiferi o all'astuzia totale, ma solo un'indicazione delle possibilità di ricerca e sviluppo dove, in generale, non te le aspetti.
Fonte: habr.com