Mendapatkan Squid dan TPROXY dengan IPv6 bekerja pada CentOS 7

Saya mengalami masalah saat TPROXY bekerja dengan Squid dan IPv6 pada server CentOS 7. Saya sebelumnya menggunakan pengaturan penyadapan generik dengan NAT, tetapi hanya terbatas pada IPv4. Saya sekarang memperluas pengaturan untuk memasukkan IPv6 dengan TPROXY.

Saya telah menggunakan artikel wiki Squid resmi pada subjek untuk mengkonfigurasi semuanya:

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

Sejauh ini konfigurasi TPROXY tampaknya berfungsi untuk IPv4 tanpa masalah. Dengan IPv6 namun koneksi waktunya habis dan tidak berfungsi dengan benar. Saya akan memecah setup untuk pemahaman yang lebih baik.

Perhatikan bahwa semua aturan firewall dan perutean sama persis untuk IPv4, satu-satunya perbedaan adalah inet6dan ip6tablesuntuk mengkonfigurasi aturan berbasis IPv6 dalam contoh di bawah ini.

• OS dan Kernel: CentOS 7 (3.10.0-229.14.1.el7.x86_64)
• Semua paket terbaru menurut yum
• Versi Squid: 3.3.8 (Juga mencoba 3.5.9)
• Firewall: iptables / ip6tables 1.4.21
• libcap-2.22-8.el7.x86_64

Konektivitas IPv6 saat ini melalui terowongan 6in4 melalui Hurricane Electric, ini dikonfigurasi pada router DD-WRT dan kemudian awalan yang ditugaskan didelegasikan kepada klien melalui radvd. Kotak Squid memiliki beberapa alamat IPv6 statis yang dikonfigurasi.

Kotak Squid berada di dalam LAN utama yang dilayaninya. Klien yang mengalami lalu lintas pada port 80 dicegat (terutama klien nirkabel) didorong ke kotak Squid melalui router DD-WRT saya dengan firewall dan aturan perutean berikut, diadaptasi dari artikel wiki Routing Kebijakan dan wiki DD-WRT

• http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute

• http://www.dd-wrt.com/wiki/index.php/Squid_Transparent_Proxy

  ip6tables -t mangle -A PREROUTING -i "$CLIENTIFACE" -s "$PROXY_IPV6" -p tcp --dport 80 -j ACCEPT
  ip6tables -t mangle -A PREROUTING -i "$CLIENTIFACE" -p tcp --dport 80 -j MARK --set-mark $FWMARK
  ip6tables -t mangle -A PREROUTING -m mark --mark $FWMARK -j ACCEPT
  ip6tables -t filter -A FORWARD -i "$CLIENTIFACE" -o "$CLIENTIFACE" -p tcp --dport 80 -j ACCEPT
  
  ip -f inet6 rule add fwmark $FWMARK table 2
  ip -f inet6 route add default via "$PROXY_IPV6" dev "$CLIENTIFACE" table 2
  

Ini tampaknya berfungsi baik dalam hal meneruskan lalu lintas ke kotak Squid. Satu aturan tambahan yang harus saya tambahkan pada router DD-WRT di samping aturan di atas adalah aturan pengecualian untuk alamat IPv4 dan IPv6 keluar yang dikonfigurasikan pada kotak Squid, jika tidak saya mendapatkan masalah lingkaran gila dan lalu lintas rusak untuk semua klien termasuk LAN utama yang menggunakan Squid on 3128.

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

Pada kotak Squid saya kemudian menggunakan aturan perutean berikut dan rantai DIVERT untuk menangani lalu lintas yang sesuai. Saya perlu menambahkan aturan tambahan untuk mencegah kesalahan dengan rantai yang sudah ada selama pengujian. Firewall saya adalah CSF, saya telah menambahkan yang berikut kecsfpre.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 dikonfigurasi untuk dua port:

http_proxy 3128
http_proxy 3129 tproxy

Selain itu saya juga menggunakan Privoxy dan harus menambahkan no-tproxyke baris cache_peer saya, jika tidak semua lalu lintas tidak dapat diteruskan untuk kedua protokol.

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

Saya tidak menggunakan tcp_outgoing_addressarahan apa pun karena Privoxy, alih-alih saya mengendalikan alamat keluar melalui CentOS dan urutan bind.

nilai 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

Saya tidak yakin apakah rp_filtermodifikasi diperlukan karena pengaturan bekerja pada IPv4 dengan atau tanpa mereka dan menghasilkan hasil yang sama untuk IPv6.

SELINUX

SELINUX diaktifkan pada kotak Squid, tetapi kebijakan telah dikonfigurasikan untuk memungkinkan pengaturan TPROXY, sehingga tidak diblokir (IPv4 berfungsi menunjukkan hal ini). Saya telah memeriksa grep squid /var/log/audit/audit.log | audit2allow -adan menerima<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;

Saya juga telah mengatur boolean berikut:

setsebool squid_connect_any 1
setsebool squid_use_tproxy 1

Konektivitas IPv6 rusak

Pada akhirnya, konektivitas IPv6 benar-benar rusak untuk klien TPROXY (klien LAN pada port 3128yang menggunakan file WPAD / PAC memiliki IPv6 yang berfungsi penuh). Sementara tampaknya lalu lintas sedang dialihkan ke kotak Squid dalam beberapa cara, tidak ada permintaan melalui IPv6 melalui TPROXY yang muncul di kotak access.log. Semua IPv6 meminta IPv6 literal dan DNS, batas waktu. Saya dapat mengakses klien IPv6 internal tetapi sekali lagi, lalu lintas ini juga tidak masuk.

Saya melakukan beberapa pengujian menggunakan test-ipv6.com dan menemukan bahwa itu mendeteksi alamat IPv6 Squid saya yang keluar tetapi tes IPv6 menunjukkan buruk / lambat atau waktu habis. Saya sementara mengaktifkan header melalui dan menemukan header HTTP Squid terlihat, sehingga lalu lintas setidaknya sampai ke kotak Squid tetapi tidak dirutekan dengan benar setelah itu ada di sana.

Saya sudah mencoba untuk mendapatkan ini berfungsi untuk beberapa waktu dan tidak dapat menemukan apa masalahnya, saya bahkan bertanya pada milis Squid, tetapi tidak dapat mendiagnosis masalah yang sebenarnya atau menyelesaikannya. Berdasarkan pengujian saya, saya cukup yakin ini salah satu area berikut dan kotak Squid masalahnya:

• Rute
• Inti
• Firewall

Setiap ide dan langkah tambahan yang bisa saya ambil untuk membuat TPROXY dan IPv6 bekerja akan sangat dihargai!

Informasi tambahan

aturan 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

Tabel routing IPv6 (awalan dikaburkan)

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

Saya menyadari ini sudah tua, dan saya sendiri tidak memiliki jawaban penuh untuk ini, tetapi, saya melakukan sesuatu yang sangat mirip dengan Anda, dan memiliki gejala yang hampir sama.

Pertama: test-ipv6.com tampaknya telah memperbarui sendiri agak baru-baru ini untuk dapat menangani jenis kesalahan baru (itu rusak awal tahun ini). Cobalah lagi.

Dalam kasus saya, itu mengirim saya ke URL yang menjelaskan masalah yang sepertinya saya miliki: Path MTU Detection FAQ . Mereka menyediakan URL yang dapat Anda gunakan dengan CURL untuk melakukan tes PMTUD, dan kemudian Anda dapat memeriksa lalu lintas Anda menggunakan tpcdumpatau wireshark.

Ketika lalu lintas TPROXY lebih dari Squid, IPv6 Path MTU Detection tidak sepenuhnya bekerja pada host Anda. (Saya masih bekerja pada mengapa itu tidak bekerja pada host saya , jadi saya tidak punya solusi pasti).

Deskripsi singkat:

• ICMP sangat penting dalam IPv6. Banyak orang ingin memblokir ICMP, dan akhirnya menyebabkan lebih banyak kerusakan daripada kebaikan.
• Jika paket "terlalu besar" untuk koneksi Anda, paket dijatuhkan, dan pesan ICMP tipe 2 ("Paket terlalu besar") seharusnya dikirim ke server asal, memintanya untuk mengurangi ukuran paket dan mengirim ulang.
• Jika pesan ICMP tidak sampai ke server, server terus mengirim ulang paket besar - yang segera dibuang karena terlalu besar.
• Ini telah digambarkan sebagai "lubang hitam" karena paket tidak pernah mencapai tujuan mereka.

Jadi, Anda mungkin ingin memastikan aturan firewall Anda diatur untuk menerima pesan ICMPv6 (lihat RFC4890 untuk daftar jenis ICMP "diperlukan").

Dalam kasus saya, saya mengizinkan pesan ICMP, dan masih memiliki masalah. Saya tidak cukup siap untuk menyerah dan hanya mengurangi MTU jaringan saya (yang merupakan opsi nuklir).