Tôi đang cố gắng chuyển tiếp giao thức 41 (ipv6-in-ipv4) cho đường hầm HE thông qua WRT54G chạy Tomato 1.28. Tomato 1.28 đang chạy kernel 2.4 hoàn toàn không biết gì về giao thức 41, ngoại trừ việc nó được đặt tên là "ipv6". Có một hạt nhân 2.4 cũng có nghĩa là conntrack không thể bị vô hiệu hóa: không có quy tắc iptables "thô".
Tôi có thể thiết lập các quy tắc để các gói đến là DNAT-ed đến máy chủ nội bộ chính xác. Nếu máy chủ từ xa gửi một cái gì đó qua đường hầm trước, mọi thứ đều hoạt động tốt. Các gói có thể chảy qua đường hầm theo cả hai hướng với NATing thích hợp và tôi nhận được một /proc/net/ip_conntrack mục như thế này:
unknown 41 599 src=72.52.104.74 dst=67.180.229.14 src=10.1.0.3 dst=72.52.104.74 use=1 mark=0
Mục nhập cho biết đó là giao thức không xác định 41, có thời gian chờ là hơn 599 giây nếu không nhận được thêm lưu lượng truy cập và có một cặp địa chỉ nguồn và đích ở phía bắt đầu (là phía WAN) và một bên khác ở phía bên nhận (đó là phía mạng LAN).
Nhưng nếu hệ thống của tôi cố gắng gửi một gói ra khỏi đường hầm trước tiên, địa chỉ nguồn sẽ không được dịch sang địa chỉ của bộ định tuyến như mong muốn và tôi nhận được một mục conntrack như thế này:
unknown 41 589 src=10.1.0.3 dst=72.52.104.74 [UNREPLIED] src=72.52.104.74 dst=10.1.0.3 use=1 mark=0
Miễn là máy của tôi tiếp tục cố gắng sử dụng đường hầm, nó sẽ giữ cho mục nhập conntrack không có thật này tồn tại và tôi có thể thấy các gói rời khỏi bộ định tuyến của mình cho modem cáp với địa chỉ nguồn bên trong vẫn được gắn vào, khiến chúng bị rơi và không bao giờ đến được họ đang đi.
Để làm cho đường hầm của tôi xuất hiện, tôi phải đưa giao diện đường hầm xuống, sử dụng công cụ ping HE để tạo ra một số lưu lượng IPv6 để đi xuống đường ống, và trong khi thời gian chờ 10 phút vẫn hoạt động đúng nhập conntrack, đưa phần cuối của đường hầm của tôi trở lại một lần nữa - và sau đó đảm bảo nó không bao giờ nhàn rỗi trong 10 phút ở một đoạn. tôi có thể làm điều đó, nhưng nó khá ngu ngốc.
Ngay bây giờ tôi có các quy tắc chuyển tiếp của mình được thiết lập như thế này:
# Send incoming ipv6-in-ipv4 packets to the correct host
iptables -t nat -A PREROUTING -p 41 -s 72.52.104.74 -j DNAT --to 10.1.0.3
# Allow those packets through the firewall
iptables -I FORWARD -p 41 -d 10.1.0.3 -j ACCEPT
# Things I have added to try and solve my problem, which didn't work:
# Remove the default masquerade-everything rule
iptables -t nat -D POSTROUTING 10
# Masquerade only protocols other than 41. Conntrack still gets its bogus entries,
# and if I get the correct entry in it still works.
iptables -t nat -A POSTROUTING -p ! 41 -j MASQUERADE
Tôi cũng đã có lúc thử thiết lập quy tắc SNAT như thế này:
iptables -t nat -I POSTROUTING -p 41 -s 10.1.0.3 -j SNAT --to 67.180.229.14
Nhưng theo như tôi có thể nói, điều đó cũng không giúp được gì.
Vì vậy, câu hỏi của tôi là:
1. Nếu vậy, bạn đã sử dụng quy tắc tường lửa đặc biệt nào?
2) Tại sao bộ định tuyến nghĩ rằng nó không phải thực hiện dịch địa chỉ nguồn trên giao thức gửi đi 41?