-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Feature request: bind to specific system interface or IP address #444
Comments
This was referenced Aug 30, 2020
@caffix thanks for implementing this! There's one little bug which is breaking it- it looks like you need an extra call on the string you're using for the interface- as it is, it's a CIDR notation representation, so instead of, e.g., 10.1.1.11 I'm getting 10.1.1.11/24 and it silently fails and continues on with the primary interface. The following takes care of it (I didn't do error handling)
|
caffix
added a commit
that referenced
this issue
Sep 1, 2020
Co-authored-by: mzpqnxow <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For systems with multiple interfaces but only one interface set as the default route, it would be nice if it was possible to specify a specific interface to bind to, either by the interface name or by using the IP address. This allows cycling the interfaces across runs without making invasive changes to the routing table
This is a real use-case for me that I've been working around this using a simple hack- here is an example of what I'm doing in the HTTP dialer:
I would like to implement a "proper" solution, by having the interface name or address be part of the options and taken from the context, though it's a little tricky because there is more than one place where various network requests are made from- they aren't all HTTP, for starters
I'm a C and Python programmer, so I can read golang and can write golang with very basic proficiency. I'm not very well-versed in the amass architecture, so it has been a little slow for me trying to figure out the most appropriate way to add this functionality. Ideally there would be a single function that is used to get a socket, whether it's TCP or UDP- and it would have the context Config and be able to set the DialContext in the way that I do above. I'm not familiar enough with golang to know if there is a simpler way to do something that would more seamlessly and simply apply this DialContext globally. If there is a mechanism to do that it would obviously be the preferred way
I guess my questions are:
getenv()
calls all over the place is certainly not the right way, it's just the easiestAlternately, if you think this is a simple and you're willing to do it yourself because of your proficiency in golang and familiarity with the code, I would very happily defer the task to you :)
The text was updated successfully, but these errors were encountered: