☰

특정 인터페이스를 통해 특정 포트의 트래픽을 라우팅하시겠습니까?

tag-icon • tag-icon networking iptables routing openvpn route
특정 인터페이스를 통해 특정 포트의 트래픽을 라우팅하시겠습니까?

현재 실행 중인 시스템은 HTTP 및 HTTPS 트래픽을 직접 보내고 받을 수 있어야 하지만, 다른 모든 트래픽은 VPN을 통과해야 합니다.

내 설정은 다음과 같습니다

x2 인터페이스: eth0(로컬 네트워크, 라우터 뒤) 및 tun0(openvpn 클라이언트)

현재 모든 트래픽은 VPN을 통해 라우팅됩니다. 가능한지 알고 싶습니다.아니요VPN을 통해 http 및 https 트래픽(80, 443)을 라우팅합니다.

이것은 시스템과 openvpn 클라이언트가 시작될 때의 라우팅 테이블입니다.

0.0.0.0/1 via 10.8.13.5 dev tun0 
default via 192.168.1.1 dev eth0 
10.8.13.1 via 10.8.13.5 dev tun0 
10.8.13.5 dev tun0 proto kernel scope link src 10.8.13.6 
128.0.0.0/1 via 10.8.13.5 dev tun0 
176.67.168.144 via 192.168.1.1 dev eth0 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.56 
192.168.1.1 dev eth0 scope link

다른 유사한 질문을 읽었지만 답변은 트래픽을 다시 라우팅하지 않거나 차단하는 것뿐입니다.

미리 감사드립니다 :)

답변1

라우팅은 IP 계층 3에 있습니다. TCP는 레이어 4에 있으므로 라우팅만으로는 이 문제를 해결하기에 충분하지 않습니다.

즉, 흥미로운 트래픽이 있어야 합니다.다음으로 표시iptables, 선택한 패킷에 태그를 지정합니다.ip rulefwmark별도의 라우팅 테이블을 사용하세요 . 그런 다음 로컬 원본/수신 트래픽 사례에 두 가지 추가 수정 사항을 적용해야 하는데 이는 라우팅 사례보다 어렵습니다. 물론 모든 설정은 로컬 시스템에서 수행됩니다.

라우팅 테이블 80(일치하는 기호 이름을 추가할 수 있지만 /etc/iproute2/rt_tables필수는 아님) 및 태그는 0x80"임의로" 선택됩니다.

ip route add table 80 192.168.1.0/24 dev eth0 scope link src 192.168.1.56
ip route add table 80 default dev eth0 via 192.168.1.1

-Iiptables 규칙이 너무 늦게 연결되지 않았는지 확인하는 데 사용됩니다 . 현재 규칙에 따라 필요한 경우 재정렬 방법을 확인해야 합니다.

iptables -t mangle -N markports
iptables -t mangle -I PREROUTING 1 -j CONNMARK --restore-mark
iptables -t mangle -I OUTPUT 1 -m mark --mark 0 -j markports
iptables -t mangle -I OUTPUT 2 -j CONNMARK --save-mark
iptables -t mangle -A markports -p tcp --dport 80 -j MARK --set-mark 0x80
iptables -t mangle -A markports -p tcp --dport 443 -j MARK --set-mark 0x80

ip rule add fwmark 0x80 lookup 80

이 블로그:Netfilter Connmark » Linux 이상!에 대한 좋은 정보를 제공하세요 CONNMARK.

이는 작동하지만 실제로는 경로가 통과하려고 할 때 첫 번째 라우팅 결정에서 잘못된 기본 발신 IP를 선택합니다 tun0. 태그로 인한 수표 경로 재지정 mangle/OUTPUT(이 내용 참조)일반 네트워크 다이어그램의 Netfilter 및 패킷 흐름명확히 하기 위해) 이 IP는 변경되지 않습니다. 처리 중인 트래픽이 로컬로 시작되지 않고 라우팅되는 경우에는 이 문제가 발생하지 않습니다. 서비스인지 확인하기 위해 별도의 네트워크 네임스페이스를 사용하는 솔루션은 데스크톱에서 작동하지 않을 수 있습니다. 따라서 이를 위해서는 그 위에 하나의 레이어가 필요합니다 MASQUERADE(또는 더 복잡한 경우).SNAT

iptables -t nat -I POSTROUTING 1 -m mark --mark 0x80 -j MASQUERADE

이제 나가는 소스 IP는 정확하지만 여전히 작동하지 않습니다.역방향 경로 필터거의 같은 이유로 반환 경로에서 발생합니다. 이전에 내린 라우팅 결정은 당분간 PREROUTING알려지지 않았습니다 fwmark(비록이전 회로도mangle/PREROUTING이는 분명히 그렇지 않은 라우팅 결정 이전에 배치되므로 반환 트래픽 패킷이 스푸핑된 것으로 간주하여 조기에 삭제합니다. eth0인터페이스rp_filter이를 허용하려면 느슨한 모드로 설정해야 합니다. 이로 인해 NAT 뒤에 몇 가지 (매우 사소한) 보안 문제가 발생할 수 있지만 라우팅되지 않은 경우에는 피할 수 없습니다.

echo 2 > /proc/sys/net/ipv4/conf/eth0/rp_filter

영구적으로 설정하는 방법을 찾아야 합니다(예: echo net.ipv4.conf.eth0.rp_filter=2 > /etc/sysctl.d/90-local-loose-mode.conf나중에 아무것도 변경하지 않는 경우).

OP와 유사한 설정으로 네임스페이스를 사용하여 테스트한 결과는 괜찮았습니다.

참고: DNS 요청은 계속해서 터널을 통과합니다. 일부 지역화된 웹 서비스는 예상대로 작동하지 않을 수 있습니다.

관련 정보