-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
DRAFT: Proxy Protocol Transport Socket #10682
Conversation
Signed-off-by: Weston Carlson <[email protected]>
Signed-off-by: Weston Carlson <[email protected]>
Buffer::OwnedImpl buff{}; | ||
Common::ProxyProtocol::generateV1Header(src_address, dst_address, src_port, dst_port, ip_version, buff); | ||
auto res = buff.write(callbacks_->ioHandle()); | ||
if (!res.ok()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the raw buffer socket, it also checks if the res.err
is an Api::IoError::IoErrorCode::Again
, and returns KeepOpen
if it is. I wasn't sure if when receiving the Again
error, it was a possibility that the header was partially sent. Handling that would complicate the logic so for now I'm just returning Close
on any error. Let me know what you think is the right thing to do here is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lizan, do you know? Should this do a similar thing to the raw buffer socket, or is it fine to Close
on any error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm inclined to have @lizan lead first pass on this one as I think he's done more of the socket level API work, but here's some thoughts in passing :-)
api/envoy/config/transport_socket/proxy_protocol/v2/proxy_protocol.proto
Show resolved
Hide resolved
* @return the optional downstream address info. Can be used in upstream sockets that | ||
* need awareness of downstream info e.g. proxy_protocol. | ||
*/ | ||
virtual const absl::optional<DownstreamAddresses> downstreamAddresses() const PURE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@envoyproxy/maintainers for future-proofing sanity check
We use our own custom proxy proto header equivalent in-house as we add some non-standard fields IMO are fairly generically useful. Do y'all know if anyone else does this? I already have some ideas of how we can do our custom stuff with stock Envoy but if we're not the only ones who play around this way I'd be inclined to do a review pass with generic extensibility in mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
proxy protocol v2 has support to extensions. Can your internal version be mapped on this?
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
If the length specified in the PROXY protocol header indicates that additional
bytes are part of the header beyond the address information, a receiver may
choose to skip over and ignore those bytes, or attempt to interpret those
bytes.
The information in those bytes will be arranged in Type-Length-Value (TLV
vectors) in the following format. The first byte is the Type of the vector.
The second two bytes represent the length in bytes of the value (not included
the Type and Length bytes), and following the length field is the number of
bytes specified by the length.
struct pp2_tlv {
uint8_t type;
uint8_t length_hi;
uint8_t length_lo;
uint8_t value[0];
};
A receiver may choose to skip over and ignore the TLVs he is not interested in
or he does not understand. Senders can generate the TLVs only for
the information they choose to publish.
The following types have already been registered for the <type> field :
#define PP2_TYPE_ALPN 0x01
#define PP2_TYPE_AUTHORITY 0x02
#define PP2_TYPE_CRC32C 0x03
#define PP2_TYPE_NOOP 0x04
#define PP2_TYPE_UNIQUE_ID 0x05
#define PP2_TYPE_SSL 0x20
#define PP2_SUBTYPE_SSL_VERSION 0x21
#define PP2_SUBTYPE_SSL_CN 0x22
#define PP2_SUBTYPE_SSL_CIPHER 0x23
#define PP2_SUBTYPE_SSL_SIG_ALG 0x24
#define PP2_SUBTYPE_SSL_KEY_ALG 0x25
#define PP2_TYPE_NETNS 0x30
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly, but if other folks are likely to use the extension I think that answers my question - that should be good enough for the common case. Thanks!
Actually can we do one more split, which is trying to land the APIs first? I've got a WIP patch using your utilities (yay!) and I think I have a handle on API work now: I think basically it'd be nice to have a standalone message for proxy proto config which has the version, and can optionally be extended later for extensions. Then in my PR for translating CONNECT I can just pull that whole proto in the ProxyConfig. Alternately I can land the API with my PR, but I figure you've done all the hard work, might as well get the git blame credit :-P |
Yeah, that sounds good to me. I'm fine if that change happens in your PR. If you need it right away, it's probably best. If it can wait a couple days, I'm happy to do it. |
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Command 'rerun' is not supported by Azure Pipelines. Supported commands
See additional documentation. |
Description: This PR creates a common PROXY protocol config API message. It will be used for CONNECT work as well as in the transport socket for my upstream proxy proto work. This message could be extended to include TLVs in the future. Risk Level: Low Testing: None Docs Changes: None Release Notes: None Discussed in: #10682 (my draft PR to discuss the upstream implementation) Signed-off-by: Weston Carlson <[email protected]>
Okay, thanks for the initial feedback here, everyone 🙂. Since there were no objections, I'm going to split out the first PR (as mentioned in the description). |
Signed-off-by: Weston Carlson <[email protected]>
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Closing as I'm just going to work on making PRs for the individual pieces |
@wez470 wondering if you have other PRs opened, if so please share them |
Hi, sorry for the delay. I plan to have PR 1 out this weekend. |
Commit Message: Add proxy proto transport socket Additional Description: This is the part 1 PR described in #10682. It adds the transports socket / unit tests, a transport socket options struct for the proxy proto header, and does a refactor to make the listener filter use the common proxy proto constants (potentially want to move these now since the proxy proto config api type is not in extensions?) Risk Level: Small Testing: Unit Docs Changes: None Release Notes: None Part Of: #1031 Signed-off-by: Weston Carlson <[email protected]> Co-authored-by: Lizan Zhou <[email protected]>
Commit Message: Add proxy proto transport socket Additional Description: This is the part 1 PR described in envoyproxy#10682. It adds the transports socket / unit tests, a transport socket options struct for the proxy proto header, and does a refactor to make the listener filter use the common proxy proto constants (potentially want to move these now since the proxy proto config api type is not in extensions?) Risk Level: Small Testing: Unit Docs Changes: None Release Notes: None Part Of: #1031 Signed-off-by: Weston Carlson <[email protected]> Co-authored-by: Lizan Zhou <[email protected]> Signed-off-by: Kevin Baichoo <[email protected]>
Commit Message: Add proxy proto transport socket Additional Description: This is the part 1 PR described in envoyproxy#10682. It adds the transports socket / unit tests, a transport socket options struct for the proxy proto header, and does a refactor to make the listener filter use the common proxy proto constants (potentially want to move these now since the proxy proto config api type is not in extensions?) Risk Level: Small Testing: Unit Docs Changes: None Release Notes: None Part Of: envoyproxy#1031 Signed-off-by: Weston Carlson <[email protected]> Co-authored-by: Lizan Zhou <[email protected]>
Commit Message: Add proxy proto transport socket Additional Description: This is the part 1 PR described in envoyproxy#10682. It adds the transports socket / unit tests, a transport socket options struct for the proxy proto header, and does a refactor to make the listener filter use the common proxy proto constants (potentially want to move these now since the proxy proto config api type is not in extensions?) Risk Level: Small Testing: Unit Docs Changes: None Release Notes: None Part Of: envoyproxy#1031 Signed-off-by: Weston Carlson <[email protected]> Co-authored-by: Lizan Zhou <[email protected]> Signed-off-by: chaoqinli <[email protected]>
I opened this because I wanted to discuss / get some feedback on a few things. I am thinking I can split the rest of this work into 2 PRs (Maybe 3?). Contents would be as follows:
PR 1:
PR 2:
PR 3:
This branch currently has PR 1 and some parts of what would be PR 2 in it. I'd just move the PR 1 pieces to a separate branch. Thoughts? I've also left a comment with a question on some code.
@alyssawilk @mattklein123
edit - Just noticed that v2 xDS is now frozen. So I'll have to update that.