Kalandok a semmiből

Hogyan segíthet a Spotify a démonok, RFC-k, hálózatok tanulmányozásában és a nyílt forráskód népszerűsítésében. Vagy mi történik, ha nem tud fizetni, de nagyon szeretne prémium finomságokat.

kezdet

A harmadik napon észrevették, hogy a Spotify az IP-cím országa alapján jelenít meg hirdetéseket. Azt is megjegyezték, hogy egyes országokban egyáltalán nem importáltak reklámot. Például a Fehérorosz Köztársaságban. Aztán egy „zseniális” terv született a hirdetés letiltására egy nem prémium fiókban.

Egy kicsit a Spotify-ról

Általánosságban elmondható, hogy a Spotifynak furcsa politikája van. Testvérünknek eléggé csavarodnia kell ahhoz, hogy prémiumot vásároljon: a profiljában cserélje ki a helyet a tengerentúlra, keressen egy megfelelő ajándékkártyát, amit csak PayPal-lal lehet fizetni, ami mostanában furcsán viselkedik, és egy csomó dokumentumot akar. Általában ez is kaland, de más sorrendben. Bár a legtöbben a mobil verzió kedvéért csinálják ezt, engem ez nem érdekel. Ezért az alábbiakban leírtak csak az asztali verzió esetében segítenek. Ráadásul a funkciók nem bővülnek. Csak le kell vágni néhány pluszt.

Miért olyan bonyolult?

És erre gondoltam, amikor a Spotify konfigban regisztráltam a socks-proxy adatokat. A probléma az volt, hogy a zokniban a bejelentkezés és a jelszó segítségével történő hitelesítés nem működik. Ráadásul a fejlesztők rendszeresen tesznek valamit a proxy körül: vagy engedélyezik, majd megtiltják, vagy megtörik, ami viták egész paneljére ad okot a webhelyen kívül.

Úgy döntöttünk, hogy nem hagyatkozunk instabil funkciókra, és keresünk valami megbízhatóbb és érdekesebbet.

Valahol itt az olvasónak fel kell kérdeznie: miért nem veszi ssh kulccsal -D és itt a vége? És általában igaza lesz. De először is, ezt még mindig démonizálni kell, és meg kell barátkozni az autossh-val, hogy ne gondoljon szakadt kapcsolatokra. Másodszor pedig: túl egyszerű és unalmas.

Rendben

Szokás szerint haladjunk balról jobbra, fentről lefelé, és írjunk le mindent, amire szükségünk van „egyszerű” ötletünk megvalósításához.

Először is kell egy proxy

És sok alternatíva van egyszerre:

• egyszerűen mehetsz és vehetsz át a nyitott proxylistákból. Olcsó (vagy inkább semmiért), de abszolút megbízhatatlan, és az ilyen proxyk élettartama nullára nyúlik. Ezért kellene keresni/írni egy értelmezőt a proxylistákhoz, szűrni őket a kívánt típus és ország szerint, és nyitva marad a talált proxy helyettesítésének kérdése a Spotify-ban (jó, talán ezen keresztül HTTP_PROXY átvitele és egyéni burkoló létrehozása a binárishoz, hogy az összes többi forgalom ne kerüljön oda).
• Vásárolhat hasonló proxyt, és megkímélheti magát a fent leírt problémák többségétől. De proxy áron azonnal prémiumot vásárolhat a Spotify-on, és ez nem praktikus az eredeti feladathoz.
• Emeld fel a tiédet. Ahogy valószínűleg sejti, ez a mi választásunk.

Pusztán véletlenül kiderülhet, hogy van egy barátod egy szerverrel a Fehérorosz Köztársaságban vagy egy másik kis országban. Ezt kell használnia, és ki kell helyeznie rajta a kívánt proxyt. A különleges ínyencek megelégedhetnek azzal, ha egy barátjuk routerrel rendelkezik DD-WRT vagy hasonló szoftver. De ott övé csodálatos világ és ez a világ nyilvánvalóan nem fér bele ennek a történetnek a keretébe.

Tehát a mi lehetőségeink: Squid - nem inspiráló, és nem akarok HTTP-proxyt, már túl sok van ebből a protokollból. És a SOCKS területén nincs semmi értelmes, kivéve Dante még nem szállították le. Ezért vegyük.

Ne várja meg Dante telepítési és konfigurálási kézikönyvét. Ő csak guglizik és nem különösebben érdekli. A minimális konfigurációban mindenfélét be kell dobnia client pass, socks pass, regisztrálja megfelelően az interfészt, és ne felejtse el hozzáadni socksmethod: username. Ebben a formában a hitelesítéshez a rendszerhasználóktól veszik a logopass-t. És a biztonsággal kapcsolatos rész: a localhosthoz való hozzáférés tiltása, a felhasználók korlátozása stb. - ez tisztán egyéni, a személyes paranoiától függően.

Telepítsen egy proxyt a hálózat felé

A darab két felvonásos.

Cselekedj egyet

Kiválasztottuk a proxyt, most a globális webről kell elérnünk. Ha fehér IP-vel rendelkező gépe van a kívánt országban, akkor ezt a pontot nyugodtan kihagyhatja. Nekünk nincs ilyenünk (mint fentebb említettük, a barátok házában vagyunk otthon), és a legközelebbi fehér IP valahol Németországban van, ezért tanulmányozni fogjuk a hálózatokat.

Tehát igen, a figyelmes olvasó ismét felteszi a kérdést: miért nem vesz egy meglévő szolgáltatást, mint pl ngrok vagy hasonló? És megint igaza lesz. De ez egy szolgáltatás, megint démonizálni kell, pénzbe is kerülhet, és általában nem sportszerű. Ezért ócskavas anyagokból fogunk kerékpárokat készíteni.

Feladat: valahol messze a NAT mögött van egy proxy, rá kell akasztani egy fehér IP-vel rendelkező, a világ szélén található VPS egyik portjára.

Logikus feltételezés, hogy ez megoldható akár port továbbítással (amely a fent említetteken keresztül valósul meg ssh), vagy a hardver virtuális hálózatba való kombinálásával VPN-en keresztül. VAL VEL ssh tudjuk, hogyan kell dolgozni, autossh Unalmas, ezért vegyük az OpenVPN-t.

A DigitalOcean rendelkezik csodálatos manul ebben az ügyben. nincs hozzáfűznivalóm. Az így kapott konfig pedig egészen egyszerűen összekapcsolható az OpenVPN klienssel és systemd. Csak tedd be (config). /etc/openvpn/client/ és ne felejtse el módosítani a kiterjesztést .conf. Ezt követően húzza ki a szolgáltatást [email protected]ne felejtsd el megtenni neki enable és örülj, hogy minden elrepült.

Természetesen le kell tiltanunk a forgalom bármilyen átirányítását az újonnan létrehozott VPN-re, mert nem akarjuk csökkenteni a kliensgép sebességét azzal, hogy fél labdán átadjuk a forgalmat.

És igen, regisztrálnunk kell egy statikus IP-címet a VPN-kiszolgálón ügyfelünk számára. Erre egy kicsit később lesz szükség a történetben. Ehhez engedélyeznie kell ifconfig-pool-persist, szerk ipp.txt, amely tartalmazza az OpenVPN-t, engedélyezze a client-config-dir-t, valamint szerkessze a kívánt kliens konfigurációját a hozzáadással ifconfig-push a megfelelő maszkkal és a kívánt IP-címmel.

Második felvonás

Most van egy gépünk a „hálózaton”, amely az Internet felé néz, és önző célokra használható. Mégpedig a forgalom egy részét átirányítani rajta.

Új feladat tehát: ki kell kapcsolni az egyik fehér IP-vel rendelkező VPS portra érkező forgalmat, hogy ez a forgalom az újonnan csatlakoztatott virtuális hálózatba kerüljön, és onnan vissza tudjon térni a válasz.

Megoldás: természetesen iptables! Mikor lesz még ilyen csodálatos lehetőséged vele gyakorolni?

A szükséges konfigurációt elég gyorsan, három óra alatt, száz szitokszó és egy marék elvesztegetett ideg alatt meg lehet találni, mert a hálózatok hibakeresése nagyon specifikus eljárás.

Először is engedélyeznie kell a forgalom átirányítását a kernelben. Ezt a dolgot úgy hívják ipv4.ip_forward és az operációs rendszertől és a hálózatkezelőtől függően kissé eltérően engedélyezett.

Másodszor, ki kell választania egy portot a VPS-en, és az arra irányuló összes forgalmat virtuális alhálózatba kell csomagolnia. Ez megtehető például a következőképpen:

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

Itt átirányítjuk a külső interfész 8080-as portjára érkező összes TCP-forgalmat egy 10.8.0.2-es IP-című és ugyanazzal a 8080-as porttal rendelkező gépre.

Azoknak, akik a munka piszkos részleteire vágynak netfilter, iptables és általában az útválasztást, feltétlenül szükséges megfontolni ezt vagy ezt.

Tehát most a csomagjaink a virtuális alhálózatba repülnek és... ott is maradnak. Pontosabban a socks proxy válasza visszarepül az alapértelmezett átjárón keresztül a gépen Dantéval, és a címzett eldobja, mert a hálózatokban nem szokás egy IP-re küldeni kérést és a másiktól választ kapni. Ezért tovább kell varázsolnunk.

Tehát most minden csomagot át kell irányítania a proxyról a virtuális alhálózatra a VPS felé fehér IP-címmel. Itt a helyzet egy kicsit rosszabb, mert egyszerűen iptables nem lesz elég, mert ha az útválasztás előtt javítjuk a célcímet (PREROUTING), akkor a csomagunk nem repül az internetre, és ha nem javítjuk, a csomag a címre kerül default gateway. Tehát a következőket kell tennie: emlékezzen a láncra mangle, hogy megjelölje a csomagokat iptables és csomagolja be őket egy egyéni útválasztási táblázatba, amely elküldi őket, ahová menniük kell.

Alig van szó, mint kész:

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

Felvesszük a kimenő forgalmat, megjelölünk mindent, ami arról a portról repül, amelyen a proxy ül (esetünkben 8080), az összes megjelölt forgalmat átirányítjuk a 80-as számú útválasztó táblára (általában a szám nem függ semmitől, csak akartuk to), és adjunk hozzá egyetlen szabályt , amely szerint a táblázatban szereplő összes csomag a VPN-alhálózatra repül.

Nagy! Most a csomagok visszarepülnek a VPS felé... és ott meghalnak. Mert a VPS nem tud velük mit kezdeni. Ezért, ha nem zavarja, egyszerűen átirányíthatja a virtuális alhálózatról érkező összes forgalmat az internetre:

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

Itt minden, ami a 10.8.0.0 alhálózatról érkezik 255.255.255.000 maszkkal, forrás-NAT-ba van csomagolva, és az alapértelmezett interfészre repül, amely az Internet felé fordul. Fontos megjegyezni, hogy ez a dolog csak akkor fog működni, ha transzparensen továbbítjuk a portot, vagyis a VPS bejövő portja megegyezik a proxynk portjával. Ellenkező esetben egy kicsit többet kell szenvednie.

Valahol most mindennek működnie kell. És csak egy kevés maradt: ne felejtsd el megbizonyosodni arról, hogy minden konfigurációt iptables и route az újraindítás után nem folytatódott. Mert iptables vannak speciális fájlok, mint pl /etc/iptables/rules.v4(Ubuntu esetében), de az útvonalaknál minden kicsit bonyolultabb. Belenyomtam őket up/down OpenVPN-szkriptek, bár szerintem tisztességesebben is meg lehetett volna csinálni.

Csomagolja be az alkalmazásból származó forgalmat proxyba

Tehát van egy hitelesítéssel rendelkező proxynk a kívánt országban, amely statikus fehér IP-címen keresztül érhető el. Nem marad más hátra, mint használni, és oda irányítani a forgalmat a Spotify-ból. De van egy árnyalat, amint fentebb említettük, a proxy bejelentkezési jelszava a Spotify-ban nem működik, ezért meg fogjuk keresni, hogyan lehet megkerülni.

Kezdésként emlékezzünk kb meghatalmazott. Remek cucc, de annyiba kerül, mint egy csillaghajó (40 dollár). Ebből a pénzből újra vásárolhatunk prémiumot, és végezhetünk vele. Ezért több ingyenes és nyitott analógot fogunk keresni a Mac-en (igen, zenét akarunk hallgatni a Mac-en). Fedezzünk fel egy egész eszközt: proximac. És boldogan megyünk megbökni őt.

De az öröm rövid életű lesz, mert kiderül, hogy engedélyeznie kell a hibakeresési módot és az egyéni kernelkiterjesztéseket a MacOS-ban, be kell adnia egy egyszerű konfigurációt, és meg kell értenie, hogy ennek az eszköznek pontosan ugyanaz a problémája, mint a Spotify-nak: nem tudja átadni a hitelesítést a bejelentkezési jelszó a socks-proxy-n.

Valahol itt az ideje, hogy kiakadjon, és vegyen egy prémiumot... de nem! Próbáljuk meg kérni a javítását, nyílt forráskódú! Csináljuk jegy. És válaszul kapunk egy szívszorító történetet arról, hogy az egyetlen karbantartónak már nincs MacBookja, és a pokolba is, nem javítás.

Megint idegesek leszünk. De akkor emlékezni fogunk a fiatalságunkra és a C-re, bekapcsoljuk a hibakeresési módot Dante-ban, több száz kilobájt naplót ássunk át, menjünk RFC1927 A SOCKS5 protokollal kapcsolatos információkért nézzük meg az Xcode-ot, és keressük meg a problémát. Elegendő egy karaktert kijavítani azon metóduskódok listáján, amelyeket a kliens felkínál a hitelesítéshez, és minden elkezd működni, mint a karikacsapás. Örülünk, összegyűjtjük a kiadási binárist, megtesszük pull kérés és bemegyünk a naplementébe és megyünk a következő ponthoz.

Automatizáld

Amint a Proximac működik, démonizálni kell, és el kell felejteni. Egy teljes inicializálási rendszer alkalmas erre, ami a MacOS-ban található, mégpedig elindítva.

Gyorsan megtaláljuk kézikönyv és megértjük, hogy ez egyáltalán nem így van systemd és itt szinte egy gombóc és xml. Nincsenek díszes konfigurációk az Ön számára, nincsenek ehhez hasonló parancsok status, restart, daemon-reload. Csak hardcore fajta start-stop, list-grep, unload-load és még sok furcsaság. Mindezt leküzdve írunk plist, Betöltés. Nem működik. Tanulmányozzuk a démon hibakeresésének módszerét, hibakeresést, megértjük, mi van ott ENV még PATH nem adtuk le a normált, vitatkozunk, behozzuk (hozzátéve /sbin и /usr/local/bin) és végül elégedettek vagyunk az automatikus indítással és a stabil működéssel.

Lehel

mi az eredmény? Egy hét kaland, térdelő állatkert a szívnek kedves szolgáltatásokból, és megteszi, amit elvárnak tőle. Egy kis tudás kétes technikai területeken, egy kis nyílt forráskód és mosoly az arcodon a „megcsináltam!” gondolattól!

PS: ez nem a kapitalisták bojkottjára, a meccseken való spórolásra vagy a totális ravaszságra szólít fel, hanem csak a kutatás-fejlesztés lehetőségeinek jelzése, ahol általában nem számítanak rájuk.

Forrás: will.com