Eventyr ut av det blå

Eventyr ut av det blå

Hvordan Spotify kan hjelpe deg med å studere demoner, RFC-er, nettverk og fremme åpen kildekode. Eller hva skjer hvis du ikke kan betale, men du virkelig vil ha noen førsteklasses godbiter.

begynner

På den tredje dagen ble det lagt merke til at Spotify viste annonser basert på landet til IP-adressen. Det ble også bemerket at i noen land ble reklame ikke importert i det hele tatt. For eksempel i republikken Hviterussland. Og så ble det laget en "genial" plan for å deaktivere annonsering på en ikke-premiumkonto.

Litt om Spotify

Generelt sett har Spotify en merkelig policy. Broren vår må bli ganske vridd for å kjøpe premium: endre plasseringen i profilen til utlandet, se etter et passende gavekort som kun kan betales med PayPal, som har oppført seg rart i det siste og vil ha en haug med dokumenter. Generelt er det også et eventyr, men av en annen rekkefølge. Selv om de fleste gjør dette for mobilversjonens skyld, er jeg ikke interessert i det. Derfor vil alt nedenfor bare hjelpe når det gjelder skrivebordsversjonen. Dessuten vil det ikke være noen utvidelse av funksjoner. Bare å kutte av noen av de ekstra.

Hvorfor er det så komplisert?

Og det tenkte jeg da jeg registrerte socks-proxy-dataene i Spotify-konfigurasjonen. Problemet viste seg å være at autentisering i sokker ved hjelp av innlogging og passord ikke fungerer. I tillegg gjør utviklere regelmessig noe rundt proxyen: noen ganger tillater det, noen ganger forbyr det, noen ganger bryter det, noe som gir opphav til hele paneler med diskusjoner på off-site.

Det ble besluttet å ikke stole på ustabile funksjoner og å finne noe mer pålitelig og interessant.

Et sted her må leseren spørre: hvorfor ikke ta ssh med en nøkkel -D og det er slutten på det? Og generelt vil han ha rett. Men for det første må dette fortsatt demoniseres og bli venner med autossh, for ikke å tenke på ødelagte forbindelser. Og for det andre: det er for enkelt og kjedelig.

I rekkefølge

Som vanlig, la oss gå fra venstre til høyre, topp til bunn og beskrive alt vi trenger for å implementere vår "enkle" idé.

Først trenger du en proxy

Og det er mange alternativer på en gang:

  • du kan bare gå og ta fra åpne proxy-lister. Billig (eller rettere sagt for ingenting), men absolutt upålitelig og levetiden til slike proxyer har en tendens til null. Derfor vil det være nødvendig å finne/skrive en parser for proxy-lister, filtrere dem etter ønsket type og land, og spørsmålet om å erstatte den funnet proxy i Spotify forblir åpent (vel, kanskje gjennom HTTP_PROXY overføre og opprette en tilpasset innpakning for binæren slik at all annen trafikk ikke sendes dit).
  • Du kan kjøpe en lignende proxy og redde deg selv fra de fleste problemene beskrevet ovenfor. Men til prisen av en proxy kan du umiddelbart kjøpe premium på Spotify, og dette er ikke praktisk for den opprinnelige oppgaven.
  • Hev din. Som du sikkert har gjettet, er dette vårt valg.

Helt tilfeldig kan det vise seg at du har en venn med en server i republikken Hviterussland eller et annet lite land. Du må bruke denne og rulle ut ønsket proxy på den. Spesielle kjennere kan nøye seg med en venn med en ruter på DD-WRT eller lignende programvare. Men det hans fantastisk verden og denne verden passer tydeligvis ikke inn i rammen av denne historien.

Så alternativene våre: Blekksprut - ikke inspirerende, og jeg vil ikke ha en HTTP-proxy, det er allerede for mange av denne protokollen rundt. Og i SOCKS-området er det ikke noe fornuftig bortsett fra Dante har ikke levert enda. Derfor, la oss ta det.

Ikke vent på Dantes manual om installasjon og konfigurering. Han bare google og er ikke av spesiell interesse. I minimumskonfigurasjonen må du kaste inn alle slags client pass, socks pass, registrer grensesnittene riktig og ikke glem å legge til socksmethod: username. I dette skjemaet, for autentisering, vil logopasset bli tatt fra systembrukerne. Og delen om sikkerhet: å forby tilgang til localhost, begrense brukere osv. - dette er rent individuelt, avhengig av personlig paranoia.

Distribuer en proxy som vender mot nettverket

Stykket er i to akter.

Akt én

Vi har sortert ut proxyen, nå må vi få tilgang til den fra det globale nettet. Hvis du har en maskin med hvit IP i ønsket land, kan du trygt hoppe over dette punktet. Vi har ikke en (vi, som nevnt ovenfor, er vert hos venner) og den nærmeste hvite IP-adressen er et sted i Tyskland, så vi vil studere nettverk.

Så ja, den oppmerksomme leseren vil igjen spørre: hvorfor liker du ikke en eksisterende tjeneste ngrok eller liknende? Og han vil ha rett igjen. Men dette er en tjeneste, den må igjen demoniseres, den kan også koste penger og generelt sett er den ikke sportslig. Derfor skal vi lage sykler av skrapmaterialer.

Oppgave: det er en proxy et sted langt bak NAT, du må henge den på en av portene til en VPS som har en hvit IP og er plassert i utkanten av verden.

Det er logisk å anta at dette kan løses enten ved portvideresending (som implementeres gjennom ovennevnte ssh), eller ved å kombinere maskinvare til et virtuelt nettverk via VPN. MED ssh vi vet hvordan vi skal jobbe, autossh Det er kjedelig å ta, så la oss ta OpenVPN.

DigitalOcean har fantastisk manul om denne saken. Jeg har ingenting å legge til. Og den resulterende konfigurasjonen kan ganske enkelt kobles til OpenVPN-klienten og systemd. Bare legg den inn (config). /etc/openvpn/client/ og ikke glem å endre utvidelsen til .conf. Etter det, trekk tjenesten [email protected]ikke glem å gjøre det for henne enable og glede deg over at alt fløy avgårde.

Selvfølgelig må vi deaktivere enhver omdirigering av trafikk til den nyopprettede VPN-en, fordi vi ikke ønsker å redusere hastigheten på klientmaskinen ved å sende trafikk gjennom en halv ball.

Og ja, vi må registrere en statisk IP-adresse på VPN-serveren for klienten vår. Dette vil være nødvendig litt senere i historien. For å gjøre dette må du aktivere ifconfig-pool-persist, redigere ipp.txt, inkludert med OpenVPN og aktiver client-config-dir, pluss rediger konfigurasjonen til ønsket klient ved å legge til ifconfig-push med riktig maske og ønsket IP-adresse.

Akt to

Nå har vi en maskin på "nettverket" som vender mot Internett og kan brukes til egoistiske formål. Nemlig omdirigere en del av trafikken gjennom den.

Så, en ny oppgave: du må slå av trafikken som kommer til en av VPS-portene med en hvit IP slik at denne trafikken går til det nylig tilkoblede virtuelle nettverket og svaret kan komme tilbake derfra.

Løsning: selvfølgelig iptables! Når ellers vil du få en så fantastisk mulighet til å øve med ham?

Den nødvendige konfigurasjonen kan bli funnet ganske raskt, på tre timer, hundre banneord og en håndfull bortkastede nerver, fordi feilsøking av nettverk er en veldig spesifikk prosedyre.

Først må du aktivere trafikkomdirigering i kjernen. Denne tingen heter ipv4.ip_forward og er aktivert litt forskjellig avhengig av OS og nettverksadministrator.

For det andre må du velge en port på VPS-en og pakke all trafikk som går til den inn i et virtuelt subnett. Dette kan for eksempel gjøres slik:

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

Her omdirigerer vi all TCP-trafikk som kommer til port 8080 på det eksterne grensesnittet til en maskin med IP 10.8.0.2 og samme port 8080.

For de som vil ha de skitne detaljene i jobben netfilter, iptables og ruting generelt, er det absolutt nødvendig å tenke på dette eller dette.

Så nå flyr pakkene våre til det virtuelle undernettet og... de blir der. Mer presist, svaret fra socks proxy flyr tilbake gjennom standard gateway på maskinen med Dante og mottakeren dropper det, fordi i nettverk er det ikke vanlig å sende en forespørsel til en IP og motta et svar fra en annen. Derfor må vi fortsette å trylle.

Så nå må du omdirigere alle pakker fra proxyen tilbake til det virtuelle subnettet mot VPS med en hvit IP. Her er situasjonen litt verre, fordi den er rettferdig iptables vi vil ikke ha nok, fordi hvis vi korrigerer destinasjonsadressen før ruting (PREROUTING), vil ikke pakken vår fly til Internett, og hvis vi ikke fikser den, vil pakken gå til default gateway. Så du må gjøre følgende: husk kjeden mangle, for å merke pakker gjennom iptables og pakk dem inn i en tilpasset rutetabell som sender dem dit de skal.

Ikke før sagt enn 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 trafikk, merker alt som flyr fra porten som proxyen sitter på (8080 i vårt tilfelle), omdirigerer all merket trafikk til rutetabellen med nummer 80 (generelt sett er ikke antallet avhengig av noe, vi ville bare til) og legg til en enkelt regel , ifølge hvilken alle pakkene som er inkludert i denne tabellen, flyr til VPN-undernettet.

