Przygody niespodziewane

Przygody niespodziewane

Jak Spotify może pomóc Ci w badaniu demonów, RFC, sieci i promowaniu open source. Albo co się stanie, jeśli nie możesz zapłacić, ale naprawdę chcesz gadżetów premium.

początek

Trzeciego dnia zauważono, że Spotify wyświetla reklamy w oparciu o kraj adresu IP. Odnotowano także, że w niektórych krajach reklamy w ogóle nie były importowane. Na przykład w Republice Białorusi. A potem powstał „genialny” plan wyłączenia reklam na koncie innym niż premium.

Trochę o Spotify

Ogólnie rzecz biorąc, Spotify ma dziwną politykę. Nasz brat musi się nieźle nagimnastykować, żeby kupić premium: zmień lokalizację w swoim profilu na zagraniczną, poszukaj odpowiedniej karty podarunkowej, za którą można zapłacić tylko za pomocą PayPala, który ostatnio dziwnie się zachowuje i potrzebuje kilku dokumentów. W sumie to też przygoda, ale innego rodzaju. Chociaż większość osób robi to ze względu na wersję mobilną, mnie to nie interesuje. Dlatego wszystko poniżej pomoże tylko w przypadku wersji na komputery stacjonarne. Co więcej, nie będzie rozbudowy funkcji. Po prostu odetnę kilka dodatkowych.

Dlaczego to takie skomplikowane?

I tak pomyślałem, rejestrując dane skarpetek-proxy w konfiguracji Spotify. Problemem okazało się, że nie działa uwierzytelnianie w skarpetkach przy użyciu loginu i hasła. Ponadto programiści regularnie robią coś wokół serwera proxy: albo zezwalają na to, a następnie zabraniają go lub łamią, co powoduje całe panele dyskusji poza witryną.

Zdecydowano nie polegać na niestabilnych funkcjach i znaleźć coś bardziej niezawodnego i interesującego.

Gdzieś tutaj czytelnik musi zapytać: dlaczego nie wziąć ssh z kluczem -D i to już koniec? I ogólnie będzie miał rację. Ale po pierwsze, nadal należy to zdemonizować i zaprzyjaźnić się z autossh, aby nie myśleć o zerwanych połączeniach. A po drugie: to zbyt proste i nudne.

W celu

Jak zwykle przejdźmy od lewej do prawej, od góry do dołu i opiszmy wszystko, czego potrzebujemy, aby wdrożyć nasz „prosty” pomysł.

Najpierw potrzebujesz proxy

Istnieje wiele alternatyw na raz:

  • możesz po prostu iść i wziąć z otwartych list serwerów proxy. Tanie (a raczej za darmo), ale absolutnie zawodne, a żywotność takich proxy dąży do zera. Należałoby więc znaleźć/napisać parser dla list proxy, przefiltrować je po żądanym typie i kraju, a kwestia podstawienia znalezionego proxy w Spotify pozostaje otwarta (no, może przez HTTP_PROXY transfer i utwórz niestandardowe opakowanie dla pliku binarnego, aby cały pozostały ruch nie był tam wysyłany).
  • Możesz kupić podobny serwer proxy i uchronić się przed większością problemów opisanych powyżej. Ale za cenę proxy możesz od razu kupić premium na Spotify, co nie jest praktyczne w przypadku pierwotnego zadania.
  • Podnieś swoje. Jak zapewne się domyślacie, jest to nasz wybór.

Czysto przez przypadek może się okazać, że masz znajomego z serwerem w Republice Białorusi lub innym małym kraju. Musisz tego użyć i wdrożyć na nim żądany serwer proxy. Wyjątkowi koneserzy mogą zadowolić się przyjacielem z włączonym routerem DD-WRT lub podobne oprogramowanie. Ale tam jego cudowny świat i ten świat wyraźnie nie mieści się w ramach tej historii.

Zatem nasze opcje: Squid – nie jest inspirujący i nie chcę proxy HTTP, jest już zbyt wiele tego protokołu. A w obszarze SOCKS nie ma nic sensownego poza Dante jeszcze nie dostarczyłem. Dlatego weźmy to.

Nie czekaj na podręcznik Dantego dotyczący instalacji i konfiguracji. On po prostu googluję i nie jest szczególnie interesujący. W minimalnej konfiguracji musisz wrzucić wszelkiego rodzaju client pass, socks pass, poprawnie zarejestruj interfejsy i nie zapomnij dodać socksmethod: username. W tej formie do uwierzytelnienia od użytkowników systemu zostanie pobrany logopass. A część dotycząca bezpieczeństwa: zakaz dostępu do localhost, ograniczanie użytkowników itp. - to kwestia czysto indywidualna, zależna od osobistej paranoi.

Wdróż serwer proxy skierowany do sieci

Spektakl jest w dwóch aktach.

Akt pierwszy

Rozwiązaliśmy problem z serwerem proxy, teraz musimy uzyskać do niego dostęp z globalnej sieci. Jeśli masz maszynę z białym adresem IP w wybranym kraju, możesz bezpiecznie pominąć ten punkt. Nie mamy takiego (jak wspomniano powyżej, gościmy u znajomych), a najbliższy biały adres IP znajduje się gdzieś w Niemczech, więc będziemy badać sieci.

Więc tak, uważny czytelnik ponownie zapyta: dlaczego nie skorzystasz z istniejącej usługi, takiej jak nrok lub podobne? I znowu będzie miał rację. Ale to jest usługa, znowu trzeba ją demonizować, może też kosztować i w ogóle nie jest sportowa. Dlatego będziemy tworzyć rowery ze złomu.

Zadanie: gdzieś daleko za NAT-em znajduje się serwer proxy, należy go powiesić na jednym z portów VPS-a, który ma biały adres IP i jest zlokalizowany na krańcu świata.

Logiczne jest założenie, że można to rozwiązać poprzez przekierowanie portów (co jest realizowane za pomocą wyżej wymienionego ssh) lub łącząc sprzęt w sieć wirtualną za pośrednictwem VPN. Z ssh wiemy jak pracować, autossh To nudne, więc weźmy OpenVPN.

DigitalOcean ma wspaniały manul w tej sprawie. Nie mam nic do dodania. Powstałą konfigurację można dość łatwo połączyć z klientem OpenVPN i systemd. Po prostu włóż go (config). /etc/openvpn/client/ i nie zapomnij zmienić rozszerzenia na .conf. Następnie pociągnij usługę [email protected]nie zapomnij zrobić tego dla niej enable i ciesz się, że wszystko odleciało.

Musimy oczywiście wyłączyć wszelkie przekierowania ruchu do nowo utworzonego VPN, ponieważ nie chcemy zmniejszać prędkości na komputerze klienckim przepuszczając ruch przez pół kuli.

I tak, musimy zarejestrować statyczny adres IP na serwerze VPN dla naszego klienta. Będzie to potrzebne nieco w dalszej części historii. Aby to zrobić, musisz włączyć ifconfig-pool-persist, edytować ipp.txt, dołączony do OpenVPN i włącz katalog-konfiguracyjny klienta, a także edytuj konfigurację żądanego klienta, dodając ifconfig-push z poprawną maską i żądanym adresem IP.

Akt drugi

Teraz mamy maszynę w „sieci”, która jest zwrócona w stronę Internetu i może być wykorzystywana do celów egoistycznych. Mianowicie przekieruj przez niego część ruchu.

A więc nowe zadanie: należy wyłączyć ruch przychodzący na jeden z portów VPS o białym adresie IP, aby ruch ten trafiał do nowo podłączonej sieci wirtualnej i stamtąd odpowiedź mogła wrócić.

Rozwiązanie: oczywiście iptables! Kiedy jeszcze będziesz miał tak wspaniałą okazję poćwiczyć z nim?

Wymaganą konfigurację można znaleźć dość szybko, w trzy godziny, sto wulgaryzmów i garść zmarnowanych nerwów, bo debugowanie sieci to bardzo specyficzna procedura.

Najpierw musisz włączyć przekierowywanie ruchu w jądrze. Ta rzecz nazywa się ipv4.ip_forward i jest włączany nieco inaczej w zależności od systemu operacyjnego i menedżera sieci.

Po drugie, musisz wybrać port na VPS i przenieść cały ruch do niego do wirtualnej podsieci. Można to zrobić na przykład w następujący sposób:

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

Tutaj przekierowujemy cały ruch TCP przychodzący na port 8080 interfejsu zewnętrznego na maszynę z adresem IP 10.8.0.2 i tym samym portem 8080.

Dla tych, którzy chcą poznać brudne szczegóły pracy netfilter, iptables i ogólnie trasowanie, absolutnie konieczne jest rozważenie to lub to.

Zatem teraz nasze pakiety lecą do wirtualnej podsieci i... tam pozostają. Dokładniej, odpowiedź od proxy skarpetek leci z powrotem przez bramę domyślną na komputerze z Dante, a odbiorca ją odrzuca, ponieważ w sieciach nie jest zwyczajowo wysyłanie żądania do jednego adresu IP i otrzymywanie odpowiedzi z innego. Dlatego musimy nadal czarować.

Zatem teraz musisz przekierować wszystkie pakiety z serwera proxy z powrotem do wirtualnej podsieci w stronę VPS z białym adresem IP. Tutaj sytuacja jest trochę gorsza, bo po prostu iptables nie wystarczy nam, bo jeśli poprawimy adres docelowy przed trasą (PREROUTING), to nasza paczka nie poleci do Internetu, a jeśli tego nie naprawimy, paczka trafi do default gateway. Musisz więc wykonać następujące czynności: zapamiętaj łańcuch mangle, aby oznaczyć pakiety iptables i zawiń je w niestandardową tabelę routingu, która wyśle ​​je tam, gdzie powinny się udać.

Ledwo powiedziane, a już zrobione:

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

Bierzemy ruch wychodzący, zaznaczamy wszystko, co leci z portu, na którym znajduje się serwer proxy (w naszym przypadku 8080), przekierowujemy cały zaznaczony ruch do tablicy routingu numerem 80 (ogólnie liczba nie zależy od niczego, po prostu chcieliśmy do) i dodaj jedną regułę, zgodnie z którą wszystkie pakiety zawarte w tej tabeli lecą do podsieci VPN.

Świetnie! Teraz pakiety lecą z powrotem do VPS... i tam giną. Ponieważ VPS nie wie, co z nimi zrobić. Dlatego jeśli Ci to nie przeszkadza, możesz po prostu przekierować cały ruch przychodzący z wirtualnej podsieci z powrotem do Internetu:

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

Tutaj wszystko, co przychodzi z podsieci 10.8.0.0 z maską 255.255.255.000, jest opakowane w źródłowy NAT i leci do domyślnego interfejsu, który jest włączony do Internetu. Warto zauważyć, że to zadziała tylko wtedy, gdy w przejrzysty sposób przekażemy port, czyli port przychodzący na VPS będzie zgodny z portem naszego proxy. Inaczej będziesz musiał jeszcze trochę pocierpieć.

Gdzieś teraz wszystko powinno zacząć działać. I jeszcze tylko trochę: nie zapomnij upewnić się, że wszystkie pliki configs iptables и route nie był kontynuowany po ponownym uruchomieniu. Dla iptables istnieją specjalne pliki, takie jak /etc/iptables/rules.v4(w przypadku Ubuntu), ale w przypadku tras wszystko jest trochę bardziej skomplikowane. Wepchnąłem je do środka up/down Skrypty OpenVPN, chociaż myślę, że można je było zrobić bardziej przyzwoicie.

Zawijaj ruch z aplikacji w proxy

Mamy więc serwer proxy z uwierzytelnianiem w wybranym kraju, dostępny za pośrednictwem statycznego białego adresu IP. Pozostaje tylko z niego skorzystać i przekierować tam ruch ze Spotify. Ale jest niuans, jak wspomniano powyżej, hasło logowania do proxy w Spotify nie działa, więc zastanowimy się, jak to obejść.

Na początek przypomnijmy sobie pełnomocnik. Świetna rzecz, ale kosztuje tyle, co statek kosmiczny (40 dolarów). Za te pieniądze możemy znowu kupić premium i mieć to już za sobą. Dlatego będziemy szukać bardziej darmowych i otwartych analogów na Macu (tak, chcemy słuchać muzyki na Macu). Odkryjmy jedno całe narzędzie: bliskość. I chętnie go szturchniemy.

Ale radość będzie krótkotrwała, bo okazuje się, że trzeba włączyć tryb debugowania i niestandardowe rozszerzenia jądra w MacOS, dokonać prostej konfiguracji i zrozumieć, że to narzędzie ma dokładnie ten sam problem co Spotify: nie może przejść uwierzytelnienia za pomocą hasło logowania na skarpetkach-proxy.

Gdzieś tutaj nadszedł czas, aby wpaść w panikę i kupić premium… ale nie! Spróbujmy poprosić o naprawienie tego, to open source! Zróbmy bilet. W odpowiedzi otrzymujemy rozdzierającą serce historię o tym, że jedyny opiekun nie ma już MacBooka i do diabła z nim, a nie rozwiązaniem.

Znów będziemy zdenerwowani. Ale wtedy przypomnimy sobie naszą młodość i C, włączymy tryb debugowania w Dante, przekopiemy się przez setki kilobajtów logów, przejdziemy do RFC1927 aby uzyskać informacje na temat protokołu SOCKS5, spójrzmy na Xcode i znajdźmy problem. Wystarczy poprawić jeden znak na liście kodów metod, które klient oferuje do uwierzytelnienia i wszystko zaczyna działać jak w zegarku. Cieszymy się, zbieramy wydanie binarne, robimy to prośba o pociągnięcie i wchodzimy w zachód słońca i przechodzimy do następnego punktu.

Zautomatyzuj to

Kiedy Proximac zadziała, należy go zdemonizować i zapomnieć. Odpowiedni jest do tego jeden cały system inicjalizacji, który można znaleźć w systemie MacOS, a mianowicie uruchomiona.

Znajdujemy to szybko podręcznik i rozumiemy, że wcale tak nie jest systemd a tutaj to prawie miarka i xml. Żadnych wymyślnych konfiguracji dla Ciebie, żadnych poleceń takich jak status, restart, daemon-reload. Tylko taki hardcorowy start-stop, list-grep, unload-load i wiele innych ciekawostek. Pokonując to wszystko piszemy plist, Ładowanie. Nie działa. Badamy metodę debugowania demona, debugujemy go, rozumiemy, co tam jest ENV nawet PATH normalnego nie dostarczyliśmy, kłócimy się, wnosimy (dodajemy /sbin и /usr/local/bin) i w końcu jesteśmy zadowoleni z autostartu i stabilnej pracy.

Wydychać

Jaki jest wynik? Tydzień przygód, klęczące zoo od służb, które są bliskie sercu i robią to, co się od nich wymaga. Trochę wiedzy w wątpliwych obszarach technicznych, odrobina open source i uśmiech na twarzy od myśli „udało się!”

PS: to nie jest wezwanie do bojkotu kapitalistów, do oszczędzania na zapałkach czy do totalnej przebiegłości, ale jedynie wskazanie możliwości badań i rozwoju tam, gdzie się ich w ogóle nie spodziewamy.

Źródło: www.habr.com

Dodaj komentarz