The proxy doesn't seem to have a way to tell if the application is trying to make an IPv4 or an IPv6 connection (unless the remote endpoint is an explicit IPv4 or IPv6 address). Am I missing something there, or is that in fact how it's intended to be?
NEAppProxyFlow and IPv4 vs IPv6
In some sense, this is a dumb question, since the AppProxyFlow is a bridge between endpoints, not an actual IP tunnel; however, this surprised me in the sense that if an app asks what the remote connection is, or asks for a specific address family, etc. But I’m guessing that the app proxy only works with the higher-level libraries, and not with the BSD layer?
Or of course I’m completely wrong!
The proxy doesn't seem to have a way to tell if the application is trying to make an IPv4 or an IPv6 connection
Right, NEAppProxyFlow
will not give the address family information as is. On macOS 11, you can attempt to derive this information based on the remoteHostname
, for example:
if let hostname = flow.remoteHostname,
let ipv4Addr = IPv4Address(hostname) {
// ...
}
Or if your are working with a NEAppProxyTCPFlow
you can attempt to derive the address family based on the remoteEndpoint
:
// NEAppProxyTCPFlow
if let ipAddr = flow.remoteEndpoint as? Network.NWEndpoint {
// Derive IPv4Address or IPv6Address here
}
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
But, essentially, it's not supposed to matter, right? As I just described it to someone, the App Proxy Provider turns the data transport from IP to itself (ok, it sounded better in my head before I said it). You could, I suppose, use it to implement some wildly-different transport scheme that did not involve any IP packets at all.
I just wanted to make sure I did understand it properly. 😄
Using NEAppProxyFlow
is not packet based, a flow is a bidirectional stream of data. A TCP flow represents a TCP connection. A UDP flow represents a sequence of incoming and outgoing datagrams you can identify based on a local IP address and port and a remote IP address and port.
You can use your flows to create a custom transport that sits on tops of either your TCP flow or UDP flow, but this is something that needs to be built and defined by your app.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
You're saying I'm right, but you think I'm using the wrong words (which is likely true), so you're being more precise.
That's how I read it, anyway.