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å
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
Ikke vent på Dantes manual om installasjon og konfigurering. Han 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
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 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å
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
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
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
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
Vi finner det raskt 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