Currently SecureComms supports opening tunnels between PP host and WN host.
This includes:
A client at the PP host can open a connection locally (127.0.0.1: serving as an inbound). The connection will be tunneled via the SecureComms SSH channel to the WN host (serving as outbound) and from there to a any service with IP addressable from the WN host.
A client at the WN host can open a connection locally (127.0.0.1: serving as an inbound). The connection will be tunneled via the SecureComms SSH channel to the PP host (serving as outbound) and from there to a any service with IP addressable from the PP host.
The proposed feature adds support for network namespace for inbounds such that in addition to the above we will support:
A client at at any network namespace of the PP host can open a connection locally (127.0.0.1: on that network namespace, serving as an inbound). The connection will be tunneled via the SecureComms SSH channel to the WN host (serving as outbound) and from there to a any service with IP addressable from the WN host.
A client at any network namespace of the WN host can open a connection locally (127.0.0.1: on that network namespace, serving as an inbound). The connection will be tunneled via the SecureComms SSH channel to the PP host (serving as outbound) and from there to a any service with IP addressable from the PP host.
The main use case is to allow opening tunnels from the podns network namespace in the PP. This will allow offering specific remote services to clients located at pod containers and exposing such services locally - i.e. at 127.0.0.1: on the podns network namespace. The container will be able to use a client and approach a local service which will be tunneled via the SecureComms SSH channel to the WN host from there it will be forwarded to any service that the WN can address.
The below diagram shows the relationship between the
Tunnel Inbound ====TUNNEL==== Tunnel Outbound
Client------------>Local Service Client------------->Remote Service
Container in Pod Pod Network WN Host Some URL
(`podns`)
davidhadas
commented
1 month ago
Currently SecureComms supports opening tunnels between PP host and WN host. This includes:
A client at the PP host can open a connection locally (127.0.0.1: serving as an inbound). The connection will be tunneled via the SecureComms SSH channel to the WN host (serving as outbound) and from there to a any service with IP addressable from the WN host.
A client at the WN host can open a connection locally (127.0.0.1: serving as an inbound). The connection will be tunneled via the SecureComms SSH channel to the PP host (serving as outbound) and from there to a any service with IP addressable from the PP host.
The proposed feature adds support for network namespace for inbounds such that in addition to the above we will support:
A client at at any network namespace of the PP host can open a connection locally (127.0.0.1: on that network namespace, serving as an inbound). The connection will be tunneled via the SecureComms SSH channel to the WN host (serving as outbound) and from there to a any service with IP addressable from the WN host.
A client at any network namespace of the WN host can open a connection locally (127.0.0.1: on that network namespace, serving as an inbound). The connection will be tunneled via the SecureComms SSH channel to the PP host (serving as outbound) and from there to a any service with IP addressable from the PP host.
The main use case is to allow opening tunnels from the on the
podnsnetwork namespace in the PP. This will allow offering specific remote services to clients located at pod containers and exposing such services locally - i.e. at 127.0.0.1:podnsnetwork namespace. The container will be able to use a client and approach a local service which will be tunneled via the SecureComms SSH channel to the WN host from there it will be forwarded to any service that the WN can address.The below diagram shows the relationship between the