Aventures de la blau

Aventures de la blau

Com Spotify us pot ajudar a estudiar dimonis, RFC, xarxes i promoure el codi obert. O què passa si no pots pagar, però realment vols unes llaminadures premium.

Начало

El tercer dia, es va notar que Spotify mostrava anuncis basats en el país de l'adreça IP. També es va assenyalar que en alguns països no s'importava gens la publicitat. Per exemple, a la República de Bielorússia. I després es va elaborar un pla "brillant" per desactivar la publicitat en un compte no premium.

Una mica sobre Spotify

En termes generals, Spotify té una política estranya. El nostre germà s'ha de retorçar bastant per comprar premium: canviar la ubicació del seu perfil a l'estranger, buscar una targeta regal adequada que només es pugui pagar amb PayPal, que darrerament fa estranya i vol un munt de documents. En general, també és una aventura, però d'un altre ordre. Tot i que la majoria de la gent ho fa pel bé de la versió mòbil, no m'interessa. Per tant, tot el següent només ajudarà en el cas de la versió d'escriptori. A més, no hi haurà ampliació de funcions. Només tallant alguns dels addicionals.

Per què és tan complicat?

I ho vaig pensar en registrar les dades de proxy de mitjons a la configuració de Spotify. El problema va resultar ser que l'autenticació als mitjons mitjançant l'inici de sessió i la contrasenya no funciona. A més, els desenvolupadors solen fer alguna cosa al voltant del proxy: de vegades ho permeten, de vegades ho prohibeixen, de vegades el trenquen, cosa que dóna lloc a panells sencers de debats fora del lloc.

Es va decidir no confiar en funcions inestables i trobar alguna cosa més fiable i interessant.

En algun lloc d'aquí el lector s'ha de preguntar: per què no prendre ssh amb una clau -D i això és el final? I, en general, tindrà raó. Però, en primer lloc, això encara s'ha de demonitzar i fer amistat amb autossh, per no pensar en connexions trencades. I en segon lloc: és massa senzill i avorrit.

En ordre

Com és habitual, anem d'esquerra a dreta, de dalt a baix i descrivim tot el que necessitem per implementar la nostra idea "simple".

Primer necessiteu un proxy

I hi ha moltes alternatives alhora:

  • només podeu anar i prendre de les llistes de proxy obertes. Barat (o més aviat per res), però absolutament poc fiable i la vida útil d'aquests proxies tendeix a zero. Per tant, caldria trobar/escriure un analitzador per a les llistes de proxy, filtrar-les pel tipus i el país desitjats, i la qüestió de substituir el proxy trobat a Spotify continua oberta (bé, potser a través de HTTP_PROXY transferir i crear un embolcall personalitzat per al binari de manera que la resta de trànsit no s'hi enviï).
  • Podeu comprar un proxy similar i estalviar-vos de la majoria dels problemes descrits anteriorment. Però al preu d'un proxy, podeu comprar immediatament premium a Spotify, i això no és pràctic per a la tasca original.
  • Aixeca el teu. Com probablement haureu endevinat, aquesta és la nostra elecció.

Per pura casualitat pot resultar que tens un amic amb un servidor a la República de Bielorússia o un altre país petit. Heu d'utilitzar-lo i desplegar-hi el proxy desitjat. Els coneixedors especials poden contentar-se amb un amic amb un encaminador encès DD-WRT o programari similar. Però allà seva món meravellós i aquest món clarament no encaixa en el marc d'aquesta història.

Per tant, les nostres opcions: Squid - no inspira, i no vull un servidor intermediari HTTP, ja n'hi ha massa d'aquest protocol. I a l'àrea de SOCKS no hi ha res assenyat excepte Dante encara no han lliurat. Per tant, prenem-ho.

No esperis el manual de Dante sobre la instal·lació i la configuració. Ell només google i no té un interès especial. En la configuració mínima, heu de llançar tot tipus de client pass, socks pass, registreu correctament les interfícies i no us oblideu d'afegir socksmethod: username. En aquest formulari, per a l'autenticació, es prendrà el logopass dels usuaris del sistema. I la part sobre la seguretat: prohibir l'accés a localhost, limitar usuaris, etc. - això és purament individual, depenent de la paranoia personal.

Desplegueu un servidor intermediari davant la xarxa

L'obra està en dos actes.

Acte primer

Hem resolt el proxy, ara hem d'accedir-hi des del web global. Si teniu una màquina amb una IP blanca al país desitjat, podeu ometre aquest punt amb seguretat. No en tenim cap (com s'ha dit anteriorment, estem allotjats a casa d'amics) i la IP blanca més propera es troba en algun lloc d'Alemanya, així que estudiarem les xarxes.

