[Sks-devel] How can I tell if the server running recon properly

[Shengjing Zhu]

Hi,
I have been run sks.ustclug.org for about 1 year. Everything seems works
fine. Besides, I run this service in docker environment.

I recently checked the logs, some lines are confused to me:

Reconciliation attempt from unauthorized host <ADDR_INET [172.17.0.1]:43239>

I don't know why the host ip(where the docker runs) is shown there.
Maybe the log means every peer's ip, that sks sees, is the ip of the docker
host, not the real ip which peer's domain resolves. So I wonder do all
my peers successfully recon with me in the past year?...

Then I setup another instance to peer with it. It seems there's no
problem even the confused log showed.

But I do want to know how can I ensure the recon is working properly in
my docker environment.

Thanks
Shengjing Zhu

[Shengjing Zhu]

So something in the setup is terminating external TCPv4 connections and
opening new ones to proxy onwards, or masquerading inbound connections.
This won't work well with SKS.

I thought it should not work well if this error displayed. But the test
seems not to agree.

At a guess: IPv6. [2001:da8:d800:f001::99] is probably routed directly
to the container. So any of your peers with IPv6 connectivity is
exchanging keys with you over IPv6.

No, IPv6 is not enabled inside my docker container. This addr only works
on the nginx front.

That will not be going through the docker host's masquerading.
Test with IPv4 connections _from_ outside the Docker
host/cluster/whatever.

I did test from other network which is in my company. And
sks.ustclug.org is in the university.

Some logs for the test instance, https://paste.debian.net/977001/

Besides, logs for sks.ustclug.org:

2017-07-18 02:32:03 Reconciliation attempt from <ADDR_INET [172.17.0.1]:47351> while gossip disabled. Ignoring.
2017-07-18 02:32:05 Reconciliation attempt from <ADDR_INET [212.47.251.x]:43313> while gossip disabled. Ignoring.
2017-07-18 02:32:13 Requesting 3 missing keys from <ADDR_INET [101.231.119.x]:11371>, starting with 00693CDF3F16D3AC9362A69E08D6D4FB

Some are 172.17.0.1, some are not...
Just more confused...

BTW, if there's problem that my peers complained to me, I will switch to
use host network for the docker container. Thus no more such confused
problem.
But right now, it seems no further steps need to be taken.

Regards,
Shengjing Zhu