Skip to content

[docs] original src listener filter docs#5539

Merged
mattklein123 merged 7 commits intoenvoyproxy:masterfrom
klarose:original_src_docs
Jan 16, 2019
Merged

[docs] original src listener filter docs#5539
mattklein123 merged 7 commits intoenvoyproxy:masterfrom
klarose:original_src_docs

Conversation

@klarose
Copy link
Copy Markdown
Contributor

@klarose klarose commented Jan 8, 2019

Description:
This adds document for the original src listener filter, as well as some overarching documentation for how to achieve IP Transparency with Envoy.

Risk Level: Low. Just docs
Testing: Built and viewed the new docs
Docs Changes:

  • Added a new Architecture section: IP Transparency
  • Added listeners to the v2 proto docs generation
  • Added a configuration section for the original src listener filter

Signed-off-by: Kyle Larose <kyle@agilicus.com>
Signed-off-by: Kyle Larose <kyle@agilicus.com>
- Clean up formatting (100 column lines)
- Fix some typos
- Talk about ip version

Signed-off-by: Kyle Larose <kyle@agilicus.com>
Signed-off-by: Kyle Larose <kyle@agilicus.com>
@klarose
Copy link
Copy Markdown
Contributor Author

klarose commented Jan 8, 2019

@mattklein123 Here's the docs you asked for. Hopefully the architecture section is sufficient. If it isn't, let me know and I can take another stab at it.

This is needed so that we can force the non-local IPv4 addresses to
route locally.

Signed-off-by: Kyle Larose <kyle@agilicus.com>
@klarose
Copy link
Copy Markdown
Contributor Author

klarose commented Jan 8, 2019

/retest

@repokitteh-read-only
Copy link
Copy Markdown

🔨 rebuilding ci/circleci: coverage (failed build)

🐱

Caused by: a #5539 (comment) was created by @klarose.

see: more, trace.

@klarose
Copy link
Copy Markdown
Contributor Author

klarose commented Jan 14, 2019

@mattklein123 Any chance you'd be able to take a look at this in the next few days, please? Thanks!

@mattklein123
Copy link
Copy Markdown
Member

Yes I will take a look.

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks this is super awesome and exactly what I had in mind. A couple of small things. @lizan @jrajahalme can you take a quick read since you have been reviewing this feature?

/wait

Comment thread docs/root/configuration/listener_filters/original_src_filter.rst Outdated
Comment thread docs/root/intro/arch_overview/ip_transparency.rst Outdated
Signed-off-by: Kyle Larose <kyle@agilicus.com>
Review requested that some references be added. This change does so.

Signed-off-by: Kyle Larose <kyle@agilicus.com>
Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Will wait a bit to merge to see if anyone has any further comments.

@mattklein123 mattklein123 merged commit a3645c1 into envoyproxy:master Jan 16, 2019
the downstream remote address for propagation into an
:ref:`x-forwarded-for <config_http_conn_man_headers_x-forwarded-for>` header. It can also be used in
conjunction with the
:ref:`Original Src Listener Filter <arch_overview_ip_transparency_original_src_listener>`.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can we expand it to full name i.e Original Source Listener Filter?

fredlas pushed a commit to fredlas/envoy that referenced this pull request Mar 5, 2019
Signed-off-by: Kyle Larose <kyle@agilicus.com>
Signed-off-by: Fred Douglas <fredlas@google.com>
this to *X* causes Envoy to *mark* all upstream packets originating from this listener with value
*X*.

We can use the following set of commands to ensure that all ipv4 and ipv6 traffic marked with *X*
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for putting together these docs @klarose, they're very helpful.
Do you happen to know how the PREROUTING rule below works for local packets?
All the iptables diagrams seem to show no path from local process to PREROUTING so I'm having a hard time understanding how this rule applies to local traffic with the sidecar.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has been a while since I last did this, so I'm a little rusty. As some background, this configuration was inspired by mmproxy. They don't explain why exactly. :)

I think that it has to do with the fact that there is a separate routing table involved. Perhaps the system considers transit between different routing tables as transit between different networks?

It could also be that the kernel, seeing that the source IP isn't a local one, treats it as having come from an external network.

I'm sorry I don't have a better answer.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That helps, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants