Vì sao net.ipv4.conf.default.forwarding không đụng tới tun0

Bạn đặt net.ipv4.conf.default.forwarding=1, khởi động lại VPN, và đường hầm vẫn bỏ rơi những gói mà cổng vào lẽ ra phải định tuyến. Cấu hình trong tệp trông đúng, và giao diện vẫn báo rằng chuyển tiếp đang tắt. Không có gì hỏng: bạn đã đổi giá trị mà các giao diện tương lai sẽ kế thừa, không phải giá trị mà đường hầm đang chạy dùng.

Hãy rà lại điều này trên máy chủ sở hữu đường hầm, trong namespace mạng nơi đường hầm thực sự tồn tại. Một container hoặc namespace mạng có thể giữ giao diện trong khi máy chủ hiển thị những con số khác.

Đọc ba giá trị cùng lúc

Bắt đầu bằng việc so sánh công tắc toàn cổng vào, mẫu cho các giao diện mới và giao diện bạn quan tâm. Thay tun0 bằng giao diện vào thật, và đọc cả giao diện quay về, vì chuyển tiếp được đánh giá tại điểm mà gói tin đến.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Một kết quả thường gặp là ip_forward = 0, default.forwarding = 1 và tun0.forwarding = 0. Hai giá trị đầu không thống nhất về vai trò của máy chủ, và giá trị thứ ba cho thấy giao diện thực sự đang làm gì. Tổ hợp đó khớp với một máy chủ chưa bao giờ được cấu hình làm bộ định tuyến, chỉ được cấp một giá trị mẫu. Ba con số không mâu thuẫn với nhau; chúng trả lời ba câu hỏi khác nhau. Việc ghi giá trị mẫu cũng không quyết định vai trò của máy chủ.

Vì sao công tắc toàn cục mới là thứ di chuyển

net.ipv4.ip_forward là điều khiển toàn cổng vào. Thay đổi nó sẽ cập nhật cấu hình chuyển tiếp theo từng giao diện như một phần của cùng thao tác, nên một lần ghi có thể khiến một đường hầm đang có bắt đầu chuyển tiếp. default.forwarding chỉ gieo những giao diện được khởi tạo sau đó, nên đường hầm đã tồn tại giữ nguyên giá trị mà nó sinh ra cùng.

Tài liệu của nhân đánh dấu ip_forward là đặc biệt vì một lý do liên quan: thay đổi nó đặt lại một loạt tham số IPv4 khác về mặc định của máy chủ hoặc bộ định tuyến. Điều đó khiến nó thành một công cụ thô. Đặt nó một lần trong khuôn khổ thiết lập vai trò cổng vào là ổn; bật tắt nó lặp đi lặp lại như một mẹo gỡ lỗi có thể âm thầm ghi đè cấu hình mà bạn đã mất thời gian chỉnh cho đúng.

Các giá trị theo từng giao diện cũng có lý do. Một cổng vào được quản lý có chủ đích có thể giữ chuyển tiếp tắt trên một giao diện lẽ ra không bao giờ định tuyến, ngay cả khi máy chủ chuyển tiếp ở nơi khác. Đó là lý do việc đọc giao diện đang sống quan trọng và lý do chỉ giá trị toàn cục không phải là toàn bộ câu trả lời. Hãy đọc ngoại lệ như vậy như một quyết định có chủ đích, và ghi lại vì sao giao diện đó khác. Nếu không, kỹ sư tiếp theo sẽ "sửa" nó một cách ân cần.

Hãy làm cho cấu hình tồn tại lâu dài ở đúng chỗ

Một sysctl -w một lần thành công chứng minh rằng nhân chấp nhận giá trị đó. Nó không sống qua lần khởi động lại, và cũng không sống qua trình quản lý mạng vốn áp dụng lại ý niệm của chính nó về cấu hình giao diện khi kết nối lại. Đặt vai trò cổng vào trong tệp cấu hình sysctl hoặc trong trình quản lý mạng sở hữu máy chủ, rồi khởi động lại dịch vụ áp dụng nó.

Thứ tự quan trọng với đường hầm. Nếu trình quản lý tạo giao diện lúc khởi động và áp dụng chuyển tiếp sau đó, giao diện có thể kế thừa mặc định cũ. Việc khởi động lại dịch vụ tạo lại đường hầm cũng là một sự kiện tạo lập, và rất dễ bỏ sót khi unit trông khỏe mạnh. Hãy kiểm tra trình tự, không chỉ nội dung cuối cùng của tệp.

Đọc lại đúng ba giá trị đó sau khi VPN kết nối lại và một lần nữa sau khi khởi động lại. Một đường hầm mới tạo là một giao diện mới, và giao diện mới nhận mặc định đang có hiệu lực tại thời điểm tạo. Nếu các con số thay đổi qua những sự kiện đó, cấu hình đang được áp dụng bởi một thứ mà bạn chưa nhận diện ra.

Đừng sửa điều này bằng công cụ sai

Khi chuyển tiếp trông như hỏng, cám dỗ là xóa sạch tường lửa hoặc thêm masquerading. Không cái nào xử lý công tắc chuyển tiếp. Trạng thái chuyển tiếp, quyền được chuyển tiếp, một tuyến đường tới đích và một đường quay về là bốn yêu cầu riêng biệt, và chỉ yêu cầu đầu tiên là sysctl.

Cũng hãy thử với luồng đúng. Một yêu cầu thực hiện trên chính cổng vào không hề luyện tập chuyển tiếp; đó là lưu lượng sinh ra tại chỗ. Câu hỏi là liệu một gói đến từ máy khách VPN hoặc máy chủ LAN có được chấp nhận và định tuyến đi tiếp hay không, nên bài kiểm tra phải bắt đầu từ phía sau cổng vào.

Giữ trường hợp IPv6 tách riêng

Ở đây mọi thứ là IPv4. Chuyển tiếp IPv6, quảng bá bộ định tuyến và hành vi accept_ra có điều khiển riêng, và việc sao chép một đường ipv4 vào cấu hình ipv6 tạo ra một tệp trông hợp lý mà không làm gì hữu ích. Một cổng vào hai ngăn xếp cần cả hai bộ được cấu hình có chủ đích.

Một lần kiểm tra cuối: sau khi các giá trị khớp nhau, hãy xác nhận rằng tuyến của đường hầm được chọn cho đích và đường phản hồi tồn tại. Chuyển tiếp được bật trên một giao diện không có tuyến vẫn là một hố đen, và lỗi đó trông giống nhau từ phía máy khách.