| Age | Commit message (Collapse) | Author |
|---|
|
ibuf, buf_read to ibuf_read, READ_BUF_SIZE to IBUF_READ_SIZE.
ok henning gilles claudio jacekm deraadt
|
|
and follows a suggestion in event.h. also don't mix signal() and
signal_set()/signal_add().
ok jsg@ gilles@
|
|
|
|
like several other things in the tree.
ok reyk@ looks fine claudio@
|
|
elements first (this matches all the other structures). no functional
change.
|
|
ok pyr@, jmc@ for man bits
|
|
based on health check results, using the existing table syntax. this
allows to maintain multiple (uplink) gateways to implement link
balancing or WAN link failover if no routing protocol or other
keepalive method is available. works fine with or without
net.inet.ip.multipath enabled.
ok pyr@, jmc@ for manpages
|
|
another 'struct session' in sys/sysctl.h.
|
|
check if the host is only n hops away and not re-routed over a longer
path.
|
|
|
|
|
|
Stop pushing event handling in the imsg framework.
Instead, provide a small glue layer on top of both imsg and libevent.
This finally clearly separates event handling and imsg construction.
Sidetrack bonus: remove the mega-ugly hack of having a dummy imsg_event_add
stub in relayctl.
This will make bgpd (and thus henning) happy. Next up are smtpd and ospfd.
ok eric@
|
|
imsg_event_add function to be provided (which ended up being a named
callback).
Instead provide a wrapper in the daemon and call that everywhere.
Previsously discussed with the usual suspects,
ok eric@ though not too happy about the function name
(imsg_compose_event).
|
|
by not calling log_* or fatal and handle set errno when appropriate.
discussed with a bunch of imsg conscious guys, ok eric@
|
|
- use u_int16_t instead of enum imsg_type in imsg function prototypes
requested by reyk@, ok pyr@
|
|
|
|
imsg.h and a daemon-specific imsg_types.h
discussed with and "yes, please" pyr@
|
|
that function is not supposed to report anything remotely useful,
or fail in any meaningful way.
ok pyr@
|
|
ok pyr@
|
|
ok pyr@
|
|
Thanks to Marek Grzybowski for feedback and testing.
ok jmc@ (manpage bits)
|
|
server certificates when connecting as an SSL client from relays. it
works so far, but needs more testing and is currently lacking support
for certificate revocation (like CRL or OCSP). the file ssl_privsep.c
is extended to implement more code that should be in openssl to allow
loading the ca from chroot...
|
|
now sit between two SSL connections (Oitm - OpenBSD-in-the-middle),
accept SSL connections and forward to TCP, accept TCP connections and
forward to SSL, and do TCP to TCP of course.
This was tested by some people a while ago.
|
|
arbitrary string in debugging mode, it will store an error code
(HCE_*) for each host. the error code can be translated to a string
(in log.c) for debugging but it will also be passed to relayctl via
the control socket.
from a user point of view, this will print a human-readable error
message in the "relayctl show hosts" output if a host is down because
the check failed. the relayctl(8) manpage includes detailed
explanations of the error messages including mitigations for the
most-common problems.
ok jmc@ (manpages)
ok phessler@
|
|
just containing on key per line. this allows easier use of URL
white/blacklists from external sources.
|
|
stickyness with web applications that cannot do the clustering on
their own and require stickyness with HTTP to HTTPS migration. this
is required in many cases; it is a true fact that we cannot always fix
the backend application in the real world.
Tested and requested by many
|
|
|
|
faithd(8) by doing a similar mapping of IPv4/6 addresses with
relayd(8) and pf(4) redirections without the need of the faith(4)
interface. The trick works in both directions, it can accept IPv6
connections and relay them to IPv4 hosts by extracting the last 4
octets from the IPv6 destination (like faithd(8)), and it can accept
IPv4 connections and relay them to IPv6 hosts by prepending the 4
octets of the original IPv4 destination to a configured IPv6 prefix.
An access list is not needed because the classification is done in
pf.conf(5). It helps to get more faith in relayd.
manpage bits ok jmc@
yes, sounds good todd@
|
|
singly-linked SLIST instead. the only noticeable change is the
reversed order to notify the children but it does not really matter
here. also only walk through the children host list if the host
itself is a potential parent.
|
|
inherit the state from another host with the specified Id; no
additional check will be for the inheriting host. This helps in
scenarios with lots of IP aliases that all point to the same service
on the same host (like web hosting with many SSL domains).
discussed with pyr, tested in different setups
|
|
produce the DNS request ids instead of a simple per-request
arc4random(). This ensure randomness but also satisfies the
non-repeating property we need.
ok deraadt@
|
|
unbreaks NAT lookups with UDP; tested as a transparent DNS relay.
|
|
forwarded dns request to the server instead of sending from the server
socket. this will fix the limitation the the dns relay had to listen
to the "0.0.0.0" address, and will also enable relayd to use the udp
source port randomization. relayd will know randomize the source port
(on OpenBSD) and DNS request identifier for the clients behind it.
ok pyr@
|
|
relay will connect to the target host with its own ip address, but
this mode will let it use the address of the client that is connecting
from the other side. for example, there is no need to add the
X-Forwarded-For HTTP headers for internal webservers in this mode
anymore since they magically see the remote client ip address in the
connection. it also allows to build fully-transparent ssl
encapsulation for tcp sessions and many other things...
based on an initial idea from dlg@ and pascoe@ (dlg's talk at opencon)
using the new BINDANY and divert-reply interfaces from markus@ (since n2k8)
ok markus@ pyr@
|
|
|
|
to pf route-to instead of the default rdr. it is a first steps towards
support for "direct server return" (dsr), an asynchronous mode where
the load balanced servers send the replies to a different gateway like
a l3 switch/router to handle higher amounts of return traffic.
because the state handling in pf isn't optimal for this case yet, it
just sees half of the TCP connection, the sessions are forced to time
out after fixed number of seconds.
discussed with many, thought about in the onsen
|
|
the initialisation isn't done properly.
|
|
|
|
seperate functions in relayd.c (protonode_add/protonode_header). this
code got to big to look nice in the BNF statements...
|
|
a SNMP trap when the state of a host changes. relayd(8) will try to
(re-)connect to snmpd(8) and request it to send a trap to the
registered trap receivers, see snmpd.conf(5) for more information
about the configuration.
ok pyr@ thib@
|
|
in other places;
ok reyk@
|
|
reused;
ok reyk@
|
|
shuffle the forward decleration of struct relay around too accommodate
this change;
ok reyk@
|
|
for code, next struct session;
ok reyk@;
|
|
for code, next struct relay. knf long line fixes will follow later.
ok thib@
|
|
for code, start with struct relayd. finally.
ok thib@
|
|
for relays. they can be viewed with the new "relayctl show redirects"
command.
(uses the previous change to pf_table.c to get the statistics)
looks good pyr@
|
|
(for instance: rename struct service to struct rdr), refer to redirects
otherwise (hoststatectl output).
ok reyk@
|
|
the tables will look more like pf tables, it is easier to re-use
tables with different options, "services" will become "redirections"
(they refer to rdr pf rules), sync configuration directives of
redirect (l3, ex-service) relay (l7) sections (for example "virtual
host" will become "listen on"), all target definitions will start with
"forward to", etc. pp. (see relay.conf(5) and etc/relayd.conf)
discussed with pyr and deraadt
ok pyr@
|
|
what the daemon does - it is a relayer that pays attention to the status
of pools of hosts; not a status checkers that happens to do some relaying
|
