Allow passing explicit flags for --net

[syrusakbary]

We should allow having things like:

wasmer run xyz --net DOMAIN,IP,IP-RANGE,IP-PORT

Example:

wasmer run xyz --net=xyz.com,1.2.3.4,1.2.3.4/20,1.2.3.4:80,1.2.3.4/20:80

Note:

• Domains:
  • xyz.com is a valid domain
  • abc.xyz.com is a valid domain
  • *.xyz.com is a valid domain
• IP:
  • 1.2.3.4 is a valid one (single ip)
  • 1.2.3.4/20 is a valid one (ip range)
  • 1.2.3.4/20:80 is a valid one (ip range, one port)
  • 1.2.3.4:80 is a valid one (single ip, single port)
  • 1.2.3.4:80-100 is a valid one (single ip, port range)
  • 1.2.3.4:* is a valid one (single ip, any port)
  • *:80 is a valid one (any ip, port 80)
  • : is a valid one (any ip, any port)
  • *:80-1000 (port range)

[TheNicholasNick]

when doing these

• *:80 is a valid one (any ip, port 80)
• : is a valid one (any ip, any port)
• *:80-1000 (port range)

may need to be explicit with both ipv4 & ipv6 bindings - it's frustrating as a user and the OS doesn't do the expected thing and expose the port on both stacks and only does the ipv6 stack...

It's next level accepting domains, does that open up to unintended consequences though?

[syrusakbary]

Good point, we should accept IPv6 as well (not only IPv4)

[ibuildthecloud]

For my primary use case I want to reject RFC1918. Which would actually be a deny list, not an accept list. I think there's valid use cases for both. For example, if I was doing domain level filtering, an accept list would be perfect.

[ibuildthecloud]

At what layer would domain filtering happen. For example, I would not expect wasmer to ever to do reverse DNS that would reject an IP because example.com resolves to that IP.