Support chaining of mocks

[bobpaul]

If there's duplicate arguments (such as -m provided more than once) the argument parser currently uses the last argument provided without warning or error that the previous definition is ignored.

This cause me to think that multiple mocks were supported in a chain with priority order. They're not. But why not?

Currently it's possible to do:

$ #on client
$ ./tunnel -en -l tcp:localhost:11111 -r tcp:localhost:10080 -m socks5:server.example.com:1080 &
$ ./tunnel -l udp:localhost:51820 -r tcp:localhost:11111 -m http_ws_client

$ #on server, same machine as sock5 proxy server
$ ./tunnel -en -l tcp:localhost:10080 -r udp:localhost:51820 -m http_ws_server

which makes a chain:

   flowchart TD
   wireguard --udp--> 
   tunnel_1{{websocket wrapper}} --tcp+http_ws-->
   tunnel_2{{socks5 connector}} --tcp+socks5-->
   socks[socks server] --tcp+http_ws-->
   tunnel_3{{remote websocket server}} --udp-->
   wireguard_server

Loading

But if chaining of mocks was supported, one could avoid running ./tunnel twice on the client system. This should also cause fewer transitions in/out of kernel space

$ #on client
$ ./tunnel -l udp:localhost:51820 -r tcp:localhost:10080 -m http_ws_client -m socks5:server.example.com:1080  

$ #on server, same machine as sock5 proxy server
$ ./tunnel -en -l tcp:localhost:10080 -r udp:localhost:51820 -m http_ws_server

   flowchart TD
   wireguard --udp--> 
   tunnel_1{{websocket wrapper,
via socks5}} --socks5-->
   socks[socks server] --http_ws-->
   tunnel_3{{remote websocket server}} --udp-->
   wireguard_server

Loading

Order of mocks

I think there's a natural ordering of what makes sense, and this order could be used regardless of the order of things on the commandline.

   flowchart TD
     udp_in[udp] --> data
     dtls_in[dtls] --> data
     tcp_in[tcp] --> data
     tls_in[tls] --> data
     icmp_in[icmp] --> data
     icmp6_in[icmp6] --> data
     
     udp_in --> dns_in
     dtls_in --> dns_in
     tcp_in --> dns_in
     tls_in --> dns_in
     
     tcp_in --> http_ws_in
     tls_in --> http_ws_in
     
     http_ws_in{{http_ws}} --> data
     dns_in{{dns}} --> data
   
     data --> dns_r{dns}
     data --> http_ws_r{http_ws}
     data --> udp_r[udp]
     data --> dtls_r[dtls]
     data --> tcp_r[tcp]
     data --> tls_r[tls]
     data --> icmp_r[icmp]
     data --> icmp6_r[icmp]
   
     dns_r --> tcp_r
     dns_r --> tls_r
     dns_r --> udp_r
     dns_r --> dtls_r
   
     http_ws_r --> tcp_r
     http_ws_r --> tls_r
   
     tcp_r --> socks5
     tls_r --> socks5{{socks5}}

Loading

Alternatively, argument ordering could be used to specify the order of the pipeline, such as putting socks5 inside of a https_ws_client