질문: 특정 사용자에 대해 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가 다르기 때문에 데몬이 실행한 쿼리는 터널을 사용하지 않습니다.