특정 인터페이스(tum1)를 통해 사용자 트래픽 라우팅

특정 인터페이스(tum1)를 통해 사용자 트래픽 라우팅

질문: 특정 사용자에 대해 tun1을 통해 트래픽을 라우팅하는 방법은 무엇입니까?

지금까지 시도한 것: 나는 다음을 따랐습니다:

1:iptables는 모든 트래픽을 인터페이스로 전달합니다.

sudo iptables -t nat -A POSTROUTING -m owner --uid-owner user1 -j SNAT --to-source 192.168.1.1

결과: 트래픽이 tun1에 도달하지 않고 Wireshark에서 볼 수 있으며 "host google.com"은 결과를 제공하지 않습니다.

2:

sudo iptables -t nat -A POSTROUTING -m owner --uid-owner test --out-interface tun1

결과: 트래픽은 기본 경로를 통과합니다. 즉, tun1(vpn)을 거치지 않고 인터넷에 도달합니다.

추가 정보:

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
3: enx0c5b8f279a64: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 0c:5b:8f:27:9a:64 brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.100/24 brd 192.168.8.255 scope global dynamic noprefixroute enx0c5b8f279a64
       valid_lft 53043sec preferred_lft 53043sec
    inet6 fe80::5f5a:e5de:ae93:e80b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
9: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 500
    link/none 
    inet 10.0.0.1/24 scope global tun1
       valid_lft forever preferred_lft forever
    inet6 fe80::c626:a226:a66c:2b0/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
ip route list
default via 192.168.8.1 dev enx0c5b8f279a64 proto dhcp metric 100 
10.0.0.0/24 dev tun1 proto kernel scope link src 10.0.0.1 
169.254.0.0/16 dev enx0c5b8f279a64 scope link metric 1000 
192.168.8.0/24 dev enx0c5b8f279a64 proto kernel scope link src 192.168.8.100 metric 100 
linkdown

답변1

나는 dirk의 의견에 전적으로 동의합니다. 네트워크 네임스페이스를 사용하면 라우팅이 더 단순해지고 특별한 경우는 없습니다. 그러나 여기에는 Linux 커널 >= 4.10이 필요한 평소와 다른 답변이 있기를 바랍니다.

실패한 시도에 대해: POSTROUTING이름에서 알 수 있듯이 완료됨뒤쪽에라우팅 결정이 완료되었습니다. 체인은 결코 방향을 바꾸지 않습니다. 무엇을 위해 사용해야 합니까?지역적으로 시작된트래픽은 mangle/OUTPUT(nftables의 특수 체인 type route hook output)입니다. 그런 다음 마커를 사용하여 라우팅 스택과 상호 작용하고 엣지 케이스를 수정해야 합니다.CONNMARK그리고 MARK그것을 작동시키는 것은 여전히 ​​​​어렵습니다.

아무튼 방법이 있어요아니요2016년에 등장한 iptables네트워크 라우팅 스택 기능 활용uidrange커널 4.10:

UID별 라우팅에 대한 지원을 추가합니다. 이를 통해 관리자는 다음과 같은 규칙을 구성할 수 있습니다
# ip rule add uidrange 100-200 lookup 123. 모든 Android 기기는 5.0부터 이 기능을 사용하고 있습니다. 주로 앱별 라우팅 정책을 구현하는 데 사용됩니다(Android에서는 각 앱마다 고유한 UID가 있음).iptables에서 패킷을 다시 라우팅할 필요가 없습니다., 이는 getsockname() 및 MTU/MSS 계산을 중단하고 일반적으로 종단 간 연결을 중단합니다.범죄, 범죄,범죄

라우팅 스택이 즉시 올바른 경로와 일치하는 소스 IP를 선택하므로 SNAT이 IP는 필요하지 않습니다. 여전히 작은 "더러운" 부분이 있습니다.역방향 경로 필터가 느슨함~에투엔대상 사용자가 다른 사용자와 다른 라우팅 테이블을 가져오더라도 해당 인터페이스의 반환 트래픽은 어떤 사용자에게도 속하지 않으므로 해당 라우팅 테이블을 사용하지 않기 때문입니다.

이 예에서는사용자 1UID는 1234가 되며 임의로 선택한 테이블 1001234가 대체 경로로 사용됩니다.

해당 기본 경로를 테이블 1001234에 복사/변경하고 경로를 완화합니다. 이러한 경로와 설정은 인터페이스가 사라지거나 종료되면 손실되므로 터널이 다시 설정될 때마다 다시 추가해야 합니다.

ip route add table 1001234 10.0.0.0/24 dev tun1 src 10.0.0.1
ip route add table 1001234 default dev tun1 #no need of a gateway on a layer 3 interface
sysctl -w net.ipv4.conf.tun1.rp_filter=2

이 작업은 한 번만 수행하면 되며 사용자에게 즉시 영향을 미칩니다.

ip rule add uidrange 1234-1234 lookup 1001234

NAT 규칙 을 추가하지 마세요 iptables. 물론 적절한 방화벽 규칙은 여전히 ​​필요합니다. 사용자가 로컬 서비스(예: 127.0.0.1:53에서 사용 가능한 로컬 DNS 캐시 데몬)를 쿼리하는 경우 데몬의 UID가 다르기 때문에 데몬이 실행한 쿼리는 터널을 사용하지 않습니다.

관련 정보