标签：#Work

I maintain gumdrop , an async, non-blocking Java server framework. Last year I wanted to add HTTP/3 support, and ran into a wall: the Java ecosystem essentially doesn't have QUIC. The JDK's own experimental support (JEP 517) is client-only. Netty gets HTTP/3 by shelling out to quiche + BoringSSL over JNI — which works, but you're back to native builds, platform-specific binaries, and a C library sitting underneath your "pure Java" framework. I used that approach first. It was clumsy enough that I went looking for a pure-Java alternative. There's exactly one: Kwik. But Kwik is blocking per connection — one thread per QUIC connection. That's a non-starter for a framework built around single-threaded selector loops handling tens of thousands of concurrent connections. So I wrote a QUIC implementation from scratch: packet protection, loss detection and NewReno congestion control, connection migration, 0-RTT, QPACK, an HTTP/3 client and server — all driven by the same non-blocking event loop as everything else in gumdrop. Collaboration note: TLS 1.3 comes from Agent15 — also from Kwik's author, Peter Doornbosch, but just the handshake layer, not the connection model. We're currently working together on making PQC — hybrid key exchange and signatures — the default there. Why the thread model matters The reason this mattered beyond HTTP/3: gumdrop isn't a web framework with QUIC bolted on, it's a general async I/O framework, and QUIC is just a transport. One thread per connection is exactly the model gumdrop exists to avoid — it caps concurrency at your thread pool, not your file descriptors, and it's the reason a "just use Kwik" fix was never really on the table. The same QUIC stack backs DNS-over-QUIC (DoQ) as a first-class DNS transport alongside DoT, DoH, UDP, and TCP — and the DNS resolver itself is fully async, with no blocking InetAddress.getByName() anywhere in the I/O path, which is its own small miracle in Java. HTTP, SMTP, IMAP, POP3, FTP, MQTT, SOCKS — it's the