Flott! Nå flyr pakkene tilbake mot VPS... og dør der. Fordi VPS ikke vet hva de skal gjøre med dem. Derfor, hvis du ikke gidder, kan du ganske enkelt omdirigere all trafikk som kommer fra det virtuelle undernettet tilbake til Internett:

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

Her er alt som kommer fra 10.8.0.0-undernettet med en maske på 255.255.255.000 pakket inn i kilde-NAT og flyr til standardgrensesnittet, som er snudd til Internett. Det er viktig å merke seg at denne tingen bare vil fungere hvis vi transparent videresender porten, det vil si at den innkommende porten på VPS samsvarer med porten til proxyen vår. Ellers må du lide litt mer.

Et sted nå burde alt begynne å fungere. Og bare litt gjenstår: ikke glem å sørge for at alle konfigurasjoner iptables и route fortsatte ikke etter omstart. Til iptables det er spesielle filer som /etc/iptables/rules.v4(i tilfellet med Ubuntu), men for ruter er alt litt mer komplisert. Jeg dyttet dem inn up/down OpenVPN-skript, selv om jeg tror de kunne vært gjort mer anstendig.

Pakk inn trafikk fra applikasjonen i proxy

Så vi har en proxy med autentisering i ønsket land, tilgjengelig via en statisk hvit IP-adresse. Alt som gjenstår er å bruke det og omdirigere trafikk fra Spotify dit. Men det er en nyanse, som nevnt ovenfor, påloggingspassordet for proxyen i Spotify fungerer ikke, så vi vil se etter hvordan vi kan omgå det.

Til å begynne med, la oss huske ca proxy. Flotte greier, men det koster like mye som et romskip ($40). Med disse pengene kan vi igjen kjøpe premium og være ferdige med det. Derfor vil vi se etter flere gratis og åpne analoger på Mac (ja, vi vil høre på musikk på Mac). La oss finne ett helt verktøy: proximac. Og vi vil gjerne gå og stikke ham.

Men gleden vil være kortvarig, fordi det viser seg at du må aktivere feilsøkingsmodus og tilpassede kjerneutvidelser i MacOS, arkivere en enkel konfigurasjon og forstå at dette verktøyet har nøyaktig det samme problemet som Spotify: det kan ikke bestå autentisering ved å bruke innloggingspassord på socks-proxy.

Et eller annet sted her er det på tide å flippe ut og kjøpe en premium... men nei! La oss prøve å be om at det blir fikset, det er åpen kildekode! La oss gjøre billett. Og som svar får vi en hjerteskjærende historie om hvordan den eneste vedlikeholderen ikke lenger har en MacBook og til helvete med den, ikke en løsning.

Vi blir lei oss igjen. Men så vil vi huske ungdommen vår og C, slå på feilsøkingsmodusen i Dante, grave gjennom hundrevis av kilobyte med logger, gå til RFC1927 for informasjon om SOCKS5-protokollen, la oss se på Xcode og finne problemet. Det er nok å korrigere ett tegn i listen over metodekoder som klienten tilbyr for autentisering, og alt begynner å fungere som smurt. Vi gleder oss, vi samler utgivelsesbinæren, vi gjør det pull forespørsel og vi går inn i solnedgangen og går til neste punkt.

Automatiser det

Når Proximac fungerer, må den demoniseres og glemmes. Det er ett helt initialiseringssystem som egner seg for dette, som finnes i MacOS, nemlig launchd.

Vi finner det raskt Håndbok og vi forstår at dette ikke er det i det hele tatt systemd og her er det nesten et scoop og xml. Ingen fancy konfigurasjoner for deg, ingen kommandoer som status, restart, daemon-reload. Bare hardcore type start-stop, list-grep, unload-load og mange flere rariteter. Å overvinne alt dette skriver vi plist, lasting. Virker ikke. Vi studerer metoden for å feilsøke demonen, feilsøker den, forstår hva som er der ENV selv PATH vi leverte ikke den vanlige, vi argumenterer, vi henter den inn (legger til /sbin и /usr/local/bin) og til slutt er vi fornøyd med autostart og stabil drift.

Puste ut

Hva er resultatet? En uke med eventyr, en knelende dyrehage fra tjenester som er kjære for hjertet og gjør det som kreves av det. Litt kunnskap på tvilsomme tekniske områder, litt åpen kildekode og et smil om munnen fra tanken «jeg klarte det!»

PS: dette er ikke en oppfordring til boikott av kapitalister, for å spare på fyrstikker eller for total list, men bare en indikasjon på mulighetene for forskning og utvikling der du generelt sett ikke forventer dem.

Kilde: www.habr.com

Legg til en kommentar