WebTunnel is available on the entry nodes the platform has opened it for, node by node. On any other node the Settings show no WebTunnel box.
It is one more line for the routes through your entry. To a network it looks like an ordinary website on your own domain: a real certificate, and a plain "not found" page for anyone who asks for the wrong address. Your entry only reads the name in each connection and forwards the encrypted bytes to the exit, which ends the TLS, so neither the entry nor its hosting company can read what passes. The line is the route's own session at the route's price: what a user pays and an operator earns does not change.
Which links carry it
A link carries WebTunnel only when its entry and its exit are both yours and both run an agent that supports it. Each such link gets a name of its own under your domain, and the names say nothing about the exit. Each of those exits restarts its Xray once when the first name reaches it, and once more when WebTunnel is turned off, which briefly cuts the connections on that exit; while it holds names, it also restarts its Xray at each start of its agent, up to three times within seconds on an exit that also runs Hysteria2 and XHTTP.
What you set up
- An extra IPv4 address on this server, and an IPv6 one if the server has one, other than the address the node is registered at. Ask your hosting company for it. Put it into the server's own network configuration, not only on the running interface, so that it is still there after a reboot: if the address disappears, the line stops until it is back. Add it as a secondary address: the server's own connections keep leaving from the address the node is registered at, because nothing the server sends may come from the extra address (the agent's filter on it judges each packet alone, and would drop the replies).
- TCP 80 and 443 open on that address, and only on it, in your hosting company's firewall and in the server's own, if it has one: a rule for that address and not for the whole port, so that the address the node is registered at answers on port 80 as it did before. The agent opens no firewall of the host; on that address it lets in only TCP 80, TCP 443 and ICMP, and drops everything else. Port 80 is for the certificate checks and 443 is the line.
- A domain you control, such as
ru1.example.com. It cannot be under proofkit.org, and no other node can use it, or a domain above or below it, for WebTunnel. Use a domain of its own for each entry. - Two DNS records at that domain's DNS provider. The box prints them, ready to copy:
*.ru1.example.com. A 203.0.113.7
ru1.example.com. CAA 0 issue "letsencrypt.org; accounturi=<account URL from the box>"The first record sends every name under the domain to the extra address (add an AAAA record the same way for an IPv6 address). Create it DNS only, with no CDN proxy: on Cloudflare, the grey cloud. The second is the CAA record, and its text is the same for every operator: it lets Let's Encrypt issue certificates for your names to ProofKit's account and to nobody else. Without it, anyone who controls port 80 on the address, your hosting company included, could get a certificate for your names and read the line, so the box serves nothing until it is there. A CAA record that lets another issuer or another account issue fails the check too.
What the box checks
Tick WebTunnel in the entry's Settings, fill in the domain and the address, and save. The box prints the records for your domain and runs four checks at once, then again every 6 hours while they pass and every 10 minutes while one fails, so a fix shows within minutes:
- Address. The address is on the server (the agent says so), and it is neither the address the node is registered at nor another node's.
- DNS record. A name under the domain resolves to the address.
- CAA record. The CAA records that apply to names under the domain let only ProofKit's account issue.
- Port 80. Port 80 on the address answers a test: the entry answers a token sent through that address. Something else answering there, a web server, a redirect or a proxy in front of the entry, fails it.
A failing check says what to fix. The box also counts the entry's links that are ready: a link is ready when its exit holds the certificate for its name and all four checks pass.
Certificates
ProofKit orders a certificate for each name from Let's Encrypt under its own account and renews it well before it ends, so you do nothing. The exit makes the key and the key never leaves it. A line reaches users only while its certificate is live and every check passes; if a record drifts, the lines leave until it is right again and then come back by themselves.
Who receives the line
A user's list carries it only when the user chose WebTunnel (or All) in the subscription settings and has a route through your entry that serves it. A partner's subscribers get it only when that partner ticks WebTunnel among its transports, which is off until the partner does.
Turning it off, and changing it
Untick the box and the lines leave the lists at their next refresh, and the names and certificates are dropped; the domain and the addresses stay saved for next time. Another domain or address gives every link a new name and a new certificate.
WebTunnel has an address of its own so that a block of that address or of the domain takes nothing else of the entry with it: the node's main address serves everything else as before.