Seri: Proxmox VE Cluster ve Corosync | Hafta 5 Serinin adı "Cluster ve Corosync"; ama dört modüldür ağırlık HA Manager, resource affinity ve CRS'teydi, Corosync'in kendisine (redundant link'ler, izleme araçları) hiç dönmemiştim. Bu modülde iki konuyu birleştirip derinlemesine işledim: birden fazla corosync link'i tanımlayıp gerçekten birini kesip diğerinin devralmasını kanıtlamak, ve günlük operasyonda kullanılacak izleme araçlarını tek tek denemek. İkisi de planladığımdan çok daha fazla soru açtı; biri yanlış bir config anahtarı yüzünden saatler süren bir araştırmaya dönüştü, diğeri ise hiç beklemediğim bir kilitlenme keşfiyle bitti. Bölüm 1: Redundant Corosync Links Kurulum: İkinci Link'i Eklemek Şu ana kadar cluster'ımızda tek bir corosync link'i vardı ( link1 , izole corosync-net ağı). Management ağını ( 192.168.122.x ) link0 olarak ekleyip gerçek bir yedeklilik kurdum; /etc/pve/corosync.conf 'u kopyalayıp düzenleyip atomik olarak yerine taşıdım: cp /etc/pve/corosync.conf /etc/pve/corosync.conf.new # nodelist'teki her node'a ring0_addr ekledim, totem'e ikinci bir interface bloğu ekledim mv /etc/pve/corosync.conf.new /etc/pve/corosync.conf Doğrulama: corosync-cfgtool -s LINK ID 0 udp addr = 192.168.122.11 status: ... connected ... connected LINK ID 1 udp addr = 10.10.10.11 status: ... connected ... connected Teknik olarak başarılı; iki link de bağlı. Ama log'a dikkatlice bakınca, mimarimizin niyetini tersine çeviren bir şey oldu: [KNET ] rx: host: 3 link: 0 is up [KNET ] host: host: 3 (passive) best link: 0 (pri: 1) link_mode: passive modunda, öncelik eşitken düşük numaralı link kazanıyor . link0 'ı sonradan eklediğim için, o Corosync'in asıl trafiğini üstlenmiş; Modül 0'da özellikle izole ettiğimiz corosync-net ( link1 ) sessizce yedek konuma düşmüştü. Yanlış Anahtar, Saatler Süren Bir Araştırma Bunu düzeltmek için link1 'e daha yüksek öncelik vermeye çalıştım: interface { linknumber : 0 priority : 5 } interface { linknumber : 1 priority : 10 } İşe yaramadı. cor

The social app founded by Bonobos co-founder Andy Dunn is expanding beyond events with new digital homes for groups to connect, organize, and make plans.

The blunt tool is still in a lot of GRUB files: GRUB_CMDLINE_LINUX_DEFAULT = "isolcpus=0,1" Then update-grub (or grub2-mkconfig ) and reboot. Userspace tasks stop landing on CPU0/1. That is all most people verify — they fire a few busy loops and top looks empty on those cores. IRQs do not care. isolcpus is a scheduler isolation hint. Hardware interrupts can still fire on the "isolated" CPUs. I watched seven tight loops leave 0/1 idle for processes while /proc/interrupts still ticked on those cores. If you wanted a CPU for DPDK, a user-space NIC, or a cycle-accurate loop, scheduler isolation is necessary and not sufficient . Lab notes (English original is short; this write-up is the missing IRQ half): https://sunshout.tistory.com/1620 How to see what you actually isolated After reboot: cat /proc/cmdline # isolcpus=0,1 must be there grep PREEMPT /boot/config- $( uname -r ) || true taskset -cp 1 # pick a known userspace pid; it should not be 0,1 watch -n1 'grep "^ *[0-9]" /proc/interrupts | head' If IRQs still increment on CPU0/1, isolation is incomplete. That is expected with classic isolcpus= . On newer kernels the story split: isolcpus=domain / cpusets / cgroup cpuset — userspace isolcpus=managed_irq or manual irqaffinity / /proc/irq/*/smp_affinity — interrupts nohz_full= — tick reduction, another knob, not a substitute isolcpus is also marked deprecated in some trees in favor of cpusets. The IRQ caveat did not go away when the docs changed the preferred interface. Moving IRQs by hand Find the noisy ones ( eth0 , NVMe, GPU): grep -E 'eth|nvme|enp' /proc/interrupts # smp_affinity is a hex CPU mask. CPU2 only → 4 echo 4 > /proc/irq/IRQNUM/smp_affinity Or set the default affinity so new IRQs skip 0/1: irqaffinity=2-7 in the same GRUB line (adjust to your CPU count). Some devices ignore this (managed IRQs, VFIO). Then you isolate at the driver: bind the NIC to vfio-pci and poll from a pinned thread. When this shows up next to SR-IOV Passing a VF into KVM does not pin ho

Networking terms can feel like alphabet soup when you're starting out — Hub, Switch, Router, MAC address, IP address, Subnet Mask — thrown at you all at once, usually with zero real-world context. Here's how I finally made sense of it, using something a lot more familiar: cricket. The Cricket Analogy Imagine a cricket team with three players: a hub , a switch , and a router . All three are part of the same game, but each has a completely different job — one's a batsman, one's a bowler, one's a fielder. Networking devices work the same way: they're all part of one network, but each does something distinct. Hub — The One Who Shouts to Everyone A hub is the simplest of the three. If only two devices need to talk, you don't even need one — but the moment more than two devices are connected, a hub becomes necessary to relay traffic between them. Here's the catch: a hub has no idea who's talking to whom. If Device A wants to send data to Device B, it sends that data to the hub — and since the hub doesn't know which device Device A actually wants to reach, it just broadcasts the data to every single connected device. So a hub's "functionality" is really a lack of intelligence — it doesn't figure out who wants to speak with whom; it just floods the message everywhere and lets the devices sort it out. Switch — The One Who Knows Everyone by Name A switch does the same basic job as a hub — moving data between connected devices — but with one major upgrade: it actually knows who's who. Instead of blindly broadcasting to every device, a switch keeps a table of each connected device's MAC address , so it can send data directly to the right recipient. What Is a MAC Address? Every device that connects to a network — a laptop, phone, router, anything — has a Network Interface Card (NIC) . That NIC comes with a MAC address : a permanent ID burned in by the manufacturer. If your laptop has an Ethernet port, the NIC lives right behind it. If you're connecting over Wi-Fi instead, the NI

Opinion: Your Tests Can't See What a Migration Destroys — Dry-Run It on a Clone A green test suite is the wrong tool for judging an AI-generated migration, because tests run against the post-migration schema and never observe the intermediate states where data disappears. The up migration is the visible artifact that gets reviewed, while the down migration is treated as an afterthought even though it is the only safety net when the deployment goes wrong. Free model access makes the problem structural: generation cost drops to zero, so migration volume rises, and every additional migration multiplies the surface for unreviewed data loss. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Tests validate the destination, not the journey When a test suite runs against a migrated database, it confirms that the application can read the new schema, but it cannot confirm that the migration preserved the data it was supposed to preserve. The test runner connects after the migration has executed, so it never sees the moment when a column is dropped, a table is renamed, or a constraint is silently relaxed. A migration that passes every test can still destroy production data, because the tests were designed to validate application behavior, not migration safety. The standard mitigation is a staging database, but staging is a poor substitute for a dry run because it has different data, different volume, and different usage patterns. The dry run I recommend uses a clone of the production schema with a representative data sample, and it exercises both directions of the migration with data integrity checks at every step. The clone does not need to be large; a few thousand rows per table is enough to expose most destructive patterns. The dry-run workflow in five steps The workflow is deliberately mechanical, because the goal is to remove judgment from the verification process and reserve human attention for the migration's intent: Clone the schema and lo

The organizations embracing hybrid agile models aren't making a principled methodological choice — most of them are just formalizing the mess they were already living in. Picture a delivery team at a mid-sized European bank. They run two-week Scrum sprints — daily standups, sprint reviews, the whole ceremony. They use Jira boards. They call themselves agile. And then, every quarter, a Release Approval Board convenes to review a 47-page change documentation package before anything goes to production. The sprints are agile theater. The real schedule is a Gantt chart that lives in somebody's SharePoint. Nobody says this out loud in the all-hands. They don't need to. This scenario — the sprint-shaped container wrapped around predictive, gate-controlled delivery — has quietly become the dominant operating model in software delivery. According to the 18th State of Agile Report, 74% of organizations now report using hybrid or homegrown models, mixing and matching agile with whatever else their org chart demands. The consulting firms have a polished name for it: hybrid delivery. The people living it often have a less flattering one. Here's the uncomfortable argument worth making: the rise of hybrid agile isn't evidence that organizations have matured past ideological purity. For many of them, it's evidence that they never committed to anything in the first place — and now have a framework-shaped fig leaf to cover that fact. The hybrid model is legitimate. Claiming you've adopted one when you've actually just left the org chart untouched while duct-taping Scrum on top? That's a different animal entirely. How We Got Here The path from "pure agile" to hybrid wasn't a straight line. It started with a real problem. As organizations tried to scale agile beyond small teams, limitations became visible — among them, agile's tendency to underweight documentation and its friction with physical product iteration cycles, both of which created compliance and maintenance headaches in regu

tailscale up --tun=userspace-networking gets you a green dot in the admin console and almost nothing else. The node appears in your tailnet, tailscale status looks healthy, and then you try to SSH into that container from your laptop and the connection hangs until TCP gives up. Two lines in the LXC config file fix it, and the container stays unprivileged. That's the whole post, really. But those two lines only make sense once you understand why every guide pushes you toward userspace mode in the first place, and what you're giving up by staying there. Who should care Anyone running services in unprivileged LXC containers on Proxmox who wants those containers to be real tailnet members with their own 100.64.0.0/10 address. Not reachable through something else. Reachable directly, over WireGuard, with a kernel network interface that ip addr can see. If you're already routing everything through a subnet router, you have a working setup and this is an optional upgrade. I covered that pattern in Tailscale Subnet Routers . Treat this as the next rung on the ladder: instead of one node advertising routes on behalf of everyone else, each container carries its own identity, its own ACL surface, and its own direct path to peers. What userspace networking actually costs you Every LXC-and-Tailscale guide I've read lands on the same instruction: pass --tun=userspace-networking and move on. It works because it sidesteps the problem entirely. Rather than asking the kernel for a TUN device, tailscaled runs a userspace TCP/IP stack (gVisor's netstack) inside its own process and never opens /dev/net/tun . Those costs stay invisible until you trip over one. Outbound traffic needs a proxy. In userspace mode, tailscaled exposes SOCKS5 and HTTP proxies on a local port. Nothing on the system routes to 100.64.0.0/10 automatically, because there is no interface and no route. Every client has to be told about the proxy: # userspace mode: this is the only way out export ALL_PROXY = socks5://l

Cloudflare, Astro, AI agents, GitHub Actions, issue triage, agentic AI, software architecture, open source, developer tools, AI automation, automated testing, human in the loop, agent workflows, GitHub, software engineering, AI software development, bug triage, continuous integration, developer productivity, autonomous agents, AI coding, Cloudflare Workers, Flue, triagebot By Leela Kumili

Technical Reconstruction of Toxic Work Culture Mechanisms Mechanisms and Their Impact Chains The evolution of workplace dynamics in large organizations has been marked by a pronounced shift from collaborative ecosystems to competitive arenas. This transformation is driven by specific mechanisms that, while often implemented with the intent to enhance productivity, inadvertently foster toxicity. Below, we dissect these mechanisms, their internal processes, and the observable effects they precipitate, elucidating the causal pathways that undermine organizational health. Performance Evaluation Systems Impact : Stackranking, hidden metrics, and PR/LoC counts incentivize individual competition, distorting the focus from collective goals to personal advancement. Internal Process : Employees, driven by survival instincts, prioritize outperforming peers over collaborative problem-solving, eroding the foundation of trust. Observable Effect : The erosion of trust and reduced team synergy directly correlate with diminished project outcomes and increased interpersonal conflicts. PIP Processes Impact : When PIP (Performance Improvement Plan) systems are weaponized punitively rather than utilized developmentally, they become tools of fear rather than growth. Internal Process : Employees perceive PIPs as existential threats, triggering stress responses that manifest as defensiveness and reduced engagement. Observable Effect : The resultant demoralization accelerates turnover rates, exacerbating recruitment costs and depleting institutional knowledge. Time Tracking Systems Impact : An overemphasis on quantifiable hours worked relegates quality and innovation to secondary priorities, fostering a culture of compliance over excellence. Internal Process : Employees, incentivized by logged hours, allocate effort disproportionately to tasks that maximize visibility rather than impact. Observable Effect : Despite inflated time logs, overall productivity declines as creative and strategic

VRP Is Ready for External Validation — Who Will Be the First to Pilot It? My name is Vitalijus Riabovas. I am the independent architect and creator of VRP — Veil Routing Protocol . VRP is a continuity-first networking architecture built around a simple principle: A logical session should not have to die simply because the network underneath it changed. Wi-Fi → LTE/5G. IP mutation. NAT / CGNAT churn. Temporary blackout. Path failure. Recovery. Replay attempts. Stale authority. Duplicate execution. For a long time, VRP was primarily architecture, runtime engineering and internal validation. That stage has changed. The public validation boundary exists now. And I am inviting serious engineers and organisations to test it. DON'T TRUST MY CLAIMS. TEST THEM. I am not asking the networking industry to believe a presentation. I built the measurement boundary. The public VRP Validation Kit provides engineers with an environment for evaluating observable behaviour independently. You can: clone the repository; run the Docker scenarios; inspect generated evidence; verify manifests and hashes; attack the evidence; delete events; duplicate events; reorder events; attempt replay; introduce stale conditions; corrupt artifacts; run the verifier; reproduce PASS / REJECT / INCOMPLETE outcomes. If you believe something is wrong, try to produce a reproducible contradiction. Give me: environment → scenario → commands → evidence → result That is useful engineering. WHAT HAS BEEN BUILT? VRP has moved far beyond an architectural diagram. The project now includes multiple engineering layers. Continuity architecture Logical session identity is designed to survive changes in the underlying network path. The architecture is being developed around continuity rather than assuming that transport identity and logical session identity must always be the same thing. Runtime The protected runtime implements the private VRP mechanisms. That implementation is not public . State and transition handling T

By RUGERO Tesla ( @404Saint ). IEC 60870-5-104 (IEC 104) is the TCP/IP-based member of the IEC 60870-5 telecontrol family. It was designed to carry SCADA telemetry and control information across packet-switched networks, particularly within electrical power systems. Before getting into raw packets, it is worth understanding how IEC 104 is structured, how its communication state is maintained, and where its security boundaries actually exist. This is the map before we meet the protocol on the wire. Protocol Stack IEC 104 operates over TCP, commonly using port 2404 . Two protocol components are particularly important: APCI : Application Protocol Control Information ASDU : Application Service Data Unit The APCI handles framing, sequencing, acknowledgments, and connection control. The ASDU carries the actual telecontrol information. +-------------------------------------------------------------+ | ASDU | | Type ID | VSQ | COT | CA | IOA | Information Objects | +-------------------------------------------------------------+ | APCI | | 0x68 | Length | Control 1 | Control 2 | Control 3 | Ctrl 4 | +-------------------------------------------------------------+ | TCP / IP | +-------------------------------------------------------------+ Every APDU begins with the 0x68 start byte, followed by a length field and four control bytes. The length represents the bytes following the length field, including the four control bytes and, when present, the ASDU. That fixed structure is the starting point for understanding IEC 104 traffic. I, S, and U Formats IEC 104 defines three APDU formats. I-Format: → I-format frames carry application information and therefore contain an ASDU. They also carry two sequence numbers: N(S) : send sequence number N(R) : receive sequence number These allow communicating stations to maintain ordered transmission and acknowledgment state. S-Format: → S-format frames are supervisory frames. They do not carry an ASDU. Their purpose is to communicate receive ac

James Arthur shares why sync is the next frontier in frontend architecture. He explains how extending reactivity to the server with Electric and TanStack DB replaces imperative fetching with declarative data bindings. Learn how query-driven sync and local optimistic updates enable engineering leaders to build insanely fast, collaborative, and agentic applications using their existing stack. By James Arthur

Subnetting errors rarely announce themselves as "bad math." More often, two devices make different decisions about whether a destination is local, a route points at the wrong boundary, or a cloud/VPN design contains two networks that cannot be unambiguously routed. These five failure modes are worth recognizing in live configurations. 1. The two hosts use different masks Consider Host A at 192.168.10.10/24 and Host B at 192.168.11.10/16 . A calculates that B is outside 192.168.10.0/24 , so A sends the packet to its default gateway. B calculates that A is inside 192.168.0.0/16 , so B treats A as local and tries ARP directly. The result can be asymmetric: one direction follows a router, while the reply is sent directly or never reaches the expected gateway. Check the actual prefix on both interfaces, not just the dotted decimal mask shown in a diagram. ip -br addr ip route ping -c 3 192.168.11.10 Correct the prefix so both endpoints agree, or intentionally route between two correctly defined subnets. 2. Overlapping subnets are assigned to different networks Suppose a branch uses 10.20.0.0/16 , while a cloud VPC or VPN peer also uses 10.20.0.0/16 . The problem is not that either mask is mathematically invalid. The problem is that a router cannot distinguish "the branch's 10.20.5.0/24 " from "the cloud's 10.20.5.0/24 " if both are reachable through different paths. Symptoms include traffic taking the wrong tunnel, routes that cannot be installed, or a VPN that connects but cannot reach some subnets. Inventory both sides of a tunnel and compare the complete network/prefix pairs. A longer, more specific route may make one destination appear to work while hiding the underlying overlap. ip route ip route get 10.20.5.25 traceroute -n 10.20.5.25 The durable correction is renumbering or using an intentional translation/design boundary. Adding increasingly specific routes is usually a brittle workaround. This is also why I prefer teaching subnetting inside routing and troublesh

This is a writeup of building a required CI gate for degraded-network behavior. The system under test is a robotics fleet substrate, but the finding applies to anyone shaping networks in CI. Ganglion exists to reach robots on networks nobody controls. Warehouse Wi-Fi, carrier CGNAT, a hospital VLAN, a customer firewall that was configured once in 2019 and has not been touched since. Until this week that claim was a sentence on a website. CI ran on clean loopback, everything was green, and the failure modes that actually matter in the field were the exact ones the test suite could never produce. That is now a required gate. Every push to main runs the full deploy, invoke and verify round trip over the relay against five shaped network profiles, and all five have to pass before anything merges. I build Ganglion, so treat the enthusiasm accordingly. The part worth your time is not that it went green. It is what I got wrong on the way there. The five profiles clean : baseline, no shaping. If this one fails, something else is broken. lossy : packet loss with light reordering. high-latency : 250ms round trip. asymmetric : plentiful downlink, starved uplink. This is the one nobody tests and the one teleop actually dies on, because control acknowledgements go the starved direction. nat-relay : endpoints with no route to each other at all, forcing hole punching to fail and relay fallback to carry the session. The last two are the ones I care about. Loss and latency are what people imagine a bad network is. Asymmetry and no-direct-route are what a bad network usually is. What I got wrong The original design assumed you can pin netem's seed and get a repeatable lossy run. Two profiles: a pinned-seed one that gates the build, and a nastier randomized one that runs nightly and is allowed to fail. You cannot pin netem's seed. Its loss and jitter draw from the kernel RNG and there is no seed parameter to set. A "deterministic lossy netem profile" is not a thing that exists. This m

Framework says it's replacing some out-of-warranty AMD mainboards.

Short version: An Application or Network Load Balancer costs ~$0.0225/hour, about $16/month, just to exist , plus capacity units. Classic Load Balancers run ~$18/month. Load balancers outlive the services behind them: the app gets torn down, the ALB keeps billing. Here's how to find load balancers with no real traffic or no healthy targets, and remove them safely. Why idle load balancers linger The hourly base charge is fixed - an ALB with zero requests bills the same ~$16/month as a busy one. Load balancers are usually created early (with an app or an IaC module) and deleted last, if ever. A handful of abandoned ALBs from old environments is real, recurring money. Step 1 - List load balancers and their traffic aws elbv2 describe-load-balancers \ --query 'LoadBalancers[].{Name:LoadBalancerName,Type:Type,ARN:LoadBalancerArn}' \ --output table For an ALB, check request volume over the last 7 days (the metric dimension is the tail of the ARN, e.g. app/my-alb/50dc6c495c0c9188 ): aws cloudwatch get-metric-statistics \ --namespace AWS/ApplicationELB \ --metric-name RequestCount \ --dimensions Name = LoadBalancer,Value = app/my-alb/50dc6c495c0c9188 \ --start-time " $( date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ ) " \ --end-time " $( date -u +%Y-%m-%dT%H:%M:%SZ ) " \ --period 86400 --statistics Sum \ --query 'Datapoints[].Sum' Near-zero request counts over a week is a strong idle signal. (For NLBs, use the AWS/NetworkELB namespace and ActiveFlowCount .) Step 2 - Check for empty or unhealthy target groups A load balancer with no healthy targets is doing nothing useful: for tg in $( aws elbv2 describe-target-groups \ --load-balancer-arn <lb-arn> \ --query 'TargetGroups[].TargetGroupArn' --output text ) ; do echo "== $tg ==" aws elbv2 describe-target-health --target-group-arn " $tg " \ --query 'TargetHealthDescriptions[].TargetHealth.State' --output text done Empty output (no targets) or all unhealthy alongside near-zero requests is a confident "delete me." Step 3 - Delete saf

A surprising share of "the app is down" pages resolve to a name-resolution problem, not a broken service. The service is fine; the client can't turn a name into an address. dig is the precision tool for proving that in seconds instead of guessing. Think about it as a resolution chain, not "is DNS broken" When a name fails, work the chain: which resolver did the client ask, what did that resolver return, and does it match what authoritative DNS actually says? Most incidents live in the gap between those three. The method is boring and reliable: observe the symptom, form a hypothesis about where in the chain it breaks, test with one query, read the evidence, fix, then validate. The single most important habit: query the name from the same host and the same resolver the app uses. Running dig from your laptop proves nothing about what the pod or VM sees. The record types worth knowing You don't need all of them, but you need to recognize them: A / AAAA — name to IPv4 / IPv6 address. The usual suspect. CNAME — an alias pointing at another name. A stale or wrong CNAME sends traffic somewhere unexpected. MX — mail routing. TXT — SPF, DKIM, domain verification, and other metadata. NS — which servers are authoritative for a zone. SOA — the zone's serial and TTL defaults; the serial tells you whether a change has propagated. PTR — reverse lookup, IP back to name. The commands that actually earn their place Start with the quick answer, then get precise. dig +short api.internal.example.com +short strips everything except the answer. If it prints an IP, resolution works from this host. If it prints nothing, you have a real failure to chase. Empty output is a signal, not an error. dig api.internal.example.com A The full form. Read the status in the header: NOERROR with an ANSWER section is good; NXDOMAIN means the name genuinely doesn't exist; SERVFAIL points at a broken upstream or DNSSEC issue. Also note which SERVER answered at the bottom — that's the resolver you're actually

The early website Hot or Not taught its users to rank people at scale. Twenty-six years later, dating apps are trying to escape the culture the site helped create.

The tunnel comes up. wg show prints a recent handshake. The client has its address inside the tunnel. And not a single byte reaches the internet. Almost every guide answers this with "open UDP 51820 in the firewall". You already did that — it is why the handshake works at all. The problem is somewhere else, and UFW makes the distinction easy to miss: Entering a machine and traversing it are two different permissions. ufw allow 51820/udp lets packets arrive at the server. Your clients' traffic does not stop there — it goes through the box and out the public interface. That path lives in the FORWARD chain, which UFW denies by default and which no allow rule touches. The four things to check, in order 1. IP forwarding — and the file that overwrites the other file This is the one that costs hours, because the setting looks done. UFW loads its own sysctl file at startup, and it takes precedence over the system one. A value you carefully set in /etc/sysctl.conf can be silently overwritten on the next ufw enable . The right place is /etc/ufw/sysctl.conf : net / ipv4 / ip_forward = 1 net / ipv6 / conf / default / forwarding = 1 net / ipv6 / conf / all / forwarding = 1 Then check the effective value, not the file you just edited: sysctl net.ipv4.ip_forward 2. Forwarding, which is not the same as ingress Targeted, and the one to prefer: sudo ufw route allow in on wg0 out on eth0 Or globally, in /etc/default/ufw : DEFAULT_FORWARD_POLICY = "ACCEPT" The second opens forwarding for every interface. It is a good ten-second diagnostic and a poor permanent configuration. 3. NAT, which UFW never adds on its own Without it, packets leave carrying their tunnel address, which nothing on the internet knows how to answer. In /etc/ufw/before.rules , at the very top , before the *filter line: *nat :POSTROUTING ACCEPT [0:0] -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE COMMIT Two classic mistakes here: putting this block after *filter (it is then ignored), and copying eth0 without chec