Nebula: relay đã cấu hình nhưng không dùng — ba thiết lập cần kiểm tra

Bạn đã thêm một máy chủ relay, đặt địa chỉ Nebula của nó vào tệp cấu hình, mà hai peer vẫn không nói chuyện được. Điều này xảy ra vì đường relay cần ba khai báo riêng biệt khớp nhau, và chỉ một trong số đó nằm trên máy mà bạn có lẽ đã sửa. Tôi đã đuổi theo việc này hai lần: một lần máy chủ chuyển tiếp chưa bao giờ được giao vai trò relay, và một lần các thiết lập được ghi ở phía sai của kết nối. Trình tự dưới đây kiểm tra vai trò, quảng bá và quyền theo đúng thứ tự đó, và mỗi bước có một lệnh cho biết có nên tiếp tục hay không.

Lập bản đồ ba vai trò trước khi sửa cấu hình

Nebula giao cho mỗi máy chủ một nhiệm vụ, và các nhiệm vụ không được kế thừa. Hải đăng trả lời câu hỏi 'peer này ở đâu' để các máy chủ tìm thấy nhau. Relay chuyển tiếp lưu lượng giữa hai peer không có đường trực tiếp hoạt động. Một máy chủ thông thường không làm cả hai. Ba thiết lập quan trọng nằm trên ba máy khác nhau, vì thế một cấu hình máy khách trông đầy đủ vẫn có thể để cả hai peer chờ.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Một triệu chứng phân biệt hai loại lỗi. Nếu cả hai peer liệt kê nhau và nhật ký cho thấy các lần bắt tay không bao giờ hoàn tất, việc khám phá đang hoạt động và đường dữ liệu bị NAT hoặc tường lửa chặn. Nếu một peer không bao giờ biết địa chỉ của bên kia, vấn đề nằm ở hải đăng hoặc bản đồ máy chủ tĩnh của nó, và thiết lập relay không sửa được điều đó.

Xác nhận mỗi máy chủ thực sự đã tải cấu hình nào trước khi sửa bất cứ thứ gì khác. Một unit đọc đường dẫn khác với tệp bạn đã sửa là nguyên nhân phổ biến và đáng xấu hổ của 'thay đổi không làm gì cả':

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

Dòng phiên bản quan trọng trong một đội hình hỗn hợp. Cách xử lý relay, hành vi đục lỗ và các khóa cấu hình được chấp nhận không giống nhau giữa các bản phát hành, vì thế đừng cho rằng bản dựng cũ hiểu một phần mà nó không được viết cho. Căn đều các máy chủ về cùng một dòng phụ, sau đó chạy nebula -test -config /etc/nebula/config.yml trên từng máy chủ và so sánh đầu ra trước khi gỡ lỗi một giao vận mà mã không triển khai.

Bật vai trò chuyển tiếp trên máy chủ relay

Vai trò relay là một cờ trên máy chủ chuyển tiếp, và tách biệt với việc là hải đăng. Một máy chủ bật khám phá và tắt chuyển tiếp relay vẫn chỉ là dịch vụ khám phá. Trên relay:

relay:
  am_relay: true

Cờ này khai báo ý định; nó không tạo ra khả năng tiếp cận. Relay phải tiếp cận được từ cả hai peer, mà trên thực tế nghĩa là địa chỉ công cộng, UDP vào trên cổng Nebula được mở trong tường lửa của máy chủ và trong bất kỳ nhóm bảo mật đám mây nào, và không có NAT hai lớp phía trước. Kiểm tra socket đang lắng nghe, rồi quan sát các gói của peer đến:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

Hai giới hạn tiết kiệm thời gian về sau. Không thể đến relay qua một relay khác, nên một chuỗi tên relay trong cấu hình không thay thế việc cho máy chủ chuyển tiếp một đường dùng được. Và relay chuyển tiếp gói; nó không cấp quyền, nên các quy tắc vào của đích vẫn quyết định luồng đã chuyển tiếp có được phép hay không. Vai trò và các yêu cầu của nó được trình bày trong tài liệu cấu hình relay.

Quảng bá relay từ phía đích, không phải từ máy khách

Đây là sự đảo ngược ngốn nhiều giờ nhất. Danh sách relay thuộc về máy chủ bạn đang cố đến, vì nó cho các peer khác biết relay nào có thể dùng để đến máy chủ đó. Đặt nó trên máy khách khởi tạo kết nối không làm gì cho hướng mà máy khách cần:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

Các peer báo cáo danh sách đó cùng với địa chỉ của chúng khi đăng ký với hải đăng, nên quảng bá lan truyền qua khám phá chứ không qua trao đổi trực tiếp. Nếu đích không đến được hải đăng, danh sách relay của nó không bao giờ lan ra và một relay được cấu hình đúng sẽ nằm không. Lỗi đó trông đúng như một relay hỏng và không phải vậy.

Cho đích một đường khởi động trong cùng lượt. Bản đồ máy chủ tĩnh gắn một địa chỉ Nebula với một điểm cuối công cộng để lần bắt tay đầu tiên có nơi để đi, và nó cần một mục cho relay nếu đích sẽ chấp nhận lưu lượng chuyển tiếp từ các máy chủ mà nó không thể đến trực tiếp:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Cho phép peer kết nối dùng relay

Phía khởi tạo cần quyền riêng của nó. relay.use_relays được bật theo mặc định, nên trường hợp đáng tìm là một false rõ ràng, thường được sao chép từ mẫu viết trước khi tính năng relay tồn tại hoặc còn sót lại từ một lần cố ép buộc đường trực tiếp trước đó:

relay:
  use_relays: true

Quyền ở phía này không phải cổng duy nhất. Các quy tắc vào của đích vẫn áp dụng cho gói đã chuyển tiếp, và nguồn mà chúng khớp là danh tính bên trong đường hầm chứ không phải địa chỉ của chính relay. Khi bắt tay đã chuyển tiếp hoàn tất mà ứng dụng vẫn lỗi, hãy đọc nhật ký của đích để tìm nguồn mà nó đã ghi lại trước khi viết lại một quy tắc.

Các thiết lập xuyên NAT tương tác với tất cả những điều này. punchy.punch giúp hai peer mở một đường trực tiếp, và khi thành công thì không có lưu lượng relay để quan sát; đó là thành công, không phải thiếu relay. Một cặp hoạt động chập chờn thường có nghĩa là việc đục lỗ đôi khi thành công, nên hãy kiểm tra cặp đó vài lần thay vì kết luận từ một lần thử.

Xác minh với cặp đã lỗi, rồi tải lại

Kiểm tra hai máy chủ thực sự đã lỗi, với ứng dụng chúng cần. Một ping thành công từ máy trạm của bạn đến dịch vụ của chính relay không chứng minh gì về việc chuyển tiếp giữa hai peer khác, và đây là dương tính giả phổ biến nhất trong toàn bộ quy trình này.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

Tải lại thay vì khởi động lại, và xác nhận tiến trình đang chạy đã nhận tệp bạn sửa. Khởi động lại phá mọi đường hầm và làm lần kiểm tra tiếp theo khó đọc hơn, trong khi SIGHUP giữ tiến trình và buộc nó đọc lại cấu hình:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload chỉ hoạt động khi unit cục bộ định nghĩa ExecReload, và unit đi kèm dự án thì không, nên bước thành công trên một bản cài đặt tiêu chuẩn là systemctl kill -s HUP. Sau khi tải lại, hãy đọc nhật ký cho đường dẫn cấu hình mà tiến trình đã mở, để biết rằng tệp mới đã được đọc chứ không phải tệp bạn giả định.

Thiết lập relay và đục lỗ NAT đều tác động lên đường đi; không cái nào tác động lên danh tính. Nếu cặp vẫn lỗi bắt tay sau khi am_relay, relays và use_relays được xác nhận trong cấu hình đang chạy, hãy kiểm tra rằng cả hai máy chủ trình bày chứng chỉ được cấp cho các tên chúng được cấu hình và CA giống nhau ở cả hai phía. Giữ nguyên chứng chỉ và cấu hình tường lửa trong khi thay đổi từng thiết lập giao vận một, vì một chỉnh sửa chứng chỉ và một chỉnh sửa relay rơi vào cùng một lần kiểm tra không cho bạn biết cái nào đã làm bắt tay dịch chuyển. Tên hoặc CA không khớp lỗi ở đúng chỗ mà một relay không bao giờ được tìm thấy lỗi, nên phép đối chiếu này thuộc cùng lượt.

Sau đó xác nhận mỗi khai báo nằm trong tệp mà nó thuộc về:

• am_relay: true trên máy chủ chuyển tiếp, và máy chủ đó tiếp cận được qua UDP từ cả hai phía.
• relays: nêu địa chỉ Nebula của máy chủ đó trên đích.
• use_relays: true trên peer khởi tạo kết nối.
• Các quy tắc vào trên đích vẫn cho phép nguồn thực sau khi đường đi thay đổi.