Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sqlproxyccl: expose second port for proxy protocol listener #117240

Closed
DuskEagle opened this issue Jan 2, 2024 · 0 comments · Fixed by #117241
Closed

sqlproxyccl: expose second port for proxy protocol listener #117240

DuskEagle opened this issue Jan 2, 2024 · 0 comments · Fixed by #117241
Assignees
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)

Comments

@DuskEagle
Copy link
Member

DuskEagle commented Jan 2, 2024

SQLProxy currently listens on a single port for SQL connections. A flag --require-proxy-protocol controls whether that port expects incoming packets to contain proxy protocol headers.

To support GCP Private Service Connect, we need to have a listener in SQLProxy which expects packets to contain proxy protocol headers. This listener will be used for all traffic inbound from PSC. At the same time, SQLProxy must continue to accept connections through the public Internet which will not contain proxy protocol headers, and for which any proxy protocol headers we receive cannot be trusted.

This necessitates two listeners in SQLProxy: the existing one, whose behavior is controlled by the --require-proxy-protocol flag, and an optional second one, which if enabled, listens on a different port and requires proxy protocol headers. PSC will direct traffic to this listener.

Jira issue: CRDB-35085

@DuskEagle DuskEagle added C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions) labels Jan 2, 2024
@DuskEagle DuskEagle self-assigned this Jan 2, 2024
DuskEagle added a commit to DuskEagle/cockroach that referenced this issue Jan 4, 2024
craig bot pushed a commit that referenced this issue Jan 16, 2024
117241: sqlproxyccl: add proxy protocol listener r=DuskEagle a=DuskEagle

To support GCP Private Service Connect, we need to have a listener in
SQLProxy which expects packets to contain proxy protocol headers. This
listener will be used for all traffic inbound from PSC. At the same
time, SQLProxy must continue to accept connections through the public
Internet which will not contain proxy protocol headers, and for which
any proxy protocol headers we receive cannot be trusted.

This commit introduces an optional second listener in SQLProxy,
controlled by `--proxy-protocol-listen-addr`, which requires
proxy protocol even as the primary listener doesn't. Private Service
Connect will direct traffic to this second listener.

Resolves #117240

Release note: None

117819: kv: fix assertion output in TestReplicationStatusReportIntegration r=nvanbenschoten a=nvanbenschoten

Informs #117175.

This doesn't fix the failing test, but it resolves the nonsensical failure message and allows us to debug the test.

Release note: None

Co-authored-by: Joel Kenny <[email protected]>
Co-authored-by: Nathan VanBenschoten <[email protected]>
@craig craig bot closed this as completed in 8d752fd Jan 17, 2024
blathers-crl bot pushed a commit that referenced this issue Jan 17, 2024
To support GCP Private Service Connect, we need to have a listener in
SQLProxy which expects packets to contain proxy protocol headers. This
listener will be used for all traffic inbound from PSC. At the same
time, SQLProxy must continue to accept connections through the public
Internet which will not contain proxy protocol headers, and for which
any proxy protocol headers we receive cannot be trusted.

This commit introduces an optional second listener in SQLProxy,
controlled by `--proxy-protocol-listen-addr`, which requires
proxy protocol even as the primary listener doesn't. Private Service
Connect will direct traffic to this second listener.

Resolves #117240

Release note: None
cockroach-dev-inf pushed a commit that referenced this issue Jan 17, 2024
To support GCP Private Service Connect, we need to have a listener in
SQLProxy which expects packets to contain proxy protocol headers. This
listener will be used for all traffic inbound from PSC. At the same
time, SQLProxy must continue to accept connections through the public
Internet which will not contain proxy protocol headers, and for which
any proxy protocol headers we receive cannot be trusted.

This commit introduces an optional second listener in SQLProxy,
controlled by `--proxy-protocol-listen-addr`, which requires
proxy protocol even as the primary listener doesn't. Private Service
Connect will direct traffic to this second listener.

Resolves #117240

Release note: None
DuskEagle added a commit to DuskEagle/cockroach that referenced this issue Jan 25, 2024
To support GCP Private Service Connect, we need to have a listener in
SQLProxy which expects packets to contain proxy protocol headers. This
listener will be used for all traffic inbound from PSC. At the same
time, SQLProxy must continue to accept connections through the public
Internet which will not contain proxy protocol headers, and for which
any proxy protocol headers we receive cannot be trusted.

This commit introduces an optional second listener in SQLProxy,
controlled by `--proxy-protocol-listen-addr`, which requires
proxy protocol even as the primary listener doesn't. Private Service
Connect will direct traffic to this second listener.

Resolves cockroachdb#117240

Release note: None
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant