Writing a TCP/UDP server type for Caddy


(Matt Holt) #42

Awesome! I have a domain you can borrow, just let me know which IP to point it at. You’ll have to make sure ports 80 and 443 are forwarded within your home to your computer. You can DM me the IP address.

Edit: Either host or hosts is fine! They are both better than tlshost(s).

tls.NewListener() returns an unstarted listener, but tls.Listen() is a started listener. You want an unstarted one.


(Matthew Fay) #43

Also might just point out that this mob do free short term domain registrations, great for testing stuff.

http://www.dot.tk/


(Miek Gieben) #44

I can give you a subdomain under miek.nl, coredns.io or dnssex.nl (last one if a personal favorite :slight_smile: )

Let me know your IP and what name you want at miek@miek.nl (you should have a static home IP of course)


(Matthew Fay) #45

Ha, very nice.


(Pieter Louw) #47

I have created a domain for myself now.I created an A DNS record echo.leastsignificantbit.co.za and pointed it to a Google VM server external IP Address. After that I setup caddy with the net plugin on the server with the following Caddyfile:

echo :12017 {
    host echo.leastsignificantbit.co.za
}

I start caddy with the net plugin and Let’s Encrypt prompts for my email. After that I receive an error: 2017/03/31 22:44:01 [echo.leastsignificantbit.co.za] failed to get certificate: [echo.leastsignificantbit.co.za] error presenting token: Could not start HTTPS server for challenge -> listen tcp :443: bind: permission denied [EDIT: after tracking this message in the source code it looks like it’s a message from the ACME client]

I do have port 443 open on the server firewall, but nothing is listening on that port.

I tried the same on my dev machine behind my personal internet after pointing the dns record to my personal internet IP address but I get the same error.


(Matt Holt) #48

You need to make sure you give Caddy permission to bind to low ports; setcap can do this (see FAQ) or you can just run as root.


(Pieter Louw) #49

Thanks @matt,
I run as root (sudo) now but get a different error now:
failed to get certificate: acme: Error 400 - urn:acme:error:connection - Could not connect to echo.leastsignificantbit.co.za

I pointed the domain above to my local internet and forwarded port traffic to my laptop.

Also, when if I dig +short echo.leastsignificantbit.co.za I get the correct IP address.

I tried to a different server (running on Google cloud) and pointed play.leastsignificantbit.co.za to the external IP on that server. When I run caddy on there I get a different (but similar) error:
failed to get certificate: acme: Error 400 - urn:acme:error:connection - DNS problem: NXDOMAIN looking up A for play.significantbit.co.za

Again, if I dig +short play.leastsignificantbit.co.za I get the correct IP address.

If I switch off tls in the Caddyfile I can telnet into both domain names and on the listening port.

Any ideas what I might be doing wrong? Could it be something to do with my hosting company and their DNS?


(Matt Holt) #50

For ACME-related errors, there’s more output than that, there should be more lines saying what the result of their DNS lookup was, etc. But yeah, so far it looks like they had trouble connecting to your machine.

Want me to try it? DM me when you want me to try connecting from my machine. If I can’t, then it’s definitely an issue with your network configuration.


(Matthew Fay) #51

failed to get certificate: acme: Error 400 - urn:acme:error:connection - Could not connect to echo.leastsignificantbit.co.za

This means that the ACME server found a server on the other end of echo.leastsignificantbit.co.za, but couldn’t open a HTTP(S) connection to it.

This one is different - it tells me that your own DNS server is updating quicker than the one that LetsEncrypt is using for their ACME servers. I expect the solution will be to wait for a little while for DNS propagation to complete.

I don’t know if LE uses Google’s public DNS or not, but anecdotally, I’ve found that if dig @8.8.8.8 +short example.com resolves, LetsEncrypt can run it.


(Matt Holt) #52

I believe LE does an authoritative lookup each time. Some providers take hours to apply changes though, regardless of propagation.


(Matthew Fay) #53

Good point, but if he can dig it and get the right response, at very least the name servers and his DNS server must be updated, right?


(Pieter Louw) #54

I finally have success!

Not sure what fixed it but It seems I just had to wait a while after I made the changes for the domain names.

So in summary, this plugin can:

  • Echo UDP/TCP traffic back
  • Proxy UDP/TCP traffic to a specified destination (which for now is basically just a port forwarder I guess)
  • Works on all the possible tls options (tls off, tls cert key, tls self_signed and auto tls using LE)

Pieter


(Michael) #55

Just a nice gimmick.

One can flush the cache from Google Public DNS:
https://developers.google.com/speed/public-dns/cache


(Matt Holt) #56

Excellent, this is great news!! My home internet just come back online, so when I get a chance I will take a look. But don’t let me slow you down!

As you prepare to make this available, remember to start simple. Only include by default the plugins / directives that should be included in core; the rest can be external if you wish.

Have I given you access to the new Caddy website yet? If not, I will DM you with the information so you can submit it there when you are ready.


(Matt Holt) #57

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.