CentOS 7에서 작동하는 IPv6으로 오징어와 TPROXY 얻기


18

CentOS 7 서버에서 TPROXY가 Squid 및 IPv6과 함께 작동하는 데 문제가 있습니다. 이전에는 NAT와 함께 일반 인터셉트 설정을 사용하고 있었지만 IPv4로만 제한되었습니다. 이제 TPROXY에 IPv6을 포함하도록 설정을 확장하고 있습니다.

나는 주제에 관한 공식 오징어 위키 기사를 사용하여 모든 것을 구성했습니다.

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

지금까지 TPROXY 구성은 문제없이 IPv4에서 작동하는 것으로 보입니다. 그러나 IPv6을 사용하면 연결 시간이 초과되어 제대로 작동하지 않습니다. 이해를 돕기 위해 설정을 분석하겠습니다.

모든 방화벽을 참고 라우팅 규칙을 정확히 IPv4의 동일, 유일한 차이 inet6ip6tables아래의 예에서 IPv6 기반 규칙을 구성.

  • OS 및 커널 : CentOS 7 (3.10.0-229.14.1.el7.x86_64)
  • 모든 패키지는 yum에 따라 최신 상태입니다.
  • 오징어 버전 : 3.3.8 (3.5.9도 시도)
  • 방화벽 : iptables / ip6tables 1.4.21
  • libcap-2.22-8.el7.x86_64

IPv6 연결은 현재 허리케인 일렉트릭을 ​​통한 6in4 터널을 통해 이루어지며 DD-WRT 라우터에서 구성되고 지정된 접두사가을 통해 클라이언트에 위임됩니다 radvd. 오징어 상자에는 여러 개의 고정 IPv6 주소가 구성되어 있습니다.

오징어 상자는 서비스를 제공하는 기본 LAN 내에 있습니다. 포트 80에서 트래픽이 차단 된 클라이언트 (주로 무선 클라이언트)는 다음 방화벽 및 라우팅 규칙이있는 DD-WRT 라우터를 통해 Squid 상자로 푸시됩니다. 정책 라우팅 위키 기사 및 DD-WRT 위키

트래픽을 오징어 상자로 전달한다는 점에서 정상 작동하는 것으로 보입니다. 위의 것 외에도 DD-WRT 라우터에 추가해야 할 하나의 규칙은 오징어 상자에 구성된 발신 IPv4 및 IPv6 주소에 대한 예외 규칙이었습니다. 그렇지 않으면 미친 루프 문제가 발생하여 트래픽을 포함한 모든 클라이언트의 트래픽이 중단됩니다 Squid on을 사용하는 기본 LAN 3128.

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

오징어 상자에서 다음 라우팅 규칙과 DIVERT 체인을 사용하여 트래픽을 적절히 처리합니다. 테스트 중에 이미 존재하는 체인의 오류를 방지하기 위해 규칙을 추가해야했습니다. 내 방화벽은 CSF에 다음을 추가했습니다.csfpre.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 두 개의 포트로 구성되어 있습니다.

http_proxy 3128
http_proxy 3129 tproxy

또한 Privoxy를 사용하고 있으며 no-tproxycache_peer 행 에 추가 해야했습니다. 그렇지 않으면 두 프로토콜 모두에 대해 모든 트래픽을 전달할 수 없습니다.

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

tcp_outgoing_addressPrivoxy 때문에 지시문을 사용하지 않고 CentOS 및 바인드 순서를 통해 아웃 바운드 주소를 제어하고 있습니다.

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

rp_filter설정이 있거나없는 IPv4에서 설정이 작동하고 IPv6에 대해 동일한 결과를 생성하므로 수정이 필요한지 확실하지 않습니다 .

셀 리눅스

SELINUX는 Squid 상자에서 활성화되어 있지만 TPROXY 설정을 허용하도록 정책이 구성되어 있으므로 차단되지 않습니다 (IPv4 작동에 표시됨). 확인 grep squid /var/log/audit/audit.log | audit2allow -a하고 얻었습니다.<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;

또한 다음 부울을 설정했습니다.

setsebool squid_connect_any 1
setsebool squid_use_tproxy 1

IPv6 연결 끊김

궁극적으로 TPROXY 클라이언트에 대한 IPv6 연결이 완전히 끊어졌습니다 ( 3128WPAD / PAC 파일을 사용하는 포트의 LAN 클라이언트는 IPv6가 완전히 작동합니다). 트래픽이 어떤 방식으로 오징어 상자로 라우팅되고있는 것처럼 보이지만 TPROXY를 통한 IPv6을 통한 요청은에 나타나지 않습니다 access.log. 모든 IPv6는 리터럴 IPv6 및 DNS를 모두 요청합니다 (시간 종료). 내부 IPv6 클라이언트에 액세스 할 수 있지만이 트래픽도 기록되지 않습니다.

test-ipv6.com을 사용하여 몇 가지 테스트를 수행 한 결과 나가는 Squid IPv6 주소가 감지되었지만 IPv6 테스트는 불량 / 느린 속도 또는 시간 초과로 표시됩니다. via 헤더를 일시적으로 활성화하고 Squid HTTP 헤더가 표시되어 트래픽이 적어도 오징어 상자에 도착했지만 일단 오징어 상자에 제대로 라우팅되지 않았습니다.

나는 이것을 잠시 동안 작동 시키려고 노력했지만 문제가 무엇인지 찾을 수 없었습니다. 오징어 메일 링리스트에 요청했지만 실제 문제를 진단하거나 해결할 수는 없었습니다. 내 테스트를 바탕으로 다음 영역 중 하나와 오징어 상자에 문제가 있다고 확신합니다.

  • 라우팅
  • 핵심
  • 방화벽

TPROXY 및 IPv6 작업을 수행하기 위해 취할 수있는 아이디어와 추가 단계는 대단히 감사하겠습니다!

추가 정보

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

IPv6 라우팅 테이블 (접두사 가림)

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

버그 / 릴리스 문제를 배제하기 위해 Squid (3.5)의 이후 릴리스로 업데이트하려고했지만 문제가 남아 있습니다.
제임스 화이트

1
방금 1 년 전에 CentOS 6 상자 에서이 작업을 수행했다고 말합니다. 그러나 커널 업데이트 후 하루 만에 갑자기 작동이 멈추었고 그 이후로는 작동하지 않았습니다. IPv6 TPROXY 설정을 활성화하면 기본적으로 모든 포트 80 트래픽을 차단하고 오징어에 도달하지 않습니다. 나는 잠시 포기했다. 현재 실행중인 커널은 2.6.32입니다 -wiki.squid-cache.org/Features/Tproxy4 에는 2.6.37의 최소 커널 버전이 나열되어 있으므로 이미 부족합니다. 내가 그것을 고소하면, 내가 찾은 결과로 여기를 업데이트 할 것입니다.
parkamark

그래서 마침내이 일을했습니다. 문제는 squid.conf의 IPv6 "tproxy"포트와 동일한 IPv4 "절편"포트를 사용하는 것이 었습니다. 자세한 내용은 설명서에 나와 있지만이 포트를 수신하고 있기 때문에이 작업을 수행하지 않으면 해결할 수 있다고 생각했습니다. 포트와 함께 특정 주소 / 스택이 있으므로 충돌해야하는 특별한 이유가 없습니다. 글쎄, 이것은 잘못된 추정으로 보인다. ... 읽기
parkamark

squid.conf에서 "http_port 192.168.0.1:3128 인터셉트"및 "http_port [fd00 :: 2] : 3128 tproxy"를 정의했습니다.이 작업을 수행하지 마십시오! 단순히 "http_port 3128 인터셉트"및 "http_port 3129 tproxy"여야합니다. IPv6 프록시 포트를 특정 IPv6 주소에 바인딩 한 다음 모든 방화벽 / 라우팅 마법이 작동 할 것으로 기대할 수 없습니다. 포트만 지정할 수 있습니다. 즉, 오징어는 이러한 포트의 모든 주소 / 인터페이스에 바인딩됩니다. 필요에 따라 이러한 열린 포트를 잠그기 위해 방화벽 규칙을 추가하겠습니다.
parkamark

답변:


1

나는 이것이 오래되었다는 것을 알고 있으며, 이것에 대한 완전한 대답은 없지만, 나는 당신과 매우 비슷한 것을하고 있으며 거의 ​​동일한 증상을 가지고 있습니다.

첫째 : test-ipv6.com이 새로운 유형의 오류를 처리 할 수 ​​있도록 최근에 다소 업데이트 된 것으로 보입니다 (올해 초 고장났습니다). 다시 시험 해봐

내 경우에는 내가 가진 것 같은 문제를 설명하는 URL로 나를 보냈습니다 : Path MTU Detection FAQ . cURL과 함께 사용하여 PMTUD 테스트를 수행 할 수있는 URL을 제공 한 다음 tpcdump또는 wireshark를 사용하여 트래픽을 확인할 수 있습니다 .

트래픽이 오징어를 통해 TPROXY 된 경우 IPv6 경로 MTU 감지가 호스트에서 완전히 작동하지 않습니다. (이 작동하지 왜 나는 아직도 일하고 있어요 호스트 내가 명확한 해결책이 없다, 그래서).

빠른 설명 :

  • ICMP는 IPv6에서 매우 중요합니다. 많은 사람들이 ICMP를 차단하고 결국 좋은 것보다 더 많은 해를 입히고 싶어합니다.
  • 연결에 "너무 큰"패킷이 있으면 패킷이 삭제되고 ICMP 유형 2 ( "Packet too large") 메시지가 원래 서버로 전송되어 패킷 크기를 줄이고 다시 보내도록 요청합니다.
  • ICMP 메시지가 서버에 전달되지 않으면 서버는 큰 패킷을 계속 재전송합니다. 너무 큰 패킷은 즉시 삭제됩니다.
  • 이은으로 기술되었다 "블랙홀" 패킷이 목적지에 도달하지 않기 때문에.

따라서 방화벽 규칙이 ICMPv6 메시지를 수락하도록 설정되어 있는지 확인하고 싶을 수 있습니다 ( "필요한"ICMP 유형 목록은 RFC4890 참조).

제 경우에는 ICMP 메시지를 허용하는데 여전히 문제가 있습니다. 나는 수건에 넣을 준비가되어 있지 않고 네트워크의 MTU (핵 옵션)를 줄입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.