Cơ chế chống lạm dụng cho trạm chuyển tiếp mù
Các giới hạn mà một nút AeroNyx áp dụng trước khi chuyển tiếp lưu lượng chuyển tiếp đã mã hóa: giới hạn tốc độ và cách ly theo chặng trước, chặn phát lại tuyến an toàn qua khởi động lại, thử lại có giới hạn và tiếp nhận theo CPU, chỉ sử dụng siêu dữ liệu có chữ ký và bộ đếm tổng hợp.
Cơ chế chống lạm dụng cho trạm chuyển tiếp mù là tập hợp các giới hạn mà một nút AeroNyx áp dụng trước khi chuyển tiếp lưu lượng chuyển tiếp đã mã hóa cho một nút khác. Cơ chế này kiềm chế các nút ngang hàng lạm dụng hoặc không ổn định chỉ bằng siêu dữ liệu định tuyến có chữ ký và các bộ đếm cục bộ. Cơ chế này không bao giờ phân tích bản mã, lưu lịch sử tuyến hay để lộ ai trò chuyện với ai.
Phạm vi
| Biện pháp kiểm soát | Trạng thái |
|---|---|
| Chuyển tiếp dữ liệu không minh bạch | Đã triển khai |
| Kiểm tra độ mới có chữ ký và chặn phát lại tuyến | Đã triển khai. Trạng thái chống phát lại được giữ an toàn qua khởi động lại khi kho chuyển tiếp trò chuyện của nút được bật |
| Giới hạn tốc độ và cách ly theo chặng trước | Đã triển khai |
| Giới hạn tiếp nhận yêu cầu và tác vụ mật mã trên toàn tiến trình | Đã triển khai |
| Bằng chứng thời gian chạy tổng hợp trong tình trạng nút và Nodeboard | Đã triển khai |
| Kiểm tra văn bản rõ hoặc dữ liệu | Không thực hiện, theo thiết kế |
| Phân tích theo người dùng, theo tuyến hoặc theo đồ thị xã hội | Không thực hiện, theo thiết kế |
Quy tắc nút mù
Một trạm chuyển tiếp có thể xác thực siêu dữ liệu định tuyến, áp dụng chính sách có giới hạn, chuyển tiếp một phong bì không minh bạch và trả về một biên nhận có chữ ký. Trạm chuyển tiếp không bao giờ được kiểm tra dữ liệu hay để lộ siêu dữ liệu có thể giúp tái dựng một tuyến, một danh tính người dùng hay một mối quan hệ. Cụ thể, các trạm chuyển tiếp không ghi lại hay để lộ:
- văn bản rõ của tin nhắn, gói tin, phương tiện hoặc bộ nhớ
- truy vấn DNS, đích đến, tên miền, URL hoặc lịch sử duyệt web
- ID tuyến, đường đi đầy đủ, URL điểm cuối hoặc địa chỉ IP máy khách
- khóa công khai đầy đủ, danh tính người nhận, ID tin nhắn hoặc các cạnh của đồ thị xã hội
- khóa riêng, bí mật của phiếu truy cập, lưu lượng ở cấp ví hoặc tài liệu giải mã
Quy trình tiếp nhận
Mỗi yêu cầu phải vượt qua các bước kiểm tra sau trước khi có thể sử dụng dung lượng chuyển tiếp. Các bước từ 1 đến 6 chạy theo thứ tự này. Ở bước 7, một yêu cầu gửi tới chính nút này được chuyển sang khâu xử lý đích hoặc xử lý onion của nút, còn một yêu cầu dành cho nút khác được giữ chỗ sau khi chặng kế tiếp của nó được xác định.
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
Mọi quyết định đều sử dụng siêu dữ liệu định tuyến có chữ ký và trạng thái tổng hợp cục bộ, không bao giờ sử dụng nội dung đã giải mã.
Giới hạn thời gian chạy
Đây là các giá trị mặc định hiện tại trong mã nguồn nút. Chúng là các giá trị vận hành, không phải cam kết giao thức vĩnh viễn.
| Hằng số | Mặc định |
|---|---|
BLIND_RELAY_ROUTE_REPLAY_CAPACITY | 8192 tuyến đang hoạt động |
BLIND_RELAY_ROUTE_REPLAY_TTL_SECS | 600 giây |
PREVIOUS_HOP_RATE_LIMIT mỗi PREVIOUS_HOP_RATE_WINDOW_SECS | 120 yêu cầu mỗi 60 giây |
PREVIOUS_HOP_FAILURE_THRESHOLD mỗi PREVIOUS_HOP_FAILURE_WINDOW_SECS | 12 lỗi được tính điểm mỗi 300 giây |
PREVIOUS_HOP_QUARANTINE_SECS | 300 giây |
MAX_PREVIOUS_HOP_BUCKETS | 4096 bucket |
BLIND_RELAY_MAX_ENVELOPE_AGE_SECS | 600 giây |
BLIND_RELAY_MAX_FUTURE_SKEW_SECS | 120 giây |
BLIND_RELAY_DELIVERY_RECEIPT_MAX_AGE_SECS | 120 giây |
DEFAULT_MAX_ATTEMPTS (số lần thử lại khi chuyển tiếp) | 3 lần thử |
MAX_IN_FLIGHT_BLIND_RELAY_REQUESTS | 64 yêu cầu |
Giới hạn tốc độ và cách ly theo chặng trước
Giới hạn tốc độ được tính theo danh tính có chữ ký của chặng trước. Hơn 120 yêu cầu từ một chặng trước trong vòng 60 giây sẽ kích hoạt cách ly cục bộ năm phút đối với chặng đó. Một điểm lỗi riêng biệt kích hoạt cùng mức cách ly đó sau 12 lỗi được tính điểm trong vòng năm phút. Chỉ những lý do sau được tính vào điểm:
invalid_previous_hop | invalid_signature | self_loop | route_loop | ttl_exhausted
Hết thời gian chờ ở tầng truyền tải, mất xác nhận, thử lại trùng lặp và xung đột phát lại không được cộng vào điểm, vì vậy một nút ngang hàng khỏe mạnh không bị cách ly vì sự cố mạng. Kho bucket có giới hạn, và các bucket nhàn rỗi bị loại bỏ, vì vậy cơ chế bảo vệ không thể phình thành một đồ thị liên lạc dài hạn.
Phát lại tuyến và thử lại
Mỗi yêu cầu chuyển tiếp mang một ID tuyến. Khi kho chuyển tiếp trò chuyện của nút được bật ([memchain.chat_relay] enabled = true), các lượt giữ chỗ tuyến và các phản hồi đã hoàn tất được lưu trong cơ sở dữ liệu SQLite của nó, vì vậy cơ chế chống phát lại vẫn còn hiệu lực sau khi khởi động lại. Nếu không, nút sử dụng một sổ đăng ký trong bộ nhớ với cùng dung lượng và cửa sổ thời gian. Nếu cả 8192 vị trí đều đang giữ tuyến hoạt động, các tuyến mới bị từ chối với replay_capacity cho đến khi các vị trí hết hạn.
Một ID tuyến lặp lại có một trong bốn kết quả:
| Tình huống | Phản hồi | Ảnh hưởng đối với chặng trước |
|---|---|---|
| Cùng một yêu cầu; lần thử đầu tiên đã hoàn tất | Phản hồi đã lưu được phát lại, bao gồm mọi biên nhận do nút đích ký. Không có gì được phân phối hay chuyển tiếp lần thứ hai (duplicate_route) | Được tính là thành công |
| Cùng một yêu cầu; lần thử đầu tiên vẫn đang chạy | HTTP 503 route_in_flight. Bên gửi có thể thử lại | Không có |
| Yêu cầu khác nhưng dùng cùng ID tuyến | HTTP 400 replay_conflict | Được ghi vào tình trạng nút ngang hàng. Không cộng vào điểm cách ly |
| Cùng một yêu cầu, nhưng phản hồi đã lưu cũ hơn 120 giây | HTTP 409 replay_response_expired. Tuyến vẫn được giữ chỗ trong phần còn lại của cửa sổ 600 giây, vì vậy nó không thể chạy lại | Không có |
Kết quả cuối cùng áp dụng cho kho lưu trữ bền vững. Biên nhận có chữ ký chỉ hợp lệ khi là bằng chứng còn mới, vì vậy nút không phát lại biên nhận sau 120 giây.
Khi việc chuyển tiếp tới chặng kế tiếp thất bại do hết thời gian chờ, lỗi kết nối hoặc lỗi yêu cầu, nút thử lại tối đa tổng cộng ba lần thử. Khoảng trễ ngắn trước mỗi lần thử lại được dẫn xuất từ ID tuyến, chặng kế tiếp và số thứ tự lần thử. Các lỗi mà nút phía sau báo là từ chối dứt khoát sẽ không được thử lại.
Tiếp nhận tác vụ mật mã (ghi chú về dung lượng cho nhà vận hành)
Kiểm tra chữ ký, gỡ lớp onion và ký biên nhận là các tác vụ bị giới hạn bởi CPU, vì vậy mỗi tiến trình nút giới hạn chúng:
- Tổng số vị trí: một nửa số luồng CPU mà máy chủ báo cáo, làm tròn lên, tối thiểu 4 và tối đa 8, nên ngay cả máy chủ chỉ có một hoặc hai luồng cũng có 4 vị trí.
- Yêu cầu đến: ít hơn tổng số một vị trí, để việc tạo tuyến đi và hoàn tất biên nhận luôn có thể tiến triển. Vì vậy, trên những máy chủ nhỏ nhất, các yêu cầu đến có 3 vị trí.
- Khi tất cả các vị trí đều bận: yêu cầu bị từ chối ngay lập tức với HTTP 429 và lý do
backpressure. Yêu cầu không chờ trong hàng đợi.
Do đó, trên một máy chủ nhỏ, trạm chuyển tiếp sẽ sớm giảm tải khi có đột biến lưu lượng. Bộ đếm backpressure_dropped tăng lên có nghĩa là nút cần thêm CPU hoặc ít lưu lượng chuyển tiếp hơn.
Các bộ đếm thời gian chạy tổng hợp
Các nút báo cáo các bộ đếm tích lũy ở mức thô và dấu thời gian độ mới trong heartbeat của chúng dưới:
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
| Nhóm bộ đếm | Trường |
|---|---|
| Tiếp nhận và xử lý | received, terminal, forwarded, rejected |
| Xác thực và bảo vệ | invalid_signature, envelope_too_large, ttl_exhausted, no_route, invalid_endpoint, loop_detected, replay_dropped, timestamp_rejected, rate_limited, quarantined, quarantine_started |
| Truyền tải và thử lại | backpressure_dropped, forward_failed, retry_attempted, retry_succeeded, retry_exhausted |
| Thăm dò tổng hợp | probe_attempted, probe_succeeded, probe_failed, two_hop_probe_attempted, two_hop_probe_succeeded, two_hop_probe_failed |
| Phân phối thực và độ mới | verified_client_onion_deliveries, last_verified_client_onion_delivery_at, last_accepted_at, last_event_at |
Các bộ đếm này mô tả hoạt động của nút. Chúng không phải là nhật ký tin nhắn hay dữ liệu tính phí, và chúng không chứng minh rằng bất kỳ cuộc hội thoại cụ thể nào đã diễn ra.
Chất lượng bằng chứng
Bản tóm tắt chất lượng giữ tách biệt bốn loại bằng chứng: công việc chuyển tiếp không minh bạch đã được chấp nhận, các thăm dò khả năng tiếp cận tổng hợp, các thăm dò hai chặng tổng hợp, và các biên nhận do nút đích ký cho các lượt phân phối bắt nguồn từ máy khách. real_relay_ready yêu cầu một biên nhận phân phối máy khách còn mới và đã được xác thực. Bằng chứng tổng hợp không bao giờ được báo cáo là lưu lượng người dùng.
status | Ý nghĩa |
|---|---|
idle | Chưa có hoạt động chuyển tiếp hay thăm dò nào |
observing | Đã có một số bằng chứng, nhưng chưa xác lập được trạng thái sẵn sàng |
stale | Bằng chứng thành công trước đó không còn mới |
ready | Có công việc được chấp nhận còn mới hoặc một bằng chứng đủ điều kiện, không có sự cố truyền tải đang diễn ra |
protecting | Các biện pháp chống lạm dụng đã được kích hoạt trong khi trạm chuyển tiếp vẫn tiếp tục hoạt động |
degraded | Các lỗi chuyển tiếp hoặc thăm dò cần được điều tra |
attention | Tình trạng quá tải hoặc thử lại đã cạn cần nhà vận hành chú ý kịp thời |
proof_scope nêu tên bằng chứng mạnh nhất đã thấy: client_message_delivery, relay_acceptance, message_delivery, control_plane, single_hop_control_plane, attempted hoặc none.
Tình trạng nút ngang hàng mà không có quan hệ lưu lượng
peer_health_summary cho phép nhà vận hành tìm ra một nút ngang hàng đang lỗi hoặc bị cách ly mà không thấy ai liên lạc với ai.
Bao gồm: tiền tố ID nút được rút gọn, tình trạng và trạng thái bộ mô tả ở mức thô, độ mới của lan truyền và của tuyến thành công, số lượng tuyến thành công và thất bại tổng hợp, trạng thái cách ly, thời gian còn lại và các nhóm lý do ở mức thô.
Không bao giờ bao gồm: khóa công khai đầy đủ của nút, ID tuyến, danh sách điểm cuối, khối dữ liệu mã hóa hoặc giá trị băm của dữ liệu, ID tin nhắn, danh tính người nhận, địa chỉ IP máy khách, đích đến, dữ liệu DNS hay các cạnh của đồ thị xã hội.
Sơ đồ mã nguồn
| Tầng | Đường dẫn trong kho mã nút | Vai trò |
|---|---|---|
| Điều phối chuyển tiếp | crates/aeronyx-server/src/api/chat_peer/blind_relay.rs | Cổng yêu cầu, tiếp nhận tác vụ mật mã, xác thực, kiểm tra vòng lặp và TTL, kết quả phát lại, chuyển tiếp và xử lý đích |
| Bề mặt HTTP và giới hạn | crates/aeronyx-server/src/api/chat_peer.rs | Tuyến, giới hạn thân yêu cầu và yêu cầu đang xử lý, mã lỗi và nhóm lý do |
| Chính sách chống lạm dụng | crates/aeronyx-server/src/api/chat_peer_abuse_guard.rs | Giới hạn tốc độ theo chặng trước, điểm lỗi và cách ly |
| Sổ đăng ký chống phát lại | crates/aeronyx-server/src/api/chat_peer_replay.rs | Sổ đăng ký trong bộ nhớ và định dạng phản hồi đã lưu |
| Kho chống phát lại bền vững | crates/aeronyx-server/src/services/chat_relay_blind_route_store.rs | Giữ chỗ tuyến và phản hồi trong SQLite |
| Chính sách thử lại | crates/aeronyx-server/src/api/chat_peer_retry.rs | Phân biệt lỗi có thể thử lại với lỗi dứt khoát và thời điểm thử lại |
| Bộ đếm và chất lượng | crates/aeronyx-server/src/services/peer_store.rs và services/peer_store/status.rs | Bộ đếm tổng hợp, trạng thái sẵn sàng và phân loại bằng chứng |
| Báo cáo tình trạng | crates/aeronyx-server/src/api/vpn_health.rs và management/reporter.rs | JSON tình trạng cục bộ và dữ liệu heartbeat |
Phần mềm nút là mã nguồn mở theo giấy phép AGPL-3.0 tại github.com/AeroNyxNetwork/AeroNyx. Xem Khám phá nút và chuyển tiếp đa chặng mã hóa để biết cách các tuyến được xây dựng.
<!-- faq:start -->Câu hỏi thường gặp
Một nút chuyển tiếp có thể đọc hoặc ghi nhật ký lưu lượng mà nó chuyển tiếp không?
Không. Một trạm chuyển tiếp kiểm tra siêu dữ liệu định tuyến có chữ ký và chuyển tiếp một phong bì không minh bạch. Trạm chuyển tiếp chỉ giữ các bộ đếm tổng hợp, không bao giờ giữ dữ liệu, lịch sử tuyến hay danh tính người nhận.
Điều gì xảy ra khi một nút thử lại cùng một tuyến?
Nếu lần thử đầu tiên đã kết thúc, nút phát lại phản hồi đã lưu và không phân phối bất cứ thứ gì lần thứ hai. Nếu lần thử đầu tiên vẫn đang chạy, nút trả về route_in_flight có thể thử lại. Một yêu cầu khác nhưng dùng cùng ID tuyến bị từ chối với replay_conflict.
Cơ chế chống phát lại có còn hiệu lực sau khi nút khởi động lại không?
Có, khi kho chuyển tiếp trò chuyện của nút được bật. Khi đó, các lượt giữ chỗ tuyến và phản hồi đã hoàn tất được lưu trong SQLite. Nếu không có kho đó, nút sử dụng một sổ đăng ký trong bộ nhớ sẽ bị xóa khi khởi động lại.
Vì sao một nút ngang hàng bị cách ly?
Một nút ngang hàng bị cách ly trong năm phút sau khi gửi hơn 120 yêu cầu trong 60 giây, hoặc sau 12 lỗi xác thực được tính điểm trong năm phút. Hết thời gian chờ, mất xác nhận và thử lại trùng lặp không được tính là lỗi.
Vì sao nút của tôi trả về backpressure khi chịu tải?
Tất cả các vị trí tác vụ mật mã chuyển tiếp của nút đều đang bận. Một nút cho phép khoảng một nửa số luồng CPU của nó (tối thiểu 4, tối đa 8) dành cho tác vụ chữ ký và onion, và từ chối ngay lập tức các yêu cầu vượt mức thay vì xếp hàng chúng.
<!-- faq:end -->