Hello Josh (everyone else too), I can confirm that if the FD --> DIR connection is opened, then the Director does use this socket to communicate to the FD.
However, the "Connecting to Client..." message does not change, and incorrectly
(IMHO) reports that it is making an outbound
connection to the IP:port specified in the Director's resource for this Client:
----8<----
*s client=stinky-fd
Connecting to Client stinky-fd at 10.1.1.222:9102
----8<----
I did an `estimate` and then ran a job. Packet traces confirm that the
connection(s) created by the client are used and the
Director does not actually call out to it. A nice feature request would be to
change this Connecting message to something like:
----8<----
*s client=stinky-fd
Connecting to Client stinky-fd on inbound connection opened by Client
----8<----
Interestingly, if the Client's connection into the Director is down (ie: kill
the FD), then the Director does actually make
the attempt to connect to the C
lient on it's defined IP:port, which of course fails. :)
I think this is also incorrect behavior, or at least it is not behaving as
documented, or in the way I would expect/want it
to for Clients behind NAT when we know the Director will never be able to make
the connection.
This is all nice information and it proves this feature is (mostly) working as
documented, but now we still need to solve
Wanderlei's issue. :)
I am guessing one or more of a few things are the possible culprit:
- Port forwarding at the firewall is not working as expected
- The `Address = xxxx` in the Director{} section of the FD is not correct
- The FD has not been restarted (I have seen systemctl restart bacula-fd not
always work)
@Wanderlei, I would recommend to do a tcpdump on the Director when things are
quiet (ie: no jobs running) to see if this
inbound connection from the client is actually making it to the Director
through your firewall:
First stop the FD.
Then start a tcp
dump session as root on the Director:
----8<----
# tcpdump -i any tcp port 9101 or 9102 -vvv -w bacula.dump
----8<----
Then, start the FD. The "Got #" message should increment. If it does not, we
have our answer. If it does, do a 'status
client=xxxx' in bconsole for this client. The "Got #" should increment some...
Kill the tcpdump and open the dump file in Wireshark to see what was happening.
You can even start the FD in foreground and debug mode to see what it is doing
and look for its outbound connection
attempt(s) to the Director to confirm it is trying to do the right thing:
----8<----
# killall bacula-fd
# /path/to/bacula-fd -f -d100 -c /path/to/bacula-fd.conf
----8<----
Let us know what you find!
Best regards,
Bill
--
Bill Arlofski
w...@protonmail.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
