Bắt Squid và TPROXY với IPv6 hoạt động trên CentOS 7


18

Tôi gặp sự cố khi TPROXY hoạt động với Squid và IPv6 trên máy chủ CentOS 7. Trước đây tôi đã sử dụng một thiết lập chặn chung với NAT, nhưng nó chỉ giới hạn ở IPv4. Tôi hiện đang mở rộng thiết lập để bao gồm IPv6 với TPROXY.

Tôi đã sử dụng bài viết wiki Squid chính thức về chủ đề này để định cấu hình mọi thứ:

http://wiki.squid-cache.org/Features/Tproxy4

Cho đến nay, cấu hình TPROXY dường như đang hoạt động cho IPv4 mà không gặp vấn đề gì. Tuy nhiên, với IPv6, các kết nối đã hết thời gian và không hoạt động đúng. Tôi sẽ chia nhỏ thiết lập để hiểu rõ hơn.

Lưu ý tất cả các quy tắc tường lửa và định tuyến hoàn toàn giống nhau đối với IPv4, sự khác biệt duy nhất là inet6ip6tablesđể định cấu hình các quy tắc dựa trên IPv6 trong các ví dụ bên dưới.

  • Hệ điều hành và hạt nhân: CentOS 7 (3.10.0-229.14.1.el7.x86_64)
  • Tất cả các gói được cập nhật theo yum
  • Phiên bản mực: 3.3.8 (Cũng đã thử 3.5.9)
  • Tường lửa: iptables / ip6tables 1.4.21
  • libcap-2.22-8.el7.x86_64

Kết nối IPv6 hiện đang thông qua một đường hầm 6in4 thông qua Hurricane Electric, điều này được cấu hình trên bộ định tuyến DD-WRT và sau đó tiền tố được chỉ định được ủy quyền cho khách hàng thông qua radvd. Hộp Squid có một số địa chỉ IPv6 tĩnh được cấu hình.

Hộp mực nằm trong mạng LAN chính mà nó đang phục vụ. Các máy khách đang có lưu lượng truy cập trên cổng 80 bị chặn (chủ yếu là các máy khách không dây) đang được đẩy đến hộp Mực thông qua bộ định tuyến DD-WRT của tôi với các quy tắc tường lửa và định tuyến sau, được điều chỉnh từ bài viết wiki Chính sách định tuyến và wiki DD-WRT

Điều này dường như hoạt động tốt về mặt truyền lưu lượng truy cập vào hộp Mực. Một quy tắc bổ sung mà tôi phải thêm vào bộ định tuyến DD-WRT ngoài các quy tắc trên là quy tắc ngoại lệ đối với các địa chỉ IPv4 và IPv6 gửi đi được định cấu hình trên hộp Mực, nếu không, tôi gặp sự cố vòng lặp điên rồ và lưu lượng truy cập bị phá vỡ cho tất cả các máy khách bao gồm mạng LAN chính sử dụng Squid trên 3128.

ip6tables -t mangle -I PREROUTING -p tcp --dport 80 -s "$OUTGOING_PROXY_IPV6" -j ACCEPT

Trên hộp Mực tôi sau đó sử dụng các quy tắc định tuyến sau và chuỗi DIVERT để xử lý lưu lượng phù hợp. Tôi cần thêm các quy tắc bổ sung để ngăn chặn bất kỳ lỗi nào với chuỗi đã tồn tại trong quá trình thử nghiệm. Tường lửa của tôi là CSF, tôi đã thêm vào saucsfpre.sh

ip -f inet6 route flush table 100
ip -f inet6 rule del fwmark 1 lookup 100

ip -f inet6 rule add fwmark 1 lookup 100
ip -f inet6 route add local default dev eno1 table 100

ip6tables -t mangle -F
ip6tables -t mangle -X
ip6tables -t mangle -N DIVERT

ip6tables -t mangle -A DIVERT -j MARK --set-mark 1
ip6tables -t mangle -A DIVERT -j ACCEPT
ip6tables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
ip6tables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129

squid.conf được cấu hình cho hai cổng:

http_proxy 3128
http_proxy 3129 tproxy

Ngoài ra, tôi cũng đang sử dụng Privoxy và phải thêm no-tproxyvào dòng cache_peer của mình, nếu không tất cả lưu lượng truy cập không thể được chuyển tiếp cho cả hai giao thức.

cache_peer localhost parent 8118 7 no-tproxy no-query no-digest

Tôi không sử dụng bất kỳ tcp_outgoing_addresschỉ thị nào vì Privoxy, thay vào đó tôi đang kiểm soát các địa chỉ gửi đi thông qua CentOS và thứ tự ràng buộc.

giá trị sysctl:

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eno1.rp_filter = 0

Tôi không chắc chắn nếu các rp_filtersửa đổi là cần thiết vì thiết lập hoạt động trên IPv4 có hoặc không có chúng và tạo ra kết quả tương tự cho IPv6.

TỰ ĐỘNG

SELINUX được bật trên hộp Mực, nhưng các chính sách đã được định cấu hình để cho phép thiết lập TPROXY, do đó, nó không bị chặn (dù sao hoạt động của IPv4 cũng hiển thị điều này). Tôi đã kiểm tra grep squid /var/log/audit/audit.log | audit2allow -avà nhận<no matches>

#============= squid_t ==============

#!!!! This avc is allowed in the current policy
allow squid_t self:capability net_admin;

#!!!! This avc is allowed in the current policy
allow squid_t self:capability2 block_suspend;

#!!!! This avc is allowed in the current policy
allow squid_t unreserved_port_t:tcp_socket name_connect;

Tôi cũng đã thiết lập các booleans sau:

setsebool squid_connect_any 1
setsebool squid_use_tproxy 1

Kết nối IPv6 bị hỏng

Cuối cùng, kết nối IPv6 bị hỏng hoàn toàn cho các máy khách TPROXY (máy khách LAN trên cổng 3128sử dụng tệp WPAD / PAC có IPv6 hoạt động hoàn toàn). Mặc dù có vẻ như lưu lượng truy cập đang được chuyển đến hộp Mực theo một cách nào đó, không có yêu cầu nào qua IPv6 thông qua TPROXY xuất hiện trong access.log. Tất cả IPv6 yêu cầu cả IPv6 và DNS theo nghĩa đen, hết thời gian. Tôi có thể truy cập các máy khách IPv6 nội bộ nhưng một lần nữa, lưu lượng này cũng không được ghi lại.

Tôi đã thực hiện một số thử nghiệm bằng cách sử dụng test-ipv6.com và thấy rằng nó đã phát hiện địa chỉ Squid IPv6 gửi đi của tôi nhưng các thử nghiệm IPv6 hiển thị là xấu / chậm hoặc hết thời gian. Tôi đã tạm thời kích hoạt tiêu đề thông qua và thấy tiêu đề Squid HTTP có thể nhìn thấy được, vì vậy lưu lượng truy cập ít nhất là vào hộp Squid nhưng không được định tuyến chính xác khi nó ở đó.

Tôi đã cố gắng để nó hoạt động được một thời gian và không thể tìm ra vấn đề là gì, tôi thậm chí đã hỏi trong danh sách gửi thư của Mực, nhưng không thể chẩn đoán vấn đề thực sự hoặc giải quyết nó. Dựa trên thử nghiệm của tôi, tôi khá chắc chắn rằng một trong những lĩnh vực sau đây và hộp Mực có vấn đề:

  • định tuyến
  • Hạt nhân
  • Bức tường lửa

Mọi ý tưởng và các bước bổ sung mà tôi có thể thực hiện để TPROXY và IPv6 hoạt động sẽ được đánh giá rất cao!

Thông tin thêm

quy tắc ip6tables:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DIVERT     tcp      ::/0                 ::/0                 socket
TPROXY     tcp      ::/0                 ::/0                 tcp dpt:80 TPROXY redirect :::3129 mark 0x1/0x1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Chain DIVERT (1 references)
target     prot opt source               destination
MARK       all      ::/0                 ::/0                 MARK set 0x1
ACCEPT     all      ::/0                 ::/0

Bảng định tuyến IPv6 (tiền tố bị che khuất)

unreachable ::/96 dev lo  metric 1024  error -101
unreachable ::ffff:0.0.0.0/96 dev lo  metric 1024  error -101
2001:470:xxxx:xxx::5 dev eno1  metric 0
    cache  mtu 1480
2001:470:xxxx:xxx:b451:9577:fb7d:6f2d dev eno1  metric 0
    cache
2001:470:xxxx:xxx::/64 dev eno1  proto kernel  metric 256
unreachable 2002:a00::/24 dev lo  metric 1024  error -101
unreachable 2002:7f00::/24 dev lo  metric 1024  error -101
unreachable 2002:a9fe::/32 dev lo  metric 1024  error -101
unreachable 2002:ac10::/28 dev lo  metric 1024  error -101
unreachable 2002:c0a8::/32 dev lo  metric 1024  error -101
unreachable 2002:e000::/19 dev lo  metric 1024  error -101
unreachable 3ffe:ffff::/32 dev lo  metric 1024  error -101
fe80::/64 dev eno1  proto kernel  metric 256
default via 2001:470:xxxx:xxxx::1 dev eno1  metric 1

Tôi đã thử cập nhật lên bản phát hành sau của Squid (3.5), để loại trừ bất kỳ lỗi / vấn đề phát hành nào nhưng vấn đề vẫn còn.
James White

1
Chỉ cần bình luận để nói rằng tôi đã làm việc này khoảng một năm trước trên hộp CentOS 6. Tuy nhiên, nó đột nhiên ngừng hoạt động một ngày (sau khi tôi cập nhật kernel) và tôi đã không quản lý để nó hoạt động kể từ đó. Nếu tôi kích hoạt cài đặt IPv6 TPROXY, về cơ bản nó sẽ phá vỡ tất cả lưu lượng truy cập cổng 80 và không có gì đạt được mực. Tôi đã từ bỏ với nó cho thời điểm này. Hạt nhân tôi hiện đang chạy là 2.6.32 - Tôi lưu ý rằng trên wiki.squid-cache.org/Features/Tproxy4 , họ liệt kê một bản án nhân tối thiểu là 2.6.37 vì vậy tôi đã thiếu nó. Nếu tôi từng nói ra, tôi sẽ cập nhật ở đây với những phát hiện của tôi.
parkamark

Vì vậy, cuối cùng tôi đã làm việc này. Vấn đề là do cổng "chặn" của IPv4 bằng với cổng "tproxy" IPv6 trong squid.conf - đây là chi tiết trong tài liệu, nhưng tôi nghĩ rằng tôi có thể thoát khỏi việc không làm điều này vì tôi đã nghe các cổng này địa chỉ / ngăn xếp cụ thể cùng với cổng, vì vậy không có lý do cụ thể tại sao họ nên xung đột, phải không? Vâng, điều này dường như là một giả định sai. Đọc trên ...
parkamark

Tôi đã xác định "http_port 192.168.0.1:3128 chặn" và "http_port [fd00 :: 2]: 3128 tproxy" trong squid.conf - đừng làm điều này! Nó chỉ đơn giản là "http_port 3128 chặn" và "http_port 3129 tproxy". Bạn không thể có cổng tproxy IPv6 liên kết với một địa chỉ IPv6 cụ thể và sau đó mong đợi tất cả các phép thuật tường lửa / định tuyến hoạt động. Bạn chỉ có thể chỉ định các cổng một mình, có nghĩa là mực sẽ liên kết với tất cả các địa chỉ / giao diện trên các cổng này. Tôi sẽ thêm các quy tắc tường lửa để khóa các cổng mở này theo yêu cầu.
parkamark

Câu trả lời:


1

Tôi nhận ra điều này đã cũ và tôi không có câu trả lời đầy đủ cho bản thân mình, nhưng, tôi đang làm điều gì đó rất giống với bạn và có các triệu chứng gần như giống hệt nhau.

Đầu tiên: test-ipv6.com dường như đã tự cập nhật gần đây để có thể xử lý một loại lỗi mới (nó đã bị hỏng vào đầu năm nay). Hãy thử lại lần nữa.

Trong trường hợp của tôi, nó đã gửi cho tôi một URL mô tả một vấn đề mà tôi dường như gặp phải: Câu hỏi thường gặp về phát hiện MTU . Họ cung cấp một URL mà bạn có thể sử dụng với cURL để thực hiện kiểm tra PMTUD và sau đó bạn có thể kiểm tra lưu lượng truy cập của mình bằng cách sử dụng tpcdumphoặc wireshark.

Khi lưu lượng truy cập là TPROXY trên Squid, Phát hiện MTU đường dẫn IPv6 không hoàn toàn hoạt động trên máy chủ của bạn. (Tôi vẫn đang làm việc tại sao nó không hoạt động trên máy chủ của tôi , vì vậy tôi không có giải pháp dứt khoát).

Mô tả nhanh:

  • ICMP cực kỳ quan trọng trong IPv6. Rất nhiều người muốn chặn ICMP, và cuối cùng gây ra nhiều tác hại hơn là tốt.
  • Nếu một gói "quá lớn" cho kết nối của bạn, thì gói đó sẽ bị hủy và thông báo ICMP loại 2 ("Gói quá lớn") được gửi đến máy chủ ban đầu, yêu cầu nó giảm kích thước gói và gửi lại.
  • Nếu thông báo ICMP không gửi đến máy chủ, máy chủ sẽ tiếp tục gửi lại gói lớn - ngay lập tức bị hủy vì quá lớn.
  • Điều này đã được mô tả như là một "lỗ đen" vì các gói không bao giờ đến đích.

Vì vậy, bạn có thể muốn đảm bảo các quy tắc tường lửa của mình được đặt để chấp nhận tin nhắn ICMPv6 (xem RFC4890 để biết danh sách các loại ICMP "cần thiết").

Trong trường hợp của tôi, tôi đang cho phép tin nhắn ICMP và vẫn gặp sự cố. Tôi chưa sẵn sàng ném vào khăn và chỉ giảm MTU của mạng (đây là tùy chọn hạt nhân).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.