[syslog-ng] 'network' Destination With Hostname Resolution (IPv4 vs IPv6)

Scheidler, Balázs balazs.scheidler at oneidentity.com
Wed Sep 26 14:05:28 UTC 2018


It's PR2312 on github.

On Wed, Sep 26, 2018 at 4:01 PM Balazs Scheidler <bazsi77 at gmail.com> wrote:

> 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
>
> ______________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20180926/a3a5adb9/attachment-0001.html>


More information about the syslog-ng mailing list