Penjaga Penyalahgunaan Relay Buta
Batasan yang diterapkan node AeroNyx sebelum meneruskan lalu lintas relay terenkripsi: batas laju dan karantina lompatan sebelumnya, penekanan replay rute yang aman terhadap restart, percobaan ulang terbatas, dan penerimaan CPU, hanya dengan menggunakan metadata bertanda tangan dan penghitung agregat.
Penjaga Penyalahgunaan Relay Buta adalah sekumpulan batasan yang diterapkan node AeroNyx sebelum meneruskan lalu lintas relay terenkripsi untuk node lain. Penjaga ini membendung peer yang menyalahgunakan atau tidak stabil hanya dengan menggunakan metadata perutean bertanda tangan dan penghitung lokal. Penjaga ini tidak pernah mengurai ciphertext, menyimpan riwayat rute, atau mengungkap siapa berbicara dengan siapa.
Cakupan
| Kontrol | Keadaan |
|---|---|
| Penerusan payload buram | Sudah diimplementasikan |
| Pemeriksaan kesegaran bertanda tangan dan penekanan replay rute | Sudah diimplementasikan. Status replay aman terhadap restart saat penyimpanan relay chat node diaktifkan |
| Pembatasan laju dan karantina lompatan sebelumnya | Sudah diimplementasikan |
| Batas penerimaan permintaan dan kripto di seluruh proses | Sudah diimplementasikan |
| Bukti runtime agregat di kesehatan node dan Nodeboard | Sudah diimplementasikan |
| Inspeksi teks biasa atau payload | Tidak dilakukan, sesuai desain |
| Analitik per pengguna, per rute, atau graf sosial | Tidak dilakukan, sesuai desain |
Aturan node buta
Relay boleh mengautentikasi metadata perutean, menerapkan kebijakan yang terbatas, meneruskan amplop buram, dan mengembalikan tanda terima bertanda tangan. Relay tidak boleh sekali pun menginspeksi payload atau mengungkap metadata yang dapat merekonstruksi rute, identitas pengguna, atau hubungan. Secara khusus, relay tidak mencatat atau mengungkap:
- teks biasa pesan, paket, media, atau memori
- kueri DNS, tujuan, domain, URL, atau riwayat penjelajahan
- ID rute, jalur lengkap, URL endpoint, atau alamat IP klien
- kunci publik lengkap, identitas penerima, ID pesan, atau sisi graf sosial
- kunci privat, rahasia voucher, lalu lintas tingkat dompet, atau materi dekripsi
Alur penerimaan
Setiap permintaan melewati pemeriksaan berikut sebelum dapat menggunakan kapasitas penerusan. Langkah 1 hingga 6 berjalan dalam urutan ini. Pada langkah 7, permintaan yang ditujukan ke node ini masuk ke penanganan terminal atau onion miliknya sendiri, sedangkan permintaan untuk node lain dicadangkan setelah lompatan berikutnya diresolusi.
1. request gate: process-wide admission window and in-flight limit (64 requests)
2. crypto admission: a free slot for signature and onion work, or Backpressure
3. authenticate the signed previous hop and envelope
4. previous-hop rate limit and quarantine check
5. envelope metadata: size, age and future-skew limits
6. self-loop check
7. route loop, TTL and next-hop descriptor checks, plus the route replay reservation
8. forward the opaque ciphertext, or peel the terminal layer and deliver
Setiap keputusan menggunakan metadata perutean bertanda tangan dan status agregat lokal, tidak pernah konten yang didekripsi.
Batas runtime
Berikut adalah nilai default saat ini di kode sumber node. Nilai-nilai ini adalah nilai operasional, bukan janji protokol yang permanen.
| Konstanta | Default |
|---|---|
BLIND_RELAY_ROUTE_REPLAY_CAPACITY | 8192 rute aktif |
BLIND_RELAY_ROUTE_REPLAY_TTL_SECS | 600 detik |
PREVIOUS_HOP_RATE_LIMIT per PREVIOUS_HOP_RATE_WINDOW_SECS | 120 permintaan per 60 detik |
PREVIOUS_HOP_FAILURE_THRESHOLD per PREVIOUS_HOP_FAILURE_WINDOW_SECS | 12 kegagalan terskor per 300 detik |
PREVIOUS_HOP_QUARANTINE_SECS | 300 detik |
MAX_PREVIOUS_HOP_BUCKETS | 4096 bucket |
BLIND_RELAY_MAX_ENVELOPE_AGE_SECS | 600 detik |
BLIND_RELAY_MAX_FUTURE_SKEW_SECS | 120 detik |
BLIND_RELAY_DELIVERY_RECEIPT_MAX_AGE_SECS | 120 detik |
DEFAULT_MAX_ATTEMPTS (percobaan ulang penerusan) | 3 percobaan |
MAX_IN_FLIGHT_BLIND_RELAY_REQUESTS | 64 permintaan |
Pembatasan laju dan karantina lompatan sebelumnya
Batas laju dikunci berdasarkan identitas bertanda tangan dari lompatan sebelumnya. Lebih dari 120 permintaan dari satu lompatan sebelumnya dalam 60 detik memulai karantina lokal selama lima menit untuk lompatan tersebut. Skor kegagalan yang terpisah memulai karantina yang sama setelah 12 kegagalan terskor dalam lima menit. Hanya alasan berikut yang dihitung dalam skor:
invalid_previous_hop | invalid_signature | self_loop | route_loop | ttl_exhausted
Batas waktu transport, pengakuan (acknowledgement) yang hilang, percobaan ulang duplikat, dan konflik replay tidak menambah skor, sehingga peer yang sehat tidak dikarantina karena gangguan jaringan. Penyimpanan bucket dibatasi, dan bucket yang menganggur dikeluarkan, sehingga penjaga ini tidak dapat tumbuh menjadi graf komunikasi jangka panjang.
Replay rute dan percobaan ulang
Setiap permintaan relay membawa ID rute. Saat penyimpanan relay chat node diaktifkan ([memchain.chat_relay] enabled = true), reservasi rute dan respons yang telah selesai disimpan di basis data SQLite-nya, sehingga perlindungan replay tetap bertahan setelah restart. Jika tidak, node menggunakan registri dalam memori dengan kapasitas dan jendela yang sama. Jika seluruh 8192 slot berisi rute aktif, rute baru ditolak dengan replay_capacity hingga slot kedaluwarsa.
ID rute yang berulang memiliki salah satu dari empat hasil:
| Situasi | Respons | Dampak pada lompatan sebelumnya |
|---|---|---|
| Permintaan sama; percobaan pertama telah selesai | Respons yang tersimpan diputar ulang, termasuk tanda terima bertanda tangan terminal jika ada. Tidak ada yang dikirimkan atau diteruskan untuk kedua kalinya (duplicate_route) | Dihitung sebagai keberhasilan |
| Permintaan sama; percobaan pertama masih berjalan | HTTP 503 route_in_flight. Pengirim boleh mencoba ulang | Tidak ada |
| Permintaan berbeda dengan ID rute yang sama | HTTP 400 replay_conflict | Dicatat dalam kesehatan peer. Tidak menambah skor karantina |
| Permintaan sama, tetapi respons yang tersimpan berumur lebih dari 120 detik | HTTP 409 replay_response_expired. Rute tetap dicadangkan selama sisa jendela 600 detiknya, sehingga tidak dapat dijalankan lagi | Tidak ada |
Hasil terakhir berlaku untuk penyimpanan yang tahan lama. Tanda terima bertanda tangan hanya sah sebagai bukti yang segar, sehingga node tidak memutar ulang tanda terima setelah 120 detik.
Saat penerusan ke lompatan berikutnya gagal karena batas waktu, kesalahan koneksi, atau kesalahan permintaan, node mencoba ulang hingga total tiga percobaan. Jeda singkat sebelum setiap percobaan ulang diturunkan dari ID rute, lompatan berikutnya, dan nomor percobaan. Kegagalan yang dilaporkan node hilir sebagai penolakan pasti tidak dicoba ulang.
Penerimaan kripto (catatan kapasitas operator)
Pemeriksaan tanda tangan, pelepasan lapisan onion, dan penandatanganan tanda terima bergantung pada CPU, sehingga setiap proses node membatasinya:
- Total slot: setengah dari jumlah thread CPU yang dilaporkan host, dibulatkan ke atas, minimal 4 dan maksimal 8, sehingga host dengan satu atau dua thread pun mendapat 4 slot.
- Permintaan masuk: satu slot lebih sedikit dari total, sehingga pembuatan rute keluar dan penyelesaian tanda terima selalu dapat berjalan. Dengan demikian, pada host terkecil permintaan masuk mendapatkan 3 slot.
- Saat semua slot sibuk: permintaan langsung ditolak dengan HTTP 429 dan alasan
backpressure. Permintaan tidak menunggu dalam antrean.
Karena itu, pada host kecil, relay melepaskan beban lebih awal saat terjadi lonjakan. Penghitung backpressure_dropped yang terus naik berarti node memerlukan lebih banyak CPU atau lebih sedikit lalu lintas relay.
Penghitung runtime agregat
Node melaporkan penghitung kumulatif kasar dan stempel waktu kesegaran dalam heartbeat mereka di bawah:
system_stats.discovery_status.peer_store.runtime.blind_relay
system_stats.discovery_status.peer_store.blind_relay_quality
system_stats.discovery_status.peer_store.peer_health_summary
| Grup penghitung | Kolom |
|---|---|
| Penerimaan dan disposisi | received, terminal, forwarded, rejected |
| Validasi dan perlindungan | invalid_signature, envelope_too_large, ttl_exhausted, no_route, invalid_endpoint, loop_detected, replay_dropped, timestamp_rejected, rate_limited, quarantined, quarantine_started |
| Transport dan percobaan ulang | backpressure_dropped, forward_failed, retry_attempted, retry_succeeded, retry_exhausted |
| Probe sintetis | probe_attempted, probe_succeeded, probe_failed, two_hop_probe_attempted, two_hop_probe_succeeded, two_hop_probe_failed |
| Pengiriman nyata dan kesegaran | verified_client_onion_deliveries, last_verified_client_onion_delivery_at, last_accepted_at, last_event_at |
Penghitung ini menggambarkan operasi node. Penghitung ini bukan log pesan atau data penagihan, dan tidak membuktikan bahwa percakapan tertentu pernah terjadi.
Kualitas bukti
Ringkasan kualitas memisahkan empat jenis bukti: pekerjaan relay buram yang diterima, probe keterjangkauan sintetis, probe dua lompatan sintetis, dan tanda terima bertanda tangan terminal untuk pengiriman yang berasal dari klien. real_relay_ready memerlukan tanda terima pengiriman klien yang segar dan terautentikasi. Bukti sintetis tidak pernah dilaporkan sebagai lalu lintas pengguna.
status | Arti |
|---|---|
idle | Belum ada aktivitas relay atau probe |
observing | Sudah ada sebagian bukti, tetapi kesiapan belum ditetapkan |
stale | Bukti keberhasilan sebelumnya sudah tidak segar lagi |
ready | Pekerjaan yang diterima atau bukti yang memenuhi syarat masih segar, tanpa masalah transport yang aktif |
protecting | Perlindungan penyalahgunaan telah terpicu sementara relay tetap bekerja |
degraded | Kegagalan penerusan atau probe perlu diselidiki |
attention | Backpressure atau percobaan ulang yang habis memerlukan perhatian segera dari operator |
proof_scope menyebut bukti terkuat yang terlihat: client_message_delivery, relay_acceptance, message_delivery, control_plane, single_hop_control_plane, attempted, atau none.
Kesehatan peer tanpa hubungan lalu lintas
peer_health_summary memungkinkan operator menemukan peer yang gagal atau dikarantina tanpa melihat siapa berkomunikasi dengan siapa.
Disertakan: awalan ID node yang dipersingkat, kesehatan dan status deskriptor secara kasar, kesegaran gossip dan keberhasilan rute, jumlah agregat keberhasilan dan kegagalan rute, status karantina, sisa waktu, dan kelompok alasan secara kasar.
Tidak pernah disertakan: kunci publik node lengkap, ID rute, daftar endpoint, blob terenkripsi atau hash payload, ID pesan, identitas penerima, alamat IP klien, tujuan, data DNS, atau sisi graf sosial.
Peta sumber
| Lapisan | Jalur di repositori node | Peran |
|---|---|---|
| Orkestrasi relay | crates/aeronyx-server/src/api/chat_peer/blind_relay.rs | Gerbang permintaan, penerimaan kripto, autentikasi, pemeriksaan loop dan TTL, hasil replay, penerusan, dan penanganan terminal |
| Permukaan HTTP dan batas | crates/aeronyx-server/src/api/chat_peer.rs | Rute, batas body dan permintaan yang sedang berjalan, kode kesalahan, dan kelompok alasan |
| Kebijakan penyalahgunaan | crates/aeronyx-server/src/api/chat_peer_abuse_guard.rs | Batas laju lompatan sebelumnya, skor kegagalan, dan karantina |
| Registri replay | crates/aeronyx-server/src/api/chat_peer_replay.rs | Registri dalam memori dan format respons yang tersimpan |
| Penyimpanan replay tahan lama | crates/aeronyx-server/src/services/chat_relay_blind_route_store.rs | Reservasi rute dan respons di SQLite |
| Kebijakan percobaan ulang | crates/aeronyx-server/src/api/chat_peer_retry.rs | Kegagalan yang dapat dicoba ulang versus kegagalan pasti, serta waktu percobaan ulang |
| Penghitung dan kualitas | crates/aeronyx-server/src/services/peer_store.rs dan services/peer_store/status.rs | Penghitung agregat, kesiapan, dan klasifikasi bukti |
| Pelaporan kesehatan | crates/aeronyx-server/src/api/vpn_health.rs dan management/reporter.rs | JSON kesehatan lokal dan payload heartbeat |
Perangkat lunak node bersumber terbuka di bawah AGPL-3.0 di github.com/AeroNyxNetwork/AeroNyx. Lihat Penemuan node dan relay multi-lompatan terenkripsi untuk cara rute dibangun.
<!-- faq:start -->Pertanyaan yang sering diajukan
Dapatkah node relay membaca atau mencatat lalu lintas yang diteruskannya?
Tidak. Relay memeriksa metadata perutean bertanda tangan dan meneruskan amplop buram. Relay hanya menyimpan penghitung agregat, tidak pernah payload, riwayat rute, atau identitas penerima.
Apa yang terjadi saat node mencoba ulang rute yang sama?
Jika percobaan pertama telah selesai, node memutar ulang respons yang tersimpan dan tidak mengirimkan apa pun untuk kedua kalinya. Jika percobaan pertama masih berjalan, node mengembalikan route_in_flight yang dapat dicoba ulang. Permintaan berbeda dengan ID rute yang sama ditolak sebagai replay_conflict.
Apakah perlindungan replay tetap bertahan setelah node dimulai ulang?
Ya, saat penyimpanan relay chat node diaktifkan. Reservasi rute dan respons yang telah selesai kemudian disimpan di SQLite. Tanpa penyimpanan tersebut, node menggunakan registri dalam memori yang dikosongkan saat restart.
Mengapa sebuah peer dikarantina?
Peer dikarantina selama lima menit setelah mengirim lebih dari 120 permintaan dalam 60 detik, atau setelah 12 kegagalan validasi terskor dalam lima menit. Batas waktu, pengakuan yang hilang, dan percobaan ulang duplikat tidak dihitung sebagai kegagalan.
Mengapa node saya mengembalikan backpressure saat beban tinggi?
Semua slot kripto relay-nya sedang sibuk. Node mengizinkan sekitar setengah dari thread CPU-nya (minimal 4, maksimal 8) untuk pekerjaan tanda tangan dan onion, dan langsung menolak permintaan berlebih alih-alih mengantrekannya.
<!-- faq:end -->