Pavel

On the debug flag: kubectl does have verbosity, it is -v with a number. kubectl get nodes -v=8 shows the full request and response including headers, which tells you which credential was actually presented and what the server said about it.

At -v=9 you get request bodies too. It is a lot of output, but for authentication problems the useful part is right at the top — the TLS handshake and the identity being offered.

The comment line at the top of the generated file told me immediately which manager I had. Should have read the file before editing it.

If you specifically want to take manual control and stop anything managing it, that is a legitimate configuration and it is worth doing deliberately rather than by fighting the tooling.

The general shape is: disable or mask whichever manager is writing the file, replace the symlink with a real file, and put your servers in it. On systems using the stub resolver, /etc/resolv.conf is a symlink into a generated directory — replacing the symlink is the actual step people miss, because editing through the symlink edits the generated file.

Be aware of what you give up. The stub resolver provides caching, per-interface DNS and DNSSEC handling. On a VPS with a single interface you probably do not care. On anything with a VPN, you will care immediately, because split DNS stops working and you lose name resolution for internal hosts the moment the tunnel comes up.

Useful debugging note since you mentioned there is no extra-verbose flag: there is, it is just repeated. ssh -vvv gives three levels, and the negotiation section shows both sides' offered lists side by side.

Reading those two lists next to each other turns this class of problem from guesswork into a set intersection you can do by eye, and it tells you immediately which negotiation stage is failing rather than which one you assumed.

Diagnostic worth knowing for this family of errors: the runtime's own command line client can query the CRI endpoint directly and report the version it serves.

Running that against the socket the kubelet is configured to use answers the question in one step — you see which API versions the endpoint actually offers, rather than inferring it from a failure. It also confirms you have the right socket path, which is the other half of this error's population.

That last property is the thing that makes WireGuard hard to debug and it is worth understanding explicitly: it is silent by design. An invalid packet gets no reply, no error, no log line. From outside, "wrong key" and "packets never arrived" look the same.

So the diagnostic order should be to establish reachability before questioning configuration:

1. Capture on the receiving side. If you see UDP arriving on the port from the other peer's address, the network path works and the problem is cryptographic or configuration. If you see nothing, stop looking at the config.
2. Check the source address in that capture against what the sending peer thinks its endpoint is. NAT rewrites it, and a mismatch here explains a lot of one-way setups.
3. Enable the module's debug logging. WireGuard can log handshake attempts to the kernel log, which turns the silence into something readable and will tell you if it is rejecting a peer.

Most of these are solved by step 1 telling you which half of the problem to look at.

One diagnostic tip for next time, since the symptom presented as a network problem: when a hostname stops resolving, check whether it resolves from anywhere before investigating your own DNS.

A public resolver, a phone on mobile data, or an online lookup tool answers in seconds. If the name is dead globally, you are looking at somebody else's decision rather than your own configuration, and that reframes the whole investigation immediately.