[syslog-ng] 'network' Destination With Hostname Resolution (IPv4 vs IPv6)
Balazs Scheidler
bazsi77 at gmail.com
Wed Sep 26 14:01:05 UTC 2018
It should work, yes. Hmm.. I've tried what I've recommended in production
and it does not work without this patch:
```
diff --git a/lib/host-resolve.c b/lib/host-resolve.c
index b685264f9..66915fe47 100644
--- a/lib/host-resolve.c
+++ b/lib/host-resolve.c
@@ -144,6 +144,7 @@
resolve_hostname_to_sockaddr_using_getaddrinfo(GSockAddr **addr, gint
family, co
hints.ai_family = family;
hints.ai_socktype = 0;
hints.ai_protocol = 0;
+ hints.ai_flags = AI_V4MAPPED | AI_ADDRCONFIG;
if (getaddrinfo(name, NULL, &hints, &res) == 0)
{
```
With that patch, this configuration worked even if no ipv6 address was
available:
destination d_ipv6 {
network("host.name.somewhere.com" ip-protocol(6));
};
The flags above basically mean the following logic (quoting from
getaddrinfo):
> If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4
> addresses are returned in the list pointed to by res only if the local
> system has at least one IPv4 address config‐
> ured, and IPv6 addresses are returned only if the local system has
> at least one IPv6 address configured. The loopback address is not
> considered for this case as valid as a con‐
> figured address. This flag is useful on, for example, IPv4-only
> systems, to ensure that getaddrinfo() does not return IPv6 socket addresses
> that would always fail in connect(2)
> or bind(2).
>
> If hints.ai_flags specifies the AI_V4MAPPED flag, and
> hints.ai_family was specified as AF_INET6, and no matching IPv6 addresses
> could be found, then return IPv4-mapped IPv6
> addresses in the list pointed to by res. If both AI_V4MAPPED and
> AI_ALL are specified in hints.ai_flags, then return both IPv6 and
> IPv4-mapped IPv6 addresses in the list pointed
> to by res. AI_ALL is ignored if AI_V4MAPPED is not also specified.
>
This means that as long as you have a local ipv6 address configured
(loopback does not count) and the server has an IPv6 address, syslog-ng
would be using that. If the server does not have one or there's no local
ipv6 address, it'd be using an IPv4-mapped address (e.g. ::ffff:1.2.3.4)
and would continue to use ipv4 on the wire.
I am posting this fix as a PR on github in a moment.
On Tue, Sep 25, 2018 at 3:59 PM David Hauck <davidh at netacquire.com> wrote:
> Hi Balázs,
>
> Thanks for your thoughts. Please see below.
>
> On Fri, 21 Sep 2018 at 04:52:00, syslog-ng <
> syslog-ng-bounces at lists.balabit.hu> On Behalf Of Scheidler, Balázs wrote:
> > The reason you need to explicitly ask for ip-protocol(6) is that
> > sometimes, syslog-ng by itself can create such a socket, can even
> > resolve DNS names to ipv6 addresses and then communication wouldn't
> > work without an actual ipv6 tunnel/connectivity. Setting ip-protocol(6)
> > everywhere would achieve auto-detection and it probably would make sense
> > to make this configurable globally, not on a per-destination basis.
>
> Independent of a potential globally configurable hint would it work to use
> ip-protocol(6) in all of my destination configurations directly, regardless
> of whether the specified <destination-address> is a hostname (which may be
> resolve to an IPv4 or IPv6 address), an IPv4 address string, or an IPv6
> address string?
>
> I would really like to just specify this once for each/all destinations (I
> don't mind doing it for each destination, I just don't want to have to
> evaluate whether to use ip-protocol([46])*).
>
> Regards,
> -David
>
> * The destination configurations are performed programmatically and the
> extra determination for whether the configured <destination-address> falls
> into any of the above three categories is cumbersome/tricky at the locale
> where this done.
>
> > That would probably be something like this:
> >
> > * introduce ipv6 related attributes in GlobalConfig, defaulting to
> ipv4
> >
> > * have those attributes configurable through cfg-grammar.y (e.g.
> > the main configuration parser)
> > * in each destination that supports ipv6, inherit the global value
> > unless overridden locally
> >
> > There are similar patterns in the configuration/destination relation,
> > for instance with log-fifo-size() where there's a global and a local
> setting as well.
> >
> >
> > With that said, I'd say that patches are welcome, I couldn't work on
> > it myself right now, but I am happy to review any solutions.
> >
> >
> > On Thu, Sep 20, 2018 at 6:03 PM David Hauck <davidh at netacquire.com
> <mailto:davidh at netacquire.com> > wrote:
> >
> >
> > Hi Balazs,
> >
> > On Wednesday, September 19, 2018 9:21 PM, syslog-ng
> > <syslog-ng-bounces at lists.balabit.hu
> > <mailto:syslog-ng-bounces at lists.balabit.hu> > On Behalf Of Balazs
> Scheidler wrote:
> > > Ip protocol v6 should support both ipv4 and v6. So if you use
> that and
> > > the name resolves to a v4 address or should work.
> >
> > OK, interesting.
> >
> > For a different reason it would also be good if I could always
> > specify ip-protocol(6) (non-default) for any value of "myhost" below -
> > i.e., even when this is an explicit IPv4 or IPv6 address string. Would
> > this also work? And if this were to work (I see no reason why it
> > wouldn't if what you say about hostname resolution above) then I guess
> there is no value in specifying ip-protocol() at all, right (i.e.,
> syslog-ng could also just know to do the right thing in these cases)?
> >
> > Thanks,
> > -David
> >
> > > On Wed, Sep 19, 2018, 19:23 David Hauck <davidh at netacquire.com
> > <mailto:davidh at netacquire.com> <mailto:davidh at netacquire.com
> > <mailto:davidh at netacquire.com> > >> wrote: > >
> Hi, > >
> > Thought I would reach out again to see if anyone had any thoughts on the
> > item below. > > Thanks for the consideration, >
> -David >
> > > On Wednesday, September 12, 2018 3:39 PM, syslog-ng
> > <syslog-ng-bounces at lists.balabit.hu
> > <mailto:syslog-ng-bounces at lists.balabit.hu> >
> > <mailto:syslog-ng-bounces at lists.balabit.hu
> > <mailto:syslog-ng-bounces at lists.balabit.hu> > > On Behalf Of David Hauck
> > > wrote: > Hi, > > I have a question regarding how
> to
> > specify a network > destination when using a hostname when the >
> > hostname can be resolved > to either IPv4 or IPv6. In particular
> what
> > should be specified by the > ip- > protocol() parameter? There are
> > some configuration scenarios > and/or target installations that don't
> > > know a priori whether the DNS > configuration will resolve to an
> > IPv4 or IPv6 address.
> >>> E.g., > >
> > > destination d_tcp6 { > network( > "myhost"
> >>
> > > port(514) > transport(udp) >
> > ip-protocol(6 or 4 or ??)
> > > > ); > }; > > It seems like it would
> > simple enough to have
> > > syslog-ng simply validate the resulting IP address string to
> >>
> > > determine which of ip-protocol(4) or ip-protocol(6) is actually
> needed.
> > > In fact, I would argue that > specifying an IP address
> > string (as the
> > > "<destination-address>" value) could result in the same
> >> determination
> > > (the address string necessarily unambiguously determines whether
> the
> > > reference is an > IPv4 or an IPv6 address and I would think
> > there is a > 1-1 relationship between this determination and >
> > whether > ip-protocol(4) or ip-protocol(6) is used - (in other
> words it
> > would > never make sense to have > these mixed: "::1" and
> > ip-protocol(4) would > be invalid). > > Thanks, -David >
> >
> > ________________________________________________________________________
> > ______ Member info:
> https://lists.balabit.hu/mailman/listinfo/syslog-ng
> > Documentation:
> > http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ:
> > http://www.balabit.com/wiki/syslog-ng-faq
> >
> >
>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation:
> http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>
>
--
Bazsi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20180926/d7cd5cae/attachment.html>
More information about the syslog-ng
mailing list