Phản hồi đi ra qua LAN, không phải qua đường hầm: tại sao và thế nào

Một dịch vụ được công bố qua cổng hoạt động từ phần lớn internet và thất bại từ một văn phòng. Ai đó kiểm tra đường hầm, thấy yêu cầu đến và kết luận rằng phản hồi phải quay lại theo cùng đường. Linux không hoạt động như vậy, và việc kiểm tra đường hầm bao nhiêu cũng không thay đổi câu trả lời. Phản hồi được định tuyến theo đích, và kẻ gọi duy nhất thất bại đó nằm trên một mạng con mà máy chủ đã tiếp cận trực tiếp.

Điều gì thực sự quyết định một gói tin đi ra

Nhân hệ điều hành tra cứu tuyến đường cho đích của gói tin, xem xét các quy tắc chính sách theo thứ tự ưu tiên rồi đến bảng mà một quy tắc khớp chọn. Giao diện mà gói tin đến không đóng vai trò nào, trừ khi có một quy tắc hoặc dấu được ghi để làm cho nó quan trọng. Đó là một sự thật định tuyến của máy chủ này, không phải lỗi của đường hầm.

Vì vậy một yêu cầu nhận được qua đường hầm có thể tạo ra phản hồi đi ra qua giao diện vật lý, và luồng trở nên một chiều mà không thiết bị nào báo lỗi. Hãy kiểm tra cả hai chiều trước khi kết luận về đường hầm. Một phản hồi đi ra sai hướng biến mất khỏi các bộ đếm của đường hầm, đó là lý do hai đầu không đồng ý về việc có gì đó đã được gửi hay chưa. Hãy để ý bộ đếm nào đã thay đổi trước khi chạm vào một quy tắc.

Tại sao mạng con cục bộ thắng

Một máy chủ có địa chỉ trên mạng cục bộ giữ một tuyến đã kết nối cho tiền tố đó trong bảng chính, và tuyến đã kết nối là một khớp trực tiếp. Khi kẻ gọi đến từ cùng mạng con đó, việc tra cứu tìm thấy liên kết cục bộ trước khi đường hầm được xem xét.

Chính sự bất đối xứng khiến việc chẩn đoán trở nên khó hiểu. Những kẻ gọi từ internet rộng hơn hoạt động vì chúng không khớp với tuyến cục bộ nào, trong khi kẻ gọi duy nhất chia sẻ tiền tố của văn phòng lại thất bại, và đó chính là kẻ gọi mà ai đó dùng để kiểm thử.

Phạm vi của peer không giống các tuyến đã cài đặt

Về phía đường hầm, các dải được phép của một peer mô tả những gì có thể gửi vào đường hầm và những nguồn nào được chấp nhận từ đó. Chúng không nói gì về nơi bảng định tuyến cục bộ sẽ gửi gói tin.

Nếu công cụ đường hầm cài một tuyến mặc định trên máy chủ, nó có thể kéo lưu lượng không liên quan vào đường hầm như thiệt hại phụ. Ở nơi lẽ ra một quy tắc chính sách phải nắm quyết định, tùy chọn cài tuyến của công cụ tồn tại chính là để ngăn điều đó, và địa chỉ, khóa cùng cài đặt điểm cuối vẫn giữ nguyên như cũ. Một tuyến mặc định được thêm cho tiện lợi là cách phổ biến khiến máy chủ mất mạng cục bộ của chính nó.

Chọn bảng theo địa chỉ nguồn

Một quy tắc dựa trên nguồn gửi các phản hồi từ địa chỉ dịch vụ vào một bảng riêng có giá trị mặc định là đường hầm, trong khi mọi thứ khác tiếp tục dùng bảng chính. Hãy chọn số bảng và số ưu tiên không được dùng cục bộ, và đọc các quy tắc hiện có trước khi chèn bất cứ thứ gì. Hãy đọc các quy tắc đang hoạt động thay vì tệp đã lưu, vì hai thứ đó có thể khác nhau sau khi khởi động lại.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Dòng cuối khiến một tuyến bị thiếu thất bại một cách rõ ràng thay vì quay về liên kết cục bộ. Nguồn phải thực sự được gán cho máy chủ, và các tra cứu cục bộ cũng như tra cứu chính thông thường phải giữ nguyên vị trí cũ. Quy tắc chọn bảng theo nguồn; nó không so sánh độ dài tiền tố giữa các bảng.

Xác nhận đường đi, rồi đến dịch vụ

Hãy hỏi nhân hệ điều hành xem nó sẽ làm gì thay vì suy luận từ bản ghi bắt gói, dùng địa chỉ dịch vụ làm bộ chọn nguồn. Một câu trả lời đúng ở đây tiết kiệm cả một quá trình theo dõi gói tin.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Kết quả phải nêu tên đường hầm. Sau đó thử một nguồn bạn không chạm vào và xác nhận nó vẫn dùng liên kết cục bộ, để thay đổi vẫn giới hạn trong một địa chỉ. Một bộ chọn rộng hơn sẽ không chứng minh được gì về khiếu nại ban đầu.

Điều mà cách này không khắc phục

Hãy để việc chuyển tiếp, các quy tắc tường lửa và hành vi ICMPv6 trên cổng như cũ, vì tuyến theo nguồn không thay thế bất kỳ điều nào trong số đó. Một thông báo Packet Too Big bị thiếu vẫn làm hỏng các phản hồi lớn, bất kể bảng nào thắng cuộc tra cứu. Hãy sửa điều đó trước khi thêm quy tắc định tuyến, nếu không triệu chứng sẽ tồn tại sau thay đổi.

Hãy xác nhận mô hình công bố trước khi áp dụng bất kỳ điều nào trong số này. Một proxy ngược mở kết nối backend riêng của nó sẽ trình bày nguồn của chính nó và không giữ lại kẻ gọi, nên lỗi này không thể xảy ra trong thiết kế đó. Áp dụng quy tắc ở đó sẽ thêm một ngoại lệ định tuyến không giải quyết được gì và che giấu nguyên nhân thực sự.

Cuối cùng, hãy ghi số quy tắc và bảng vào quản lý cấu hình của máy chủ. Một quy tắc chính sách được thêm bằng tay sẽ biến mất ở lần dựng lại tiếp theo, và kẻ gọi từ văn phòng quay lại với cùng khiếu nại.