net: Golang udp listener send reply with unexpected source ip #36421
Labels
Milestone
Comments
From the discussions I've read in similar issues (#23367 (comment), #17930), there hasn't been a consensus on a better UDP API. I'm no networking expert, but I believe nginx is copying over the address from the inbound UDP to the outbound UDP message. I believe it's doable in Go, but there's not an obvious way to me in the standard library right now. I'm not sure how WriteToUDP would know which interface you read from unless you were explicitly telling it, given the way the listener works. /cc @mikioh |
@toothrot FYI mikioh has not been active on the issue tracker in many months. |
You may try l := ipv4.NewPacketConn(listener)
l.SetControlMessage(ipv4.FlagDst, true)
n, cs, remoteAddr, err := l.ReadFrom(data)
cs.Src = cs.Dst
n, err = l.WriteTo([]byte("world"), cs, remoteAddr) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
At the very first time, we found that when I dig the backend dns server, which is written in go, we got an unexpect source alert, it seems that the reply came from another interface from the machine.

So I want to stimulate this issue with a tiny program like:
UDP server listen on (:9999 or 0.0.0.0:9999)

What did you expect to see?
The machine we are gonna access is bound with multiple interface, i.e. it has eth0/eth1/tun0/tun1 etc.

so when the client get access to this service from eth0, it is expect that the reply must be sent from interface eth0.
What did you see instead?
Udp server local ip (multi)
x.x.52.207
x.x.56.205
x.x.78.207
client (remote IP) : x.x.218.174
run tcpdump from udp server

as you can see, the server always reply from the default interface, the steps are as belows:
TCP connections all work as expect except UDP connections.
However, when we test this scenario with Nginx, it works:
As you can see it reply the client with the incoming interface instead of the default one.
Here is the simplified config:
The text was updated successfully, but these errors were encountered: