[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