Així que sí, el lector atent tornarà a preguntar-se: per què no prens un servei existent com ngrok o similar? I tornarà a tenir raó. Però això és un servei, s'ha de demonitzar de nou, també pot costar diners i en general no és esportiu. Per tant, crearem bicicletes a partir de materials de ferralla.

Tasca: hi ha un proxy molt lluny de NAT, cal penjar-lo en un dels ports d'un VPS que té una IP blanca i es troba a la vora del món.

És lògic suposar que això es pot resoldre ja sigui mitjançant el reenviament de ports (que s'implementa mitjançant l'esmentat ssh), o combinant maquinari en una xarxa virtual mitjançant VPN. AMB ssh sabem treballar, autossh És avorrit de prendre, així que prenem OpenVPN.

DigitalOcean té meravellós manul sobre aquest tema. No hi tinc res a afegir. I la configuració resultant es pot connectar amb força facilitat amb el client OpenVPN i systemd. Només cal posar-lo (config). /etc/openvpn/client/ i no oblideu canviar l'extensió a .conf. Després d'això, tireu del servei [email protected]no t'oblidis de fer-ho per ella enable i alegra't que tot s'ha volat.

Per descomptat, hem de desactivar qualsevol redirecció del trànsit a la VPN de nova creació, perquè no volem reduir la velocitat a la màquina client fent passar trànsit per mitja bola.

I sí, hem de registrar una adreça IP estàtica al servidor VPN per al nostre client. Això serà necessari una mica més endavant en la història. Per fer-ho, cal habilitar ifconfig-pool-persist, editar ipp.txt, inclòs amb OpenVPN i habiliteu client-config-dir, a més d'editar la configuració del client desitjat afegint ifconfig-push amb la màscara correcta i l'adreça IP desitjada.

Acte segon

Ara tenim una màquina a la "xarxa" que s'enfronta a Internet i que es pot utilitzar amb finalitats egoistes. És a dir, redirigeix ​​part del trànsit a través d'ell.

Per tant, una tasca nova: cal desactivar el trànsit que arriba a un dels ports VPS amb una IP blanca perquè aquest trànsit vagi a la xarxa virtual acabada de connectar i la resposta pugui tornar d'allà.

Solució: és clar iptables! Quan més tindreu una oportunitat tan meravellosa de practicar amb ell?

La configuració requerida es pot trobar amb força rapidesa, en tres hores, un centenar de maldicions i un grapat de nervis perduts, perquè depurar xarxes és un procediment molt concret.

Primer, heu d'habilitar la redirecció de trànsit al nucli. Aquesta cosa es diu ipv4.ip_forward i s'habilita de manera lleugerament diferent segons el sistema operatiu i el gestor de xarxa.

En segon lloc, heu de seleccionar un port al VPS i embolicar tot el trànsit que hi va a una subxarxa virtual. Això es pot fer, per exemple, així:

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

Aquí redirigim tot el trànsit TCP que arriba al port 8080 de la interfície externa a una màquina amb IP 10.8.0.2 i el mateix port 8080.

Per a aquells que volen els detalls bruts de la feina netfilter, iptables i l'encaminament en general, és absolutament necessari contemplar-ho aquest o aquest.

Així doncs, ara els nostres paquets volen a la subxarxa virtual i... s'hi queden. Més precisament, la resposta del proxy de mitjons torna a través de la passarel·la predeterminada de la màquina amb Dante i el destinatari la deixa anar, perquè a les xarxes no és habitual enviar una sol·licitud a una IP i rebre una resposta d'una altra. Per tant, hem de continuar conjurant.

Per tant, ara heu de redirigir tots els paquets del servidor intermediari a la subxarxa virtual cap al VPS amb una IP blanca. Aquí la situació és una mica pitjor, perquè és just iptables no tindrem prou, perquè si corregim l'adreça de destinació abans d'enrutar (PREROUTING), aleshores el nostre paquet no volarà a Internet i, si no ho arreglem, el paquet anirà a default gateway. Per tant, heu de fer el següent: recordeu la cadena mangle, per marcar els paquets iptables i embolicar-los en una taula d'encaminament personalitzada que els enviarà on haurien d'anar.

No més aviat dir que fet:

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

Agafem el trànsit de sortida, marquem tot el que vola des del port on es troba el proxy (8080 en el nostre cas), redirigem tot el trànsit marcat a la taula d'encaminament amb el número 80 (en general, el número no depèn de res, només volíem a) i afegiu una única regla , segons la qual tots els paquets inclosos en aquesta taula volen a la subxarxa VPN.

