#relayd — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #relayd, aggregated by home.social.
-
Running #OpenBSD 7.8 :openbsd:
DNS: #nsd (3 Master Zones), #DNSSEC & #DANE (RFC6698) + #unbound
Firewall: #pf with auto-fed tables (IPS-style), spambot-tarpitting & service rate limits.
Mail: #smtpd (Multi-domain, RFC8461/MTA-STS) + #rspamd (DKIM) + #dovecot (IMAPS-only).
Spam-Defense: #spamd with auto-SPF-walk (no more greylisting issues).
Web: #relayd (TLS-Terminator, HSTS, CSP) + #httpd (NIP-05, Autoconfig, security.txt).
Performance: Lightweight "Fail2Ban" via 1-liner shell script (No Python crap!).
#Nostr Relay in Rust building...
#SelfHosted #SysAdmin #Security #Privacy -
Running #OpenBSD 7.8 :openbsd:
DNS: #nsd (3 Master Zones), #DNSSEC & #DANE (RFC6698) + #unbound
Firewall: #pf with auto-fed tables (IPS-style), spambot-tarpitting & service rate limits.
Mail: #smtpd (Multi-domain, RFC8461/MTA-STS) + #rspamd (DKIM) + #dovecot (IMAPS-only).
Spam-Defense: #spamd with auto-SPF-walk (no more greylisting issues).
Web: #relayd (TLS-Terminator, HSTS, CSP) + #httpd (NIP-05, Autoconfig, security.txt).
Performance: Lightweight "Fail2Ban" via 1-liner shell script (No Python crap!).
#Nostr Relay in Rust building...
#SelfHosted #SysAdmin #Security #Privacy -
Running #OpenBSD 7.8 :openbsd:
DNS: #nsd (3 Master Zones), #DNSSEC & #DANE (RFC6698) + #unbound
Firewall: #pf with auto-fed tables (IPS-style), spambot-tarpitting & service rate limits.
Mail: #smtpd (Multi-domain, RFC8461/MTA-STS) + #rspamd (DKIM) + #dovecot (IMAPS-only).
Spam-Defense: #spamd with auto-SPF-walk (no more greylisting issues).
Web: #relayd (TLS-Terminator, HSTS, CSP) + #httpd (NIP-05, Autoconfig, security.txt).
Performance: Lightweight "Fail2Ban" via 1-liner shell script (No Python crap!).
#Nostr Relay in Rust building...
#SelfHosted #SysAdmin #Security #Privacy -
Running #OpenBSD 7.8 :openbsd:
DNS: #nsd (3 Master Zones), #DNSSEC & #DANE (RFC6698) + #unbound
Firewall: #pf with auto-fed tables (IPS-style), spambot-tarpitting & service rate limits.
Mail: #smtpd (Multi-domain, RFC8461/MTA-STS) + #rspamd (DKIM) + #dovecot (IMAPS-only).
Spam-Defense: #spamd with auto-SPF-walk (no more greylisting issues).
Web: #relayd (TLS-Terminator, HSTS, CSP) + #httpd (NIP-05, Autoconfig, security.txt).
Performance: Lightweight "Fail2Ban" via 1-liner shell script (No Python crap!).
#Nostr Relay in Rust building...
#SelfHosted #SysAdmin #Security #Privacy -
Running #OpenBSD 7.8 :openbsd:
DNS: #nsd (3 Master Zones), #DNSSEC & #DANE (RFC6698) + #unbound
Firewall: #pf with auto-fed tables (IPS-style), spambot-tarpitting & service rate limits.
Mail: #smtpd (Multi-domain, RFC8461/MTA-STS) + #rspamd (DKIM) + #dovecot (IMAPS-only).
Spam-Defense: #spamd with auto-SPF-walk (no more greylisting issues).
Web: #relayd (TLS-Terminator, HSTS, CSP) + #httpd (NIP-05, Autoconfig, security.txt).
Performance: Lightweight "Fail2Ban" via 1-liner shell script (No Python crap!).
#Nostr Relay in Rust building...
#SelfHosted #SysAdmin #Security #Privacy -
Gestern abend noch happy, weil #OpenBSD mit #relayd bei uns an den Start ging... Heute sporadisch Ohnmachtsanfälle wegen #stromausfall im Süden Berlins. Unser RZ ist betroffen. Notstrom Aggregat wegen Defekt außer Betrieb. Hatte ich erwähnt das wir unter anderem Winterdienst in ganz Berlin mittels unserer Systeme managen? Glaube mein Wochenende ist im Eimer :D .
Aber alles halb so wild.... ist nur business. Viel wichtiger: Passt alle auf euch und eure Nächsten auf!
-
This afternoon, I got close to what I wanted to achieve in terms of load-balancing between the two #AI #sabots I have running.
I had originally planned to use #OpenBSD's #OpenHTTPD or #RelayD to do the job, but #HAProxy #PROXY protocol was the limiting factor… so I went #nginx instead.
One thing I haven't worked out yet, is how to pass the client IP by PROXY protocol to a HTTP back-end. Seems I can do it for a generic TCP stream, but not HTTP.
The alternative is to set X-Forwarded-For, and have the back-ends trust it, like they trust PROXY for the gateway's IPv4 address for #sniproxy.
But… it works, you can hit https://sabot.vk4msl.com/ and you'll either get sabot01 (which uses nepenthes) or sabot02 (which uses iocaine). Since neither cares about the URI, I can bounce the client between them.
This did get me thinking though, if enough of us did it, we could have a #AISabotAsAService for websites to redirect/link to when they think they're being scraped by an AI bot.
We could provide a pool of servers that would provide the link maze. Front-end proxies would just bounce you between all the pool members, feeding your bot nonsense.
-
This afternoon, I got close to what I wanted to achieve in terms of load-balancing between the two #AI #sabots I have running.
I had originally planned to use #OpenBSD's #OpenHTTPD or #RelayD to do the job, but #HAProxy #PROXY protocol was the limiting factor… so I went #nginx instead.
One thing I haven't worked out yet, is how to pass the client IP by PROXY protocol to a HTTP back-end. Seems I can do it for a generic TCP stream, but not HTTP.
The alternative is to set X-Forwarded-For, and have the back-ends trust it, like they trust PROXY for the gateway's IPv4 address for #sniproxy.
But… it works, you can hit https://sabot.vk4msl.com/ and you'll either get sabot01 (which uses nepenthes) or sabot02 (which uses iocaine). Since neither cares about the URI, I can bounce the client between them.
This did get me thinking though, if enough of us did it, we could have a #AISabotAsAService for websites to redirect/link to when they think they're being scraped by an AI bot.
We could provide a pool of servers that would provide the link maze. Front-end proxies would just bounce you between all the pool members, feeding your bot nonsense.
-
This afternoon, I got close to what I wanted to achieve in terms of load-balancing between the two #AI #sabots I have running.
I had originally planned to use #OpenBSD's #OpenHTTPD or #RelayD to do the job, but #HAProxy #PROXY protocol was the limiting factor… so I went #nginx instead.
One thing I haven't worked out yet, is how to pass the client IP by PROXY protocol to a HTTP back-end. Seems I can do it for a generic TCP stream, but not HTTP.
The alternative is to set X-Forwarded-For, and have the back-ends trust it, like they trust PROXY for the gateway's IPv4 address for #sniproxy.
But… it works, you can hit https://sabot.vk4msl.com/ and you'll either get sabot01 (which uses nepenthes) or sabot02 (which uses iocaine). Since neither cares about the URI, I can bounce the client between them.
This did get me thinking though, if enough of us did it, we could have a #AISabotAsAService for websites to redirect/link to when they think they're being scraped by an AI bot.
We could provide a pool of servers that would provide the link maze. Front-end proxies would just bounce you between all the pool members, feeding your bot nonsense.
-
This afternoon, I got close to what I wanted to achieve in terms of load-balancing between the two #AI #sabots I have running.
I had originally planned to use #OpenBSD's #OpenHTTPD or #RelayD to do the job, but #HAProxy #PROXY protocol was the limiting factor… so I went #nginx instead.
One thing I haven't worked out yet, is how to pass the client IP by PROXY protocol to a HTTP back-end. Seems I can do it for a generic TCP stream, but not HTTP.
The alternative is to set X-Forwarded-For, and have the back-ends trust it, like they trust PROXY for the gateway's IPv4 address for #sniproxy.
But… it works, you can hit https://sabot.vk4msl.com/ and you'll either get sabot01 (which uses nepenthes) or sabot02 (which uses iocaine). Since neither cares about the URI, I can bounce the client between them.
This did get me thinking though, if enough of us did it, we could have a #AISabotAsAService for websites to redirect/link to when they think they're being scraped by an AI bot.
We could provide a pool of servers that would provide the link maze. Front-end proxies would just bounce you between all the pool members, feeding your bot nonsense.
-
This afternoon, I got close to what I wanted to achieve in terms of load-balancing between the two #AI #sabots I have running.
I had originally planned to use #OpenBSD's #OpenHTTPD or #RelayD to do the job, but #HAProxy #PROXY protocol was the limiting factor… so I went #nginx instead.
One thing I haven't worked out yet, is how to pass the client IP by PROXY protocol to a HTTP back-end. Seems I can do it for a generic TCP stream, but not HTTP.
The alternative is to set X-Forwarded-For, and have the back-ends trust it, like they trust PROXY for the gateway's IPv4 address for #sniproxy.
But… it works, you can hit https://sabot.vk4msl.com/ and you'll either get sabot01 (which uses nepenthes) or sabot02 (which uses iocaine). Since neither cares about the URI, I can bounce the client between them.
This did get me thinking though, if enough of us did it, we could have a #AISabotAsAService for websites to redirect/link to when they think they're being scraped by an AI bot.
We could provide a pool of servers that would provide the link maze. Front-end proxies would just bounce you between all the pool members, feeding your bot nonsense.
-
@haircode Nothing in networking is straightforward. While not having tried this using the #relayd , it is likely to be a standard firewalling destination NAT (see DNAT) capability, suitable for running a server inside a firewall protected LAN. . So I've configured firewalls to do this many times, including using IPTABLE rules on Linux.
Some useful notes linked, but note that in this example:
==========================
Packets destined for IP 10.1.1.7 will be forwaded to 192.168.1.2 UDP,TCPDoes NOT work with ping (ICMP) correctly, does not handle ICMP protocol WLAN IP reply on a ping without
iptables -t nat -A PREROUTING -p tcp -i wlan0 -d 10.1.1.7 -j DNAT --to-destination 192.168.1.2
iptables -t nat -A PREROUTING -p udp -i wlan0 -d 10.1.1.7 -j DNAT --to-destination 192.168.1.2==========================
traffic on all ports are forwarded, while it's more likely you will want to forward traffic on specific ports for the Minecraft server port requirements, as that is more secure. -
Surely port-forwarding UDP and TCP packets to a #Minecraft (Debian) server using #relayd on #OpenBSD should be straightforward?
Spent quite a bit of time on this yesterday and didn't manage it. I'm a relative newb when it comes to networking, #pf, etc but even #AI couldn't get me through it.
Has anyone done this? Grateful for any tips.
-
Version 7.4.2024.01.15-p1 of #FreeBSD #relayd has just been released and is available in the FreeBSD Ports tree:
https://cgit.freebsd.org/ports/commit/?id=a66b8f6102fe56d83583db9f4041f3e7fa6c1ba9
One of the interesting changes is fix for a crash that can be triggered by a config reload. The commit message contains a nice write-up:
We are working on getting the fix upstreamed to #OpenBSD. Here's the bug report if you want to take a look:
