Add nil checks for WireGuard beacon to prevent crashes

[nf-works]

Card

Related to #1818.

My knowledge in Go is rather limited, but I still wanted to give contributing towards a more stable implant a try since the crash I'm experiencing and was able to reproduce with a debug build, which is the most severe issue at hand, should easily be fixed.

However, it is not taking into account what the reason for the connection being nil is, which might be something worth looking into itself.

I ran gofmt -w beacon.go and go generate in the implant directory. Commit is signed. I hope I did it all correctly. The tests failed at some totally unrelated stuff in the final step. Sorry, I can't get them to work right now. Someone else will have to run them, but I doubt there is going to be an issue.

Details

Unlike, for instance, with MTLS, there is no check for nil. I added it and used early returns. I figured that there could potentially be issues with the device too, so I added checks for it preemptively.

Executing the new beacon for a first test
As a first sanity check, I ran ls with a fresh beacon generated with my server, compiled from updated source. No issue.

I continued with the problematic command:

download --timeout 600 [250 MB FILE]

Sent 20:35:34 UTC, completed 20:46:47 UTC. The file was received, which is nice to have, but most importantly, the implant didn't crash.

I tried again right away without the timeout set manually.
Sent 20:48:51 UTC , not completed until 21:20, potentially never would have. However, no crash here either.

Retesting the old beacon to verify the issue is still reproducible
After two successes in regard to crash behavior, I ran a beacon without my fix.
First attempt was download --timeout 600 [250 MB FILE] again.
No file received, beacon crashed after roughly 9 minutes. Thankfully, this is still very reproducible.

Tried it again without timeout set manually.
No file received, beacon crashed after roughly 18 minutes.

Reverifying one last time with the updated beacon
I went back to my fixed implant one last time and ran the very same command that crashed a minute ago. No crash. File was received within roughly 4 minutes. Yet another run with the timeout, no crash, file received after 5 minutes.

[nf-works]

After reading rkervella's comment, I looked into the current master. The close handler looks the same. I would imagine that there might be improvements higher up in the execution flow, which might cause it not to be nil, but it would probably make sense to also include the fix there. Should I make a separate PR for that?

Regarding the failed workflow, I don't really think the code changes would cause this. I'm honestly having a hard time even extracting a precise error from the long log.