Genial! Ara els paquets volen cap al VPS... i moren allà. Perquè VPS no sap què fer amb ells. Per tant, si no us molesteu, simplement podeu redirigir tot el trànsit que arriba des de la subxarxa 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í, tot el que arriba de la subxarxa 10.8.0.0 amb una màscara de 255.255.255.000 s'embolica en font-NAT i vola a la interfície predeterminada, que es converteix a Internet. És important tenir en compte que això només funcionarà si reenviem el port de manera transparent, és a dir, el port d'entrada del VPS coincideix amb el port del nostre proxy. En cas contrari hauràs de patir una mica més.

En algun lloc ara tot hauria de començar a funcionar. I només queda una mica: no us oblideu d'assegurar-vos que totes les configuracions iptables и route no va continuar després del reinici. Per iptables hi ha fitxers especials com /etc/iptables/rules.v4(en el cas d'Ubuntu), però per a rutes tot és una mica més complicat. Els vaig empènyer up/down Scripts OpenVPN, tot i que crec que es podrien haver fet de manera més decent.

Embolica el trànsit de l'aplicació al servidor intermediari

Així doncs, tenim un proxy amb autenticació al país desitjat, accessible mitjançant una adreça IP blanca estàtica. Només queda utilitzar-lo i redirigir-hi el trànsit des de Spotify. Però hi ha un matís, com s'ha esmentat anteriorment, la contrasenya d'inici de sessió per al proxy a Spotify no funciona, així que buscarem com evitar-ho.

Per començar, recordem-ne proxy. Coses fantàstiques, però costa tant com una nau (40 dòlars). Amb aquests diners podem tornar a comprar premium i acabar amb això. Per tant, buscarem més anàlegs lliures i oberts al Mac (sí, volem escoltar música al Mac). Descobrim una eina sencera: properac. I amb molt de gust anirem a punxar-lo.

Però l'alegria serà de curta durada, perquè resulta que cal habilitar el mode de depuració i les extensions personalitzades del nucli a MacOS, arxivar una configuració senzilla i entendre que aquesta eina té exactament el mateix problema que Spotify: no pot passar l'autenticació mitjançant el contrasenya d'inici de sessió a socks-proxy.

En algun lloc per aquí és hora de flipar i comprar un premium... però no! Intentem demanar que s'arregli, és de codi obert! Fem-ho bitllet. I com a resposta tenim una història desgarradora sobre com l'únic responsable ja no té un MacBook i a la merda, no una solució.

Ens tornarem a molestar. Però després recordarem la nostra joventut i C, activarem el mode de depuració a Dante, explorarem centenars de kilobytes de registres, anar a RFC1927 per obtenir informació sobre el protocol SOCKS5, mirem Xcode i busquem el problema. N'hi ha prou amb corregir un caràcter de la llista de codis de mètode que ofereix el client per a l'autenticació i tot comença a funcionar com un rellotge. Ens alegrem, recollim el binari de llançament, ho fem petició d'extracció i entrem a la posta de sol i anem al següent punt.

Automatitza-ho

Un cop funciona Proximac, cal demonitzar-lo i oblidar-lo. Hi ha un sistema complet d'inicialització adequat per a això, que es troba a MacOS, és a dir llançat.

Ho trobem ràpidament manual i entenem que això no és gens systemd i aquí és quasi una primicia i xml. No hi ha configuracions elegants per a tu, ni ordres com status, restart, daemon-reload. Només tipus hardcore start-stop, list-grep, unload-load i moltes més rareses. Superant tot això escrivim plist, carregant. No funciona. Estudiem el mètode de depuració del dimoni, depurem-lo, entenem què hi ha ENV fins i tot PATH no vam lliurar el normal, discutim, el portem (afegint /sbin и /usr/local/bin) i finalment estem contents amb l'arrencada automàtica i el funcionament estable.

Exhalar

Quin és el resultat? Una setmana d'aventures, un zoològic agenollat ​​de serveis que és estimat per al cor i fa el que se li demana. Una mica de coneixement en àrees tècniques dubtoses, una mica de codi obert i un somriure a la cara pel pensament "Ho vaig fer!"

PD: això no és una crida al boicot als capitalistes, a l'estalvi de llumins o a l'astúcia total, sinó només una indicació de les possibilitats d'investigació i desenvolupament on, en general, no les esperes.

Font: www.habr.com

Afegeix comentari