Bagaimana Spotify dapat membantu mempelajari setan, RFC, jaringan, dan promosi sumber terbuka. Atau apa yang terjadi jika Anda tidak dapat membayar, dan beberapa roti premium benar-benar menginginkannya.
Mulai
Pada hari ketiga, diketahui bahwa Spotify membagikan iklan berdasarkan negara alamat IP. Juga dicatat di sana bahwa di beberapa negara iklan tidak ditayangkan sama sekali. Misalnya, di Belarus . Dan kemudian rencana "brilian" untuk menonaktifkan iklan di akun non-premium telah matang.
Sedikit tentang Spotify
Secara umum, Spotifay memiliki kebijakan aneh. Saudara kita harus cukup mesum untuk membeli premi: ubah lokasi di profil menjadi yang di luar negeri, cari kartu GIF yang cocok yang hanya dapat dibayar dengan paypal, yang baru-baru ini aneh dan menginginkan banyak dokumen. Secara umum, juga petualangan, tetapi dari urutan yang berbeda. Meskipun sebagian besar ini untuk versi seluler, saya tidak tertarik. Oleh karena itu, semua hal berikut ini hanya akan membantu dalam hal versi desktop. Selain itu, tidak akan ada perluasan fungsi. Hanya memotong sebagian kelebihannya.
Kenapa begitu rumit?
Dan saya pikir begitu, mendaftarkan data kaus kaki-proxy di konfigurasi Spotify. Masalahnya ternyata otentikasi mereka dalam kaus kaki dengan login dan kata sandi tidak berfungsi. Plus, pengembang secara teratur memutar sesuatu di sekitar proxy: baik memungkinkan, melarang atau menghancurkannya, yang menimbulkan seluruh panel diskusi di situs.
Diputuskan untuk tidak bergantung pada fungsi yang tidak stabil dan untuk menemukan sesuatu yang lebih dapat diandalkan dan ingin tahu.
Di suatu tempat di sini pembaca harus bertanya: mengapa tidak mengambil ssh dengan -D dan menangani akhirnya? Dan, secara umum, dia akan benar. Tapi, pertama-tama, masih perlu di-demonisasi dan berteman dengan autossh, agar tidak berpikir untuk memutuskan koneksi. Dan kedua: terlalu sederhana dan membosankan.
Dalam rangka
Seperti biasa, mari kita beralih dari kiri ke kanan, dari atas ke bawah dan menjelaskan semua yang kita butuhkan untuk mengimplementasikan ide "sederhana" kami.
Pertama, Anda perlu proxy
Dan banyak alternatif sekaligus:
- Anda bisa pergi dan mendapatkannya dari proxylists terbuka. Murah (atau lebih tepatnya tanpa biaya), tetapi sama sekali tidak dapat diandalkan dan masa pakai proxy semacam itu cenderung nol. Oleh karena itu, perlu untuk mencari / menulis parser proxy dari daftar, memfilternya berdasarkan jenis dan negara yang diinginkan, dan pertanyaan tentang mengganti proxy yang ditemukan di Spotify tetap terbuka (baik, kecuali, melalui
HTTP_PROXY mentransmisikan dan HTTP_PROXY kustom untuk biner sehingga semua sisa lalu lintas tidak dikirim ke sana) ) - Anda dapat membeli proxy yang sama dan menyelamatkan diri dari sebagian besar masalah yang dijelaskan di atas. Tetapi dengan harga proksi, Anda dapat segera membeli premi di Spotify, dan ini bukan olahraga sebagai bagian dari tugas awal.
- Angkat milikmu. Seperti yang mungkin Anda tebak, ini adalah pilihan kami.
Secara kebetulan, mungkin Anda memiliki teman dengan server di Belarusia atau negara kecil lainnya. Anda perlu menggunakan ini dan meluncurkan proxy yang diinginkan di atasnya. Penikmat khusus dapat puas dengan teman dengan rute ke DD-WRT atau perangkat lunak serupa. Tapi ada dunianya sendiri yang luar biasa dan dunia ini jelas tidak akan cocok dengan kerangka cerita ini.
Jadi, opsi kami: Squid - tidak menginspirasi, dan saya tidak ingin proxy HTTP, protokol ini memiliki terlalu banyak. Dan di bidang SOCKS tidak ada yang masuk akal kecuali Dante telah dikirim. Karena itu, kami ambil.
Manula untuk menginstal dan mengkonfigurasi Dante jangan menunggu. Dia hanya googles dan sedikit minat. Dalam konfigurasi minimum, Anda harus membuang semua jenis client pass , socks pass , mendaftarkan antarmuka dengan benar, dan jangan lupa untuk menambahkan socksmethod: username . Dalam formulir ini, untuk otentikasi, logopus akan diambil dari pengguna sistem. Dan bagian tentang keamanan: larangan akses ke localhost, pembatasan pada pengguna dan sebagainya - ini murni individu, tergantung pada paranoia pribadi.
Kinerja dalam dua babak.
Bertindak satu
Kami menemukan proxy, sekarang kami perlu mengaksesnya dari web global. Jika Anda memiliki mesin dengan IP putih di negara yang tepat, maka Anda dapat melewati item ini dengan aman. Kami tidak memilikinya (kami, seperti yang disebutkan di atas, menjamu teman-teman di rumah) dan IP putih terdekat ada di suatu tempat di Jerman, jadi kami akan mempelajari jaringannya.
Jadi ya, pembaca yang penuh perhatian akan kembali bertanya: mengapa tidak mengambil layanan yang ada seperti ngrok atau sejenisnya? Dan dia akan benar lagi. Tapi ini adalah layanan, sekali lagi perlu di-iblis-iblis, bisa juga membutuhkan biaya dan pada umumnya itu bukan olahraga. Karena itu, kami akan membuat sepeda dari bahan improvisasi.
Tugas: ada proxy di suatu tempat jauh di luar NAT, Anda harus menggantungnya di salah satu port VPS, yang memiliki IP putih dan terletak di ujung dunia.
Adalah logis untuk mengasumsikan bahwa ini diselesaikan baik dengan meneruskan port (yang diimplementasikan melalui ssh disebutkan sebelumnya), atau dengan menggabungkan potongan-potongan besi ke jaringan virtual melalui VPN. Kami tahu cara bekerja dengan ssh , autossh membosankan untuk dilakukan, jadi mari kita ambil OpenVPN.
DigitalOcean memiliki manul yang luar biasa dalam hal ini. Saya tidak punya apa-apa untuk ditambahkan. Dan konfigurasi yang dihasilkan dapat dengan mudah berteman dengan klien OpenVPN dan systemd . Cukup dengan meletakkannya (config) di /etc/openvpn/client/ dan jangan lupa untuk mengubah ekstensi ke .conf . Setelah itu, tarik layanan openvpn-client@openvpn-client-config-name.service , jangan lupa untuk enable untuk itu dan senang bahwa semuanya terbang.
Tentu saja, Anda perlu menonaktifkan pengalihan lalu lintas ke VPN yang baru dibuat, karena kami tidak ingin memotong kecepatan pada mesin klien karena lalu lintas dibanjiri melalui setengah bola.
Dan ya, Anda perlu mendaftarkan alamat ip statis di server VPN untuk klien kami. Ini akan dibutuhkan sedikit lebih jauh dalam narasi. Untuk melakukan ini, aktifkan ifconfig-pool-persist , edit ipp.txt yang datang dengan OpenVPN dan aktifkan client-config-dir, plus edit konfigurasi klien yang diinginkan dengan menambahkan ifconfig-push dengan mask yang benar dan alamat IP yang diinginkan.
Babak Kedua
Sekarang kami memiliki mesin di "jaringan" yang dihadapkan ke Internet dan dapat digunakan untuk keuntungan pribadi. Yakni, redirect bagian dari traffic yang melaluinya.
Jadi, tugas baru: Anda harus menyelesaikan lalu lintas yang tiba di salah satu port VPS dengan IP putih sehingga lalu lintas ini terbang ke jaringan virtual yang baru terhubung dan jawabannya dapat kembali dari sana.
Solusi: tentu saja iptables ! Kapan Anda akan memiliki kesempatan yang luar biasa untuk berlatih dengannya?
Konfigurasi yang diperlukan ditemukan segera, dalam tiga jam, seratus kata sumpah dan segelintir saraf yang dihabiskan, karena jaringan debug adalah prosedur yang sangat spesifik.
Pertama, Anda harus mengaktifkan pengalihan lalu lintas di kernel. Hal ini disebut ipv4.ip_forward dan menyala sedikit berbeda tergantung pada OS dan manajer jaringan.
Kedua, Anda perlu memilih port pada VPS dan membungkus semua lalu lintas yang menuju ke dalam subnet virtual. Ini bisa dilakukan, misalnya, seperti ini:
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8080 -j DNAT --to-destination 10.8.0.2:8080
Di sini kita mengarahkan semua lalu lintas TCP yang datang ke port 8080 dari antarmuka eksternal ke mesin dengan IP 10.8.0.2 dan port 8080 yang sama.
Mereka yang menginginkan detail kotor dari netfilter , iptables dan routing secara umum harus benar-benar merenungkan ini atau itu .
Jadi, sekarang paket kami terbang ke subnet virtual dan ... mereka tetap di sana. Lebih tepatnya, respons dari proksi kaus kaki terbang kembali melalui gateway default pada mesin Dante dan penerima menjatuhkannya, karena dalam jaringan itu tidak diterima untuk mengirim permintaan ke satu IP, tetapi untuk menerima tanggapan dari yang lain. Karena itu, Anda perlu menyulap lebih jauh.
Jadi, sekarang Anda perlu mengarahkan semua paket dari proxy kembali ke subnet virtual menuju VPS dengan IP putih. Di sini situasinya sedikit lebih buruk, karena iptables tidak akan cukup bagi kita, karena jika kita memperbaiki alamat tujuan sebelum routing ( PREROUTING ), maka paket kita tidak akan terbang ke Internet, dan jika kita tidak memperbaikinya, paket tersebut akan pergi ke default gateway . Jadi, Anda perlu melakukan hal berikut: ingat rantai mangle untuk menandai paket melalui iptables dan membungkusnya dalam tabel routing kustom yang akan mengirim mereka ke tempat yang seharusnya.
Tidak lebih cepat dikatakan daripada dilakukan:
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
Kami mengambil lalu lintas keluar, tandai semua yang terbang dari port tempat proxy duduk (8080 dalam kasus kami), mengalihkan semua lalu lintas yang ditandai ke tabel perutean dengan nomor 80 (secara umum, jumlahnya tidak tergantung pada apa pun, saya hanya ingin) dan menambahkan satu-satunya aturan , dimana semua paket yang termasuk dalam tabel ini terbang ke subnet VPN.
Hebat! Sekarang paket terbang kembali ke VPS ... dan mati di sana. Karena VPS tidak tahu apa yang harus dilakukan dengan mereka. Karenanya, jika Anda tidak repot, Anda dapat mengambil dan mengarahkan semua lalu lintas yang datang dari subnet virtual kembali ke Internet:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 172.42.1.10
Di sini, segala sesuatu yang datang dari subnet 10.8.0.0 dengan topeng 255.255.255.000 dibungkus dalam source-NAT dan terbang ke antarmuka default, yang dialihkan ke Internet. Penting untuk dicatat bahwa hal ini hanya akan berfungsi jika kita meneruskan port secara transparan, yaitu port yang masuk pada VPS cocok dengan port dari proxy kami. Jika tidak, Anda perlu menderita sedikit lebih banyak.
Di suatu tempat sekarang semuanya harus mulai bekerja. Dan hanya sedikit yang tersisa: jangan lupa untuk memastikan bahwa semua iptables dan konfigurasi route tidak dilanjutkan setelah restart. Untuk iptables ada file khusus seperti /etc/iptables/rules.v4 (untuk Ubuntu), dan untuk rute semuanya menjadi sedikit lebih rumit. Saya mendorong mereka ke skrip OpenVPN yang up/down , meskipun, saya pikir, itu bisa dilakukan dengan lebih sopan.
Bungkus lalu lintas dari aplikasi ke proksi
Jadi, kami memiliki proxy dengan otentikasi di negara yang tepat, dapat diakses oleh alamat IP putih statis. Tetap menggunakannya dan mengarahkan lalu lintas dari Spotify di sana. Tetapi ada nuansa, seperti yang disebutkan di atas, kata sandi masuk untuk proxy di Spotifaya tidak berfungsi, jadi kami akan mencari cara menghindar.
Sebagai permulaan, ingat proxifier . Hebatnya, harganya hanya seperti kapal luar angkasa ($ 40). Kita dapat membeli premi untuk uang dan menyelesaikannya. Oleh karena itu, kami mencari analog yang lebih bebas dan terbuka di poppy (ya, kami ingin mendengarkan musik di poppy). Kami menemukan satu alat lengkap: proximac . Dan dengan gembira mari kita menyodoknya.
Tetapi sukacita tidak akan lama, karena ternyata Anda perlu mengaktifkan mode debug dan ekstensi kernel khusus di MacOS, mengajukan konfigurasi sederhana dan memahami bahwa alat ini memiliki masalah yang persis sama dengan Spotify: alat ini tidak dapat mengautentikasi dengan kata sandi masuk pada kaus kaki-proxy.
Di suatu tempat di sini saatnya untuk panik dan masih membeli premi ... tapi tidak! Mari kita coba untuk memperbaikinya, open source! Kami membuat tiket . Dan sebagai tanggapan, kami mendapatkan kisah yang menyayat hati bahwa satu-satunya pengelola tidak lagi memiliki macbook dan bermain-main dengan Anda, dan bukan perbaikan.
Marah lagi. Tapi kemudian kita ingat pemuda dan C, nyalakan mode debug di Dante, menyelidiki seratus kilobyte log, pergi ke RFC1927 untuk informasi tentang protokol SOCKS5, cari tahu dengan Xcode dan masih menemukan masalah. Cukup untuk memperbaiki satu karakter dalam daftar kode metode yang ditawarkan klien untuk otentikasi dan semuanya mulai berfungsi seperti jam. Kami bersukacita, mengumpulkan binary rilis, melakukan permintaan pool dan pergi ke matahari terbenam Kami pergi ke titik berikutnya.
Otomatiskan itu
Setelah Proximac berhasil, Anda harus menjelekkannya dan melupakannya. Untuk ini, sistem inisialisasi satu keseluruhan cocok, yang ada di MacOS, yaitu launchd .
Kami dengan cepat menemukan manual dan memahami bahwa ini sama sekali bukan systemd , dan di sini hampir merupakan scoop dan xml . Tidak ada konfigurasi cantik untuk Anda, tidak ada perintah seperti status , restart , daemon-reload . Hanya hardcore dari bentuk start-stop , list-grep , unload-load dan banyak lagi keanehan. Mengatasi semua ini kami menulis daftar, muat. Tidak bekerja Kami mempelajari metode debugging daemon, debazhim, kami memahami bahwa bahkan PATH tidak mengimpor yang normal di sana, bersumpah, mengimpor (menambahkan /sbin dan /usr/local/bin ) dan akhirnya menikmati operasi mulai otomatis dan stabil.
Buang napas
Apa hasilnya? Seminggu petualangan, kebun binatang setinggi lutut dari layanan yang menyayangi jantung dan melakukan apa yang diminta. Sedikit pengetahuan di bidang teknis yang meragukan, setetes sumber terbuka dan senyum di wajahnya dari pemikiran "Aku berhasil!"
PS: ini bukan seruan boikot terhadap para kapitalis, untuk penghematan dalam pertandingan atau untuk kelicikan total, tetapi hanya sebuah indikasi kemungkinan penelitian dan pengembangan di mana, secara umum, Anda tidak mengharapkannya.