A tool to help to connect UDP server behind LAN.
- optimize for realtime, < 2s per reverse hole.
- Zero protocol overhead, extremely fast.
- 1-rtt, punch then exit, no daemonize.
- Publish over udp option, fire-and-drop.
- No associate punching server(with ntfy.sh or selfhost)
Data Stream:
UDP client(schedule link2lan) -> Internet(raw protocol) -> UDP server(ntfy subscription trigger)
Option 1: Signal via NTFY:
link2lan(addr from stun) -> ntfy server(deploy addr info) <- ntfy-cli(addr from stun)
Option 2: Signal via UDP:
link2lan --plan 1xx --cryptkey key -> link2lan --plan 213 --localstr "0.0.0.0:44345"" --cryptkey key --cmdpath "/path/to/handler"
If you publish via NTFY, the ntfy topic is your private SECRETE, we send plain text to that topic! Transportation is secured by HTTPS. If you don't trust public service, setup your own ntfy.sh service, also unlock rate limit.
If you publish via udp, you MUST run link2lan with --cryptkey on both server and client, and keep the system time synced, it is an encryption factor.
udpdeminer is a scheduler to trigger Link2Lan in the cookbook, you can use another alternative application to use the Link2Lan output in a format of destip:dport-sport.
NAT(UDP client) -> >>> Internet(raw protocol) >>> -> PubIP(UDP server)
Case 1, Reverse connection:
PubIP(client) -> <<< Internet(raw protocol) <<< -> NAT(server)
PubIP(client) -> <<< Internet(raw protocol) <<< -> NAT(relay) -> PubIP(server)
Case 2, Nat Punch, experimental, unstable:
NAT3(client) -> <<< Internet(raw protocol) <<< -> NAT3(server)
NAT3(client) -> <<< Internet(raw protocol) <<< -> NAT3(relay) -> PubIP(server)
Case 3, Reverse, over WARP, protect server:
PubIP(client) -> <<< Internet(raw protocol) <<< WARP(udp over warp) -> NAT(server)
Case 4: Delivery address info via NTFY or UDP.
example: door opening, DDNS updating.
Case 5: Your personal magic combination.