Aventuras fóra do azul

Aventuras fóra do azul

Como Spotify pode axudarche a estudar daemons, RFCs, redes e promover o código aberto. Ou que pasa se non podes pagar, pero realmente queres algunhas golosinas premium.

Comezar

O terceiro día, notouse que Spotify mostraba anuncios baseados no país do enderezo IP. Tamén se observou que nalgúns países non se importaba en absoluto a publicidade. Por exemplo, na República de Bielorrusia. E entón elaborouse un plan "brillante" para desactivar a publicidade nunha conta non premium.

Un pouco sobre Spotify

En xeral, Spotify ten unha política estraña. O noso irmán ten que retorcerse bastante para comprar premium: cambia a localización do seu perfil ao estranxeiro, busca unha tarxeta de agasallo adecuada que só se poida pagar con PayPal, que ultimamente se está a comportar de forma estraña e quere unha morea de documentos. En xeral, tamén é unha aventura, pero dunha orde diferente. Aínda que a maioría da xente fai isto por mor da versión móbil, non estou interesado nel. Polo tanto, todo o seguinte só axudará no caso da versión de escritorio. Ademais, non haberá ampliación de funcións. Só cortando algúns dos extras.

Por que é tan complicado?

E penseino ao rexistrar os datos do proxy de calcetíns na configuración de Spotify. O problema resultou ser que a autenticación nos calcetíns usando o inicio de sesión e o contrasinal non funciona. Ademais, os desenvolvedores adoitan facer algo ao redor do proxy: ou permitíndoo, logo prohibíndoo ou rompelo, o que orixina paneis enteiros de discusións fóra do sitio.

Decidiuse non confiar en funcións inestables e buscar algo máis fiable e interesante.

Nalgún lugar de aquí o lector debe preguntarse: por que non tomar ssh cunha chave -D e iso é o final? E, en xeral, terá razón. Pero, en primeiro lugar, aínda hai que demonizar e facer amizade con autossh, para non pensar en conexións rasgadas. E en segundo lugar: é demasiado sinxelo e aburrido.

En orde

Como de costume, imos de esquerda a dereita, de arriba a abaixo e describimos todo o que necesitamos para implementar a nosa idea "simple".

Primeiro necesitas un proxy

E hai moitas alternativas á vez:

  • pode simplemente ir e tomar das listas de proxy abertas. Barato (ou máis ben por nada), pero absolutamente pouco fiable e a vida útil destes proxies tende a cero. Polo tanto, sería necesario atopar/escribir un analizador para as listas de proxy, filtralas polo tipo e país desexados, e a cuestión de substituír o proxy atopado en Spotify segue aberta (ben, quizais a través de HTTP_PROXY transferir e crear un envoltorio personalizado para o binario para que non se envíe alí todo o resto de tráfico).
  • Podes mercar un proxy semellante e salvarte da maioría dos problemas descritos anteriormente. Pero ao prezo dun proxy, podes mercar inmediatamente Premium en Spotify, e isto non é práctico para a tarefa orixinal.
  • Levanta o teu. Como probablemente adiviñaches, esta é a nosa elección.

Por casualidade pode resultar que teñas un amigo cun servidor na República de Bielorrusia ou noutro país pequeno. Debe usalo e lanzar o proxy desexado nel. Os coñecedores especiais poden contentarse cun amigo cun enrutador conectado DD-WRT ou software similar. Pero alí súa mundo marabilloso e este mundo claramente non encaixa no marco desta historia.

Entón, as nosas opcións: Squid - non inspira, e non quero un proxy HTTP, xa hai demasiados deste protocolo. E na área de SOCKS non hai nada sensato excepto Dante aínda non entregaron. Polo tanto, tomémolo.

Non esperes polo manual de Dante sobre a instalación e configuración. El só googleando e non é de especial interese. Na configuración mínima cómpre botar todo tipo de client pass, socks pass, rexistre correctamente as interfaces e non se esqueza de engadir socksmethod: username. Neste formulario, para a autenticación, quitarase o logopass dos usuarios do sistema. E a parte da seguridade: prohibir o acceso a localhost, limitar usuarios, etc. - isto é puramente individual, dependendo da paranoia persoal.

Implementa un proxy de cara á rede

A obra está en dous actos.

Acto primeiro

Resolvemos o proxy, agora necesitamos acceder a el desde a web global. Se tes unha máquina cunha IP branca no país desexado, podes omitir este punto con seguridade. Non temos un (nós, como se mencionou anteriormente, estamos aloxados en casas de amigos) e a IP branca máis próxima está nalgún lugar de Alemaña, polo que estudaremos redes.

Entón, si, o lector atento volverá preguntar: por que non tomas un servizo como xa existente ngrok ou semellante? E volverá ter razón. Pero este é un servizo, hai que demonizar de novo, tamén pode custar cartos e en xeral non é deportivo. Por iso, crearemos bicicletas a partir de materiais de refugallo.

Tarefa: hai un proxy nalgún lugar moi atrás de NAT, cómpre colgalo nun dos portos dun VPS que ten unha IP branca e está situado na beira do mundo.

É lóxico supoñer que isto se pode resolver ben mediante o reenvío de portos (que se implementa a través do mencionado ssh), ou combinando hardware nunha rede virtual mediante VPN. CON ssh sabemos traballar, autossh É aburrido de tomar, así que tomemos OpenVPN.

DigitalOcean ten marabilloso manul sobre este asunto. Non teño nada que engadirlle. E a configuración resultante pódese conectar con bastante facilidade co cliente OpenVPN e systemd. Simplemente poñelo (config). /etc/openvpn/client/ e non esquezas cambiar a extensión a .conf. Despois diso, tire do servizo [email protected]non esquezas facelo por ela enable e alégrate de que todo voou.

Por suposto, necesitamos desactivar calquera redirección de tráfico á VPN recentemente creada, porque non queremos reducir a velocidade na máquina cliente pasando o tráfico por media bola.

E si, necesitamos rexistrar un enderezo IP estático no servidor VPN para o noso cliente. Isto será necesario un pouco máis tarde na historia. Para facelo, cómpre activar ifconfig-pool-persist, editar ipp.txt, incluído con OpenVPN e habilite client-config-dir, ademais de editar a configuración do cliente desexado engadindo ifconfig-push coa máscara correcta e o enderezo IP desexado.

Segundo acto

Agora temos unha máquina na "rede" que se enfronta a Internet e que se pode usar con fins egoístas. É dicir, redirixir parte do tráfico a través del.

Entón, unha tarefa nova: cómpre desactivar o tráfico que chega a un dos portos VPS cunha IP branca para que este tráfico vaia á rede virtual recentemente conectada e a resposta poida volver desde alí.

Solución: claro iptables! Cando máis terás unha oportunidade tan marabillosa de practicar con el?

A configuración requirida pódese atopar con bastante rapidez, en tres horas, cen insultos e un puñado de nervios desperdiciados, porque depurar redes é un procedemento moi específico.

En primeiro lugar, cómpre activar a redirección de tráfico no núcleo. Esta cousa chámase ipv4.ip_forward e está habilitado de forma lixeiramente diferente dependendo do sistema operativo e do xestor de rede.

En segundo lugar, cómpre seleccionar un porto no VPS e envolver todo o tráfico que vai a el nunha subrede virtual. Isto pódese facer, por exemplo, así:

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

Aquí rediriximos todo o tráfico TCP que chega ao porto 8080 da interface externa a unha máquina con IP 10.8.0.2 e o mesmo porto 8080.

Para os que queren os detalles sucios do traballo netfilter, iptables e enrutamento en xeral, é absolutamente necesario contemplalo este ou este.

Entón, agora os nosos paquetes voan á subrede virtual e... quedan alí. Máis precisamente, a resposta do proxy de calcetíns volve pola pasarela predeterminada na máquina con Dante e o destinatario bótaa, porque nas redes non é habitual enviar unha solicitude a unha IP e recibir unha resposta doutra. Polo tanto, hai que seguir conxurando.

Entón, agora cómpre redirixir todos os paquetes do proxy á subrede virtual cara ao VPS cunha IP branca. Aquí a situación é un pouco peor, porque é xusto iptables non teremos suficiente, porque se corriximos o enderezo de destino antes de enrutar (PREROUTING), entón o noso paquete non vai voar a Internet e, se non o solucionamos, o paquete irá a default gateway. Polo tanto, cómpre facer o seguinte: lembrar a cadea mangle, para marcar os paquetes iptables e envólveos nunha táboa de enrutamento personalizada que os enviará onde deben ir.

Nada máis dicir que feito:

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

Levamos o tráfico de saída, marcamos todo o que voa desde o porto no que se atopa o proxy (8080 no noso caso), rediriximos todo o tráfico marcado á táboa de enrutamento co número 80 (en xeral, o número non depende de nada, só queriamos). a) e engade unha única regra , segundo a cal todos os paquetes incluídos nesta táboa voan á subrede VPN.

Genial! Agora os paquetes voan cara ao VPS... e morren alí. Porque VPS non sabe que facer con eles. Polo tanto, se non te molestas, podes simplemente redirixir todo o tráfico que chega da subrede virtual a Internet:

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

Aquí, todo o que chega da subrede 10.8.0.0 cunha máscara de 255.255.255.000 envólvese en fonte-NAT e voa á interface predeterminada, que se converte en Internet. É importante ter en conta que isto só funcionará se reenviamos o porto de forma transparente, é dicir, o porto de entrada do VPS coincide co porto do noso proxy. Se non, terás que sufrir un pouco máis.

Nalgún lugar agora todo debería comezar a funcionar. E só queda un pouco: non esquezas asegurarte de que todas as configuracións iptables и route non continuou despois do reinicio. Para iptables hai ficheiros especiais como /etc/iptables/rules.v4(no caso de Ubuntu), pero para as rutas todo é un pouco máis complicado. Eu empúxoos up/down Scripts OpenVPN, aínda que creo que poderían terse feito máis decentemente.

Envolve o tráfico da aplicación no proxy

Así, temos un proxy con autenticación no país desexado, accesible a través dun enderezo IP branco estático. Todo o que queda é usalo e redirixir o tráfico de Spotify alí. Pero hai un matiz, como se mencionou anteriormente, o contrasinal de inicio de sesión para o proxy en Spotify non funciona, polo que buscaremos como sortealo.

Para comezar, lembremos sobre proxy. Cousas estupendas, pero custa tanto como unha nave estelar (40 dólares). Con estes cartos podemos de novo comprar premium e rematar con el. Polo tanto, buscaremos máis análogos libres e abertos no Mac (si, queremos escoitar música no Mac). Imos descubrir unha ferramenta completa: próximo. E iremos encantados de pegarlle.

Pero a alegría durará pouco, porque resulta que cómpre activar o modo de depuración e as extensións de núcleo personalizadas en MacOS, arquivar unha configuración sinxela e entender que esta ferramenta ten exactamente o mesmo problema que Spotify: non pode pasar a autenticación usando o contrasinal de inicio de sesión en socks-proxy.

Nalgún lugar por aquí é hora de flipar e comprar un premio... pero non! Intentemos pedir que se arranxe, é de código aberto! Imos facer billete. E como resposta recibimos unha historia desgarradora sobre como o único mantedor xa non ten un MacBook e ao carallo, non unha solución.

Estaremos molestos de novo. Pero entón lembraremos a nosa mocidade e C, activaremos o modo de depuración en Dante, exploraremos centos de kilobytes de rexistros, iremos a RFC1927 para obter información sobre o protocolo SOCKS5, vexamos Xcode e atopemos o problema. É suficiente con corrixir un carácter da lista de códigos de método que o cliente ofrece para a autenticación e todo comeza a funcionar como un reloxo. Alegrámonos, recollemos o binario de liberación, facémolo solicitude de extracción e imos ao solpor e imos ao seguinte punto.

Automatizalo

Unha vez que Proximac funciona, hai que demonizar e esquecer. Hai un sistema de inicialización completo que é axeitado para iso, que se atopa en MacOS, a saber lanzado.

Atopámolo rapidamente manual e entendemos que isto non é para nada systemd e aquí é case unha primicia e xml. Non hai configuracións elegantes para ti, sen comandos como status, restart, daemon-reload. Só tipo hardcore start-stop, list-grep, unload-load e moitas máis rarezas. Superado todo isto escribimos plist, cargando. Non funciona. Estudamos o método de depuración do demo, depurámolo, entendemos o que hai ENV mesmo PATH non entregamos o normal, argumentamos, traémolo (engadindo /sbin и /usr/local/bin) e, finalmente, estamos satisfeitos co arranque automático e o funcionamento estable.

Exhalar

Cal é o resultado? Unha semana de aventura, un zoolóxico de xeonllos de servizos que é querido para o corazón e fai o que se lle esixe. Un pouco de coñecemento en áreas técnicas dubidosas, un pouco de código aberto e un sorriso na cara ao pensar "Fíxeno!"

PD: este non é un chamamento ao boicot aos capitalistas, ao aforro de partidos ou á total astucia, senón só unha indicación das posibilidades de investigación e desenvolvemento onde, en xeral, non as esperas.

Fonte: www.habr.com

Engadir un comentario