aherman
/
boundary
mirror of https://github.com/hashicorp/boundary
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update multi-hop system-requirements.mdx (#3530)

Browse Source 
* Update multi-hop system-requirements.mdx

Clarifying multi-hop session proxying wording

* docs: Rewrite as list

* Update list to clarify connection steps, multiple upstreams possible per downstream/egress

* docs: Copy edits

* docs: Fix formatting in ordered list

---------

Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
Co-authored-by: Joe Thompson <jthompson@hashicorp.com>
pull/3554/head
PPacent 3 years ago committed by GitHub
parent be8e9fc61c
commit 6a564ae409
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 7 deletions
Show Stats Download Patch File Download Diff File

23
website/content/docs/install-boundary/system-requirements.mdx
Unescape View File

@ -100,16 +100,25 @@ If any of the default port mappings below do not meet your organization's requir
| Load balancer | Controller servers | 9203 | tcp | Health checks |
| Worker servers | Controller load balancer | 9201 | tcp | Session authorization, credentials, etc |
| Controllers | Postgres | 5432 | tcp | Storing system state |
| Client machines | Worker servers \* | 9202 | tcp | Session proxing |
| Worker servers | Boundary targets\* | various | tcp | Session proxing |
| Client machines | Ingress worker servers \*\* | 9202 | tcp | Multi-hop session proxing |
| Egress workers | Ingress worker servers \*\* | 9202 | tcp | Multi-hop session proxing |
| Egress workers | Boundary targets \*\* | various | tcp | Multi-hop session proxing |
| Client machines | Worker servers \* | 9202 | tcp | Session proxying |
| Worker servers | Boundary targets\* | various | tcp | Session proxying |
| Client machines | Ingress worker servers \*\* | 9202 | tcp | Multi-hop session proxying |
| Egress workers | Ingress worker servers \*\* | 9202 | tcp | Multi-hop session proxying |
| Egress workers | Boundary targets \*\* | various | tcp | Multi-hop session proxying |
\* In this scenario, the client connects directly to one worker, which then proxies the connection to the Boundary target.
** In this scenario, the client connects to an ingress worker, then the ingress worker connects to a downstream egress worker, then the downstream egress worker connects to the Boundary target.
Ingress and egress workers can be chained together further to provide multiple layers of session proxying.
** Multi-hop sessions use reverse proxy tunnels that are initiated when the downstream workers start and connect to upstream workers.
There are four steps when a client requests to connect to a target that requires a multi-hop path:
1. The client connects to an ingress worker.
1. The ingress worker connects with the next-downstream or egress worker through that worker's established reverse-proxy tunnel.
This step may be repeated multiple times if there are multiple worker connections in the middle of the tunnel chain.
1. The final downstream egress worker connects to the Boundary target.
1. The client can now send data through the tunnel chain.
A multi-hop worker that acts as a downstream can initiate a tunnel to one or multiple upstream workers, specified in the `initial_upstreams` list in the worker configuration.
## Network traffic encryption

Write Preview
Loading…
Cancel
Save