Phản hồi của VPN trên Linux biến mất? Kiểm tra rp_filter và tuyến đường

Các yêu cầu rời khỏi máy, đối tác VPN trả lời, và phản hồi không bao giờ đến được socket. Đường hầm đang hoạt động, nhật ký của đối tác cho thấy gói tin được gửi đi, và không có gì trong ứng dụng giải thích sự im lặng đó. Trên Linux, một trong những nghi phạm thường gặp là lọc đường dẫn ngược: một gói tin IPv4 đi vào có thể bị từ chối khi việc xác thực nguồn không khớp với tuyến đường mà nhân hệ điều hành mong đợi cho nguồn đó. Đi qua theo thứ tự sẽ cho biết đây là nguyên nhân hay chỉ là sự trùng hợp. Nó cũng giúp bạn không phải tắt một biện pháp bảo mật để sửa một tuyến đường bị thiếu.

Việc xác thực nguồn quyết định điều gì

Nhân hệ điều hành kiểm tra xem địa chỉ nguồn của gói tin có hợp lý với giao diện mà nó đến hay không, bằng cách tra bảng định tuyến để tìm tuyến đường quay lại nguồn đó. Nếu tuyến đường ngược chỉ đến nơi khác, gói tin có thể bị loại bỏ trước khi bất kỳ quy tắc tường lửa hay socket ứng dụng nào nhìn thấy nó. Việc kiểm tra đó tồn tại để làm cho một số kiểu giả mạo khó hơn, và đó cũng là lý do các thiết kế không đối xứng và định tuyến theo chính sách vấp phải nó trong khi mọi máy khách thông thường trên cùng mạng vẫn hoạt động tốt. Máy khách thông thường có định tuyến đối xứng, đúng như điều mà việc kiểm tra giả định.

Từ quan trọng là hợp lý. Gói tin có thể hoàn toàn hợp pháp mà vẫn không qua được kiểm tra, vì thứ được kiểm tra không phải tính hợp pháp.

Đọc chế độ thực tế, không phải một trường

Có ba chế độ: tắt, nghiêm ngặt và lỏng lẻo. Nghiêm ngặt áp đặt kỳ vọng tuyến đường khác với lỏng lẻo, và thiết lập toàn cục tương tác với thiết lập của từng giao diện, nên đọc một tệp có thể mô tả sai điều đang thực sự có hiệu lực. Hãy đọc cả hai, và đọc chúng trên giao diện nhận phản hồi, không phải trên giao diện của tuyến đường mặc định.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Việc tra tuyến đường ở dòng thứ ba là phần mọi người bỏ qua. Nó cho biết nhân hệ điều hành nghĩ gì về nguồn, và đó chính là đầu vào của việc kiểm tra.

Tìm sự không khớp trước khi thay đổi việc kiểm tra

Tìm hiểu tại sao phản hồi đến trên giao diện đó và liệu tuyến đường ngược của nó có nên khác đi không. Một quy tắc chính sách gửi yêu cầu ra theo một đường trong khi phản hồi quay về theo đường khác là thiết kế hợp pháp, và đó cũng chính là thiết kế mà việc xác thực nghiêm ngặt từ chối. Các dấu được dùng trong định tuyến theo chính sách cũng có thể quan trọng ở đây, vì chúng thay đổi thứ mà việc tra ngược trả về.

Nếu tuyến đường ngược chỉ đơn giản là thiếu, việc thêm nó sẽ sửa nguyên nhân thay vì tắt một lần kiểm tra. Tuyến đường thiếu, việc bị tường lửa từ chối và bộ chọn lưu lượng sai đều tạo ra cùng một triệu chứng nhìn thấy được, và chỉ một trong số đó là về xác thực nguồn.

Đừng tắt các kiểm tra nguồn trên toàn cục như phản ứng đầu tiên. Điều đó đổi một chẩn đoán cụ thể lấy một thay đổi hành vi rộng mà bạn sẽ phải nhớ về sau.

Một điều chỉnh có chọn lọc mà bạn có thể biện hộ

Nếu thực sự cần một điều chỉnh hẹp, hãy giới hạn nó ở giao diện cần đến, ghi lại lý do, và đặt nó trong cấu hình sở hữu giao diện đó để nó tồn tại qua lần khởi động lại. Sau đó kiểm tra lại đúng luồng đã thất bại, từ cùng nguồn đến cùng đích, thay vì ping đến một thứ gì đó thuận tiện.

Đưa vào một trường hợp vẫn phải bị từ chối. Nếu trường hợp đó giờ thành công, điều chỉnh đã làm yếu đi nhiều hơn một con đường mà bạn định sửa.

Giữ IPv4 và IPv6 tách biệt

Một sysctl trông quen thuộc không phải là chính sách cho mọi họ địa chỉ. IPv6 có hành vi và thiết lập riêng, và một máy có thể nghiêm ngặt ở họ này và dễ dãi ở họ kia mà không ai nhận ra cho đến khi một đích cụ thể thất bại. Hãy kiểm tra cả hai nếu khối lượng công việc dùng cả hai.

Ghi lại chế độ, giao diện, kết quả tra tuyến đường và lý do thay đổi ở một chỗ. Người tiếp theo sẽ tìm thấy thiết lập mà không có lời giải thích nào, và sẽ gỡ nó đi hoặc sao chép nó đến nơi nó không thuộc về.