GTP Tunnel Mapping via nftables » History » Version 3
laforge, 12/06/2022 01:59 PM
1 | 1 | laforge | h1. GTP Tunnel Mapping via nftables |
---|---|---|---|
2 | |||
3 | the idea here is that we map one GTP tunnel to another GTP tunnel by doing IP address + TEID rewrite inside the kernel via nftables. |
||
4 | |||
5 | 2 | laforge | h2. Notes |
6 | |||
7 | * we are treating the UPF tunnel-maping use case as a special case of an _IP router_, which forwards packets between network interfaces. For this to work, _IP forwarding_ must be enabled, just like on any Linux based router. |
||
8 | * the routing decision is made based on the new/rewritten packet. So your IP routing tables must be set up in a way that the packet after transformation can be routed to its destination. |
||
9 | |||
10 | 1 | laforge | h2. How the ruleset works |
11 | |||
12 | The ruleset for a @tunmap@ use case looks like this: |
||
13 | |||
14 | <pre> |
||
15 | table inet asdf { |
||
16 | chain tunmap1 { |
||
17 | type filter hook prerouting priority raw; policy accept; |
||
18 | meta l4proto udp ip daddr 127.0.1.2 @ih,32,32 0x1 ip saddr set 127.0.2.2 ip daddr set 127.0.0.3 @ih,32,32 set 0x7fe80002 counter; |
||
19 | meta l4proto udp ip daddr 127.0.2.2 @ih,32,32 0x2 ip saddr set 127.0.1.2 ip daddr set 127.0.0.2 @ih,32,32 set 0x7fe80001 counter; |
||
20 | } |
||
21 | } |
||
22 | 3 | laforge | |
23 | note there are two rules for each GTP tunnel: One for each direction/flow. |
||
24 | |||
25 | 1 | laforge | </pre> |
26 | |||
27 | h4. defining the chain |
||
28 | |||
29 | <pre> |
||
30 | chain tunmap1 { |
||
31 | type filter hook prerouting priority raw; policy accept; |
||
32 | </pre> |
||
33 | |||
34 | this defines a chain (list of rules) attached to the _prerouting_ netfilter hook. If no rule hits, the packet shall simply be accepted (passed on unmodified). |
||
35 | |||
36 | _prerouting_ happens to all incoming packets before the routing decision (see "Netfilter hooks":https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks). This means the actual routing of the packet is done based on the packet _after_ the transformation rules have been applied. |
||
37 | |||
38 | h3. a single rule |
||
39 | |||
40 | One rule specifies the transformation to GTP packets in one direction. |
||
41 | |||
42 | <pre> |
||
43 | meta l4proto udp ip daddr 127.0.1.2 @ih,32,32 0x1 ip saddr set 127.0.2.2 ip daddr set 127.0.0.3 @ih,32,32 set 0x7fe80002 counter; |
||
44 | </pre> |
||
45 | |||
46 | Explanation of that rule: |
||
47 | |||
48 | * @meta l4proto udp@ matches on UDP packets |
||
49 | * @ip daddr 127.0.1.2@ matches packets with the stated destination IP address |
||
50 | * @@ih,32,32 0x1@ matches packet who contain the 32-bit value 0x00000001 32-bits _after_ the L4 (UDP) header |
||
51 | ** this matches the TEID in the GTP header, as it is a 32bit value 4 bytes after the start of the GTP header |
||
52 | * @ip saddr set 127.0.2.2@ changes the destination address to the given address |
||
53 | * @ip daddr set 127.0.0.3@ changes the destination address to the given address |
||
54 | * @@ih,32,32 set 0x7fe80002@ changes the 32-bit value 32-bits after the L4 (UDP) header to 0x7fe80002 |
||
55 | ** this overewrites the TEID inside the GTP header |
||
56 | * @counter@ adds a counter to the rule so we can see hof often it has been used (how many packets have matched it) |