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.

Sign up for GitHub

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

Jump to bottom

multihome server, wrong answer ip #1257

Closed
AlexHighTower opened this issue Dec 13, 2019 · 13 comments
Closed

multihome server, wrong answer ip #1257

AlexHighTower opened this issue Dec 13, 2019 · 13 comments

Comments

@AlexHighTower
Copy link

Issue Details

machine with AdG has two interfaces: 10.10.10.10, 192.168.100.100

there is another machine connected directly by net 192.168.100.20
and it has route to 10.10.10.0/24 via 192.168.100.100

so, if there is dns request from 192.168.100.20 to 10.10.10.10, reply is send not from 10.10.10.10, but from 192.168.100.100 and nothing works...

host google.com 10.10.10.10
;; reply from unexpected source: 192.168.100.100#53, expected 10.10.10.10#53

in same configuration bind works fine
@szolin
Copy link
Contributor

szolin commented Dec 13, 2019

Please attach application logs with verbose: true. I think there will be 192.168.100.100 client address. In this case AGH works correctly.

Why does bind responds to 10.10.10.10 if its client address is 192.168.100.100 ? It probably doesn't, because it doesn't make any sense. Can you find out what is the client IP that bind receives?

@AlexHighTower
Copy link
Author

192.168.100.20 asks 10.10.10.10 - this is correct request
but get reply from 192.168.100.100 - this is wrong
bind works correct

and verbose log show nothing about incoming and outgoing interfaces/adresses

2019/12/13 16:28:00 8156#99 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).handleUDPPacket(): Start handling new UDP packet from 192.168.100.20:60823
2019/12/13 16:28:00 8156#99 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 39130
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com. IN A

2019/12/13 16:28:00 8156#99 [debug] github.com/AdguardTeam/dnsproxy/proxy.exchangeWithUpstream(): upstream 127.0.0.1:153 successfully finished exchange of ;google.com. IN A. Elapsed 20 ms.
2019/12/13 16:28:00 8156#99 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).Resolve(): RTT: 20 ms
2019/12/13 16:28:00 8156#99 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: NOERROR, id: 39130
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 115 IN A 64.233.165.102
google.com. 115 IN A 64.233.165.138
google.com. 115 IN A 64.233.165.139
google.com. 115 IN A 64.233.165.100
google.com. 115 IN A 64.233.165.101
google.com. 115 IN A 64.233.165.113

;; AUTHORITY SECTION:
. 2221 IN NS j.root-servers.net.
. 2221 IN NS f.root-servers.net.
. 2221 IN NS l.root-servers.net.
. 2221 IN NS g.root-servers.net.
. 2221 IN NS d.root-servers.net.
. 2221 IN NS a.root-servers.net.
. 2221 IN NS h.root-servers.net.
. 2221 IN NS c.root-servers.net.
. 2221 IN NS e.root-servers.net.
. 2221 IN NS m.root-servers.net.
. 2221 IN NS b.root-servers.net.
. 2221 IN NS i.root-servers.net.
. 2221 IN NS k.root-servers.net.

2019/12/13 16:28:05 8156#100 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).handleUDPPacket(): Start handling new UDP packet from 192.168.100.20:60823
2019/12/13 16:28:05 8156#100 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 39130
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com. IN A

2019/12/13 16:28:05 8156#100 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).Resolve(): Serving cached response
2019/12/13 16:28:05 8156#100 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: NOERROR, id: 39130
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 110 IN A 64.233.165.102
google.com. 110 IN A 64.233.165.138
google.com. 110 IN A 64.233.165.139
google.com. 110 IN A 64.233.165.100
google.com. 110 IN A 64.233.165.101
google.com. 110 IN A 64.233.165.113

;; AUTHORITY SECTION:
. 110 IN NS j.root-servers.net.
. 110 IN NS f.root-servers.net.
. 110 IN NS l.root-servers.net.
. 110 IN NS g.root-servers.net.
. 110 IN NS d.root-servers.net.
. 110 IN NS a.root-servers.net.
. 110 IN NS h.root-servers.net.
. 110 IN NS c.root-servers.net.
. 110 IN NS e.root-servers.net.
. 110 IN NS m.root-servers.net.
. 110 IN NS b.root-servers.net.
. 110 IN NS i.root-servers.net.
. 110 IN NS k.root-servers.net.

2019/12/13 16:28:10 8156#87 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).handleUDPPacket(): Start handling new UDP packet from 192.168.100.20:60823
2019/12/13 16:28:10 8156#87 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 39130
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com. IN A

2019/12/13 16:28:10 8156#87 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).Resolve(): Serving cached response
2019/12/13 16:28:10 8156#87 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: NOERROR, id: 39130
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 105 IN A 64.233.165.102
google.com. 105 IN A 64.233.165.138
google.com. 105 IN A 64.233.165.139
google.com. 105 IN A 64.233.165.100
google.com. 105 IN A 64.233.165.101
google.com. 105 IN A 64.233.165.113

;; AUTHORITY SECTION:
. 105 IN NS j.root-servers.net.
. 105 IN NS f.root-servers.net.
. 105 IN NS l.root-servers.net.
. 105 IN NS g.root-servers.net.
. 105 IN NS d.root-servers.net.
. 105 IN NS a.root-servers.net.
. 105 IN NS h.root-servers.net.
. 105 IN NS c.root-servers.net.
. 105 IN NS e.root-servers.net.
. 105 IN NS m.root-servers.net.
. 105 IN NS b.root-servers.net.
. 105 IN NS i.root-servers.net.
. 105 IN NS k.root-servers.net.

@szolin
Copy link
Contributor

szolin commented Dec 13, 2019 •
edited
Loading

asks 10.10.10.10

Are you sure? Because in logs there is a request from .20:

Start handling new UDP packet from 192.168.100.20:60823

This means that 192.168.100.100 interface is used. AGH correctly responds back to this client via the same interface.

@AlexHighTower
Copy link
Author

Are you sure? Because in logs there is a request from .20:
yes, I'm sure! because request is

 dig google.com @10.10.10.10
;; reply from unexpected source: 192.168.100.100, expected 10.10.10.10
;; reply from unexpected source: 192.168.100.100, expected 10.10.10.10
;; reply from unexpected source: 192.168.100.100, expected 10.10.10.10

This means that 192.168.100.100 interface is used. AGH correctly responds back to this client via the same interface.

this means that request came to intercase has 192.168.100.100 but it was targeted to 10.10.10.10 which is at the same pc with 192.168.100.100 and reachable via this interface

1 similar comment
@AlexHighTower
Copy link
Author

Are you sure? Because in logs there is a request from .20:
yes, I'm sure! because request is

 dig google.com @10.10.10.10
;; reply from unexpected source: 192.168.100.100, expected 10.10.10.10
;; reply from unexpected source: 192.168.100.100, expected 10.10.10.10
;; reply from unexpected source: 192.168.100.100, expected 10.10.10.10

This means that 192.168.100.100 interface is used. AGH correctly responds back to this client via the same interface.

this means that request came to intercase has 192.168.100.100 but it was targeted to 10.10.10.10 which is at the same pc with 192.168.100.100 and reachable via this interface

@szolin
Copy link
Contributor

szolin commented Dec 16, 2019

We're talking about a little bit different things here.
I see that you're specifiying 10.10.10.10 as a server address.
But in logs I see that your request came from 192.168.100.20.
And I don't see what AGH software can do to send response for your request using a different network interface! It looks to me more like this is a job for your OS routing mechanism.

That's why I asked:

Can you find out what is the client IP that bind receives?

Because I also don't understand how can bind do it.

@AlexHighTower
Copy link
Author

yes, we talk about different...
you want to say what AGH send response with src addr of interface via request was received - and this is wrong, I want to say that all software send reply from src address equals to dst address of received request (as bind do) - and this is correct, because pc has two ip addresses and first one is reachable via second network because of routing....

10.10.10.10 is on the same server as 192.168.100.100 (different interfaces), but 10.10.10.10 can be reached from 192.168.100.0/24 network because on pc with 192.168.100.20 there is route 10.10.10.0/24 via 192.168.100.20

@szolin
Copy link
Contributor

szolin commented Dec 20, 2019

all software send reply from src address equals to dst address of received request

I don't think this is true. A normal software doesn't control source IP field in IPv4 packets - it only can do it once by using bind() syscall. AGH's DNS server binds to all your interfaces only once during startup. It's your OS which controls which source IP address to use when responding to UDP messages. Look at sendto() syscall - you can specify only destination IP address there.

So once again, I don't see anything wrong here from AGH's side.

@AlexHighTower
Copy link
Author

if to compare with bind
bind listen on each single ip of system individually
agh listen 0.0.0.0
this could be the reason

@ameshkov
Copy link
Member

and it has route to 10.10.10.0/24 via 192.168.100.100

Could you please show iptables and ip r?

@szolin
Copy link
Contributor

szolin commented Dec 31, 2019

bind listen on each single ip of system individually

That's interesting. I wonder why they need a different listening socket in this case.
But suppose we do this too - it won't help to resolve your problem. Your client is 192.168.100.20 and

AGH correctly responds back to this client via the same interface.

which is 192.168.100.100 as source IP address.

@szolin szolin closed this as completed Jan 14, 2020
@shNanChen
Copy link

I encountered the same problem!

dig google.com @_AGH
;; reply from unexpected source: ...

dig google.com @_AGH +tcp
;; ANSWER SECTION:
google.com. x.x.x.x

@ameshkov
Copy link
Member

@shNanChen do you also have multiple IP addresses on the same interface?

I guess this is the same issue as this one then: #1490

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ameshkov @shNanChen @AlexHighTower @szolin