Apply NAT to headers/packets carried within ICMP messages

[FelixMcFelix]

This PR modifies nested packets in ICMP payloads to ensure that private source/destination addresses are replaced with the correct external IP. This makes use of a body transform to modify the packet contents, which has the downside of downgrading NAT'd ICMP packets to the less-fast-path. Note that this is not performance-critical traffic, and these frames are still taking a read lock over the port at worst.

There's a bit of trouble passing the full header stack back into these body transforms -- we have an arbitrary T which can be treated as a byteslice, but our dyn BodyTransforms presumably need to be monomorphised. We need to hand at least some knowledge of the parsed headers over, such that we only attempt this transform on the right ICMP types. For now, we achieve this by passing in a reference to the owned version of the inner ULP header.

Fixes #369.

[rcgoodfellow]

Taking this for a spin in a local omicron environment, we can run traceroute from within instances now!

debian@test:~$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.736 ms  0.913 ms  1.306 ms
 2  Docsis-Gateway (10.1.10.1)  1.790 ms  2.009 ms  2.128 ms
 3  100.92.143.3 (100.92.143.3)  15.978 ms 100.92.143.2 (100.92.143.2)  16.272 ms 100.92.143.3 (100.92.143.3)  16.682 ms
 4  po-305-315-rur201.scotts.ca.sfba.comcast.net (96.216.154.217)  15.620 ms  15.752 ms  15.439 ms
 5  po-200-xar01.scotts.ca.sfba.comcast.net (68.85.86.101)  16.404 ms po-2-rur201.scotts.ca.sfba.comcast.net (68.86.143.17)  25.289 ms  25.743 ms
 6  po-200-xar01.scotts.ca.sfba.comcast.net (68.85.86.101)  25.573 ms  21.897 ms  18.974 ms
 7  po-2-xar02.scotts.ca.sfba.comcast.net (68.87.193.74)  19.809 ms  20.331 ms  20.144 ms
 8  be-39921-cs02.9greatoaks.ca.ibone.comcast.net (68.86.93.245)  22.547 ms be-39931-cs03.9greatoaks.ca.ibone.comcast.net (68.86.93.249)  13.838 ms be-39911-cs01.9greatoaks.ca.ibone.comcast.net (68.86.93.241)  22.735 ms
 9  be-2112-pe12.losangeles.ca.ibone.comcast.net (96.110.33.18)  29.595 ms be-2312-pe12.losangeles.ca.ibone.comcast.net (96.110.33.26)  28.003 ms  27.813 ms
10  be-2212-pe12.losangeles.ca.ibone.comcast.net (96.110.33.22)  27.180 ms be-2412-pe12.losangeles.ca.ibone.comcast.net (96.110.33.30)  27.613 ms  27.449 ms
11  * 141.101.72.34 (141.101.72.34)  27.220 ms *
12  one.one.one.one (1.1.1.1)  37.045 ms 141.101.72.31 (141.101.72.31)  36.710 ms one.one.one.one (1.1.1.1)  36.841 ms

[rcgoodfellow]

Traceroute from outside the rack going in also works.

$ traceroute -nI 192.168.20.33
traceroute to 192.168.20.33 (192.168.20.33), 64 hops max, 48 byte packets
 1  192.168.1.1  3.725 ms  3.001 ms  2.773 ms
 2  192.168.20.33  3.139 ms  2.985 ms  2.724 ms

[rcgoodfellow]

LGTM. It looks like the CI issues are just that we need a new lab image?

[FelixMcFelix]

Thanks for the review Ry, great to see that traceroute now works as intended.

LGTM. It looks like the CI issues are just that we need a new lab image?

Yep, I have oxidecomputer/meta#654 open for this.