-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathexample.config.yaml
78 lines (71 loc) · 3.4 KB
/
example.config.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
sentry: https://public@sentry.example.com/1
web:
# this is the domain part of the web gateway. The generated tunnel name will be
# something like: dramatize-detergent-donator-mutable-election.tunnel.example.com
# note: this domain name must be part of the acme.provider.rfc2136.zone below
domain: tunnel.example.com
# the gateway port can be specified with -gatewayPort (default to 443). Note that
# this port is used for both visitors and the clients, and for both TCP and UDP
# certificate for the gateway and client connection will be issued by Let's Encrypt.
# until a certificate is issued, gateway and client will not be usable. However,
# once you bootstrap the leader node, the follower nodes will receive the certificates
# via state synchronization
acme:
# this is used for automatic certificate issurance. Any RFC8555 complaint CA
# that supports dns-01 challenge will work.
# the following directory is used for testing. change the directory to https://acme-v02.api.letsencrypt.org/directory
# when you are ready to issue usable Let's Encrypt certificates
directory: https://acme-staging-v02.api.letsencrypt.org/directory
contact: mailto:your@domain.name
# this directory will store the account key on each of the peer. A leader election
# will be held, and only the leader will have permission to request certificates and
# distribute the certificates to other peers.
# however, since any of the peers can become leader, the key will be shared to other peers
# via encrypted peer channel.
dataDir: /path/to/safe/storage
provider:
# currently, only RFC2136 dns provider is supported
rfc2136:
# note: if your domain root is example.com, but you want to have tunnels
# at *.tunnel.example.com, the certificate will be issued to *.tunnel.example.com
zone: example.com
tsigKey: sign.
tsigSecret: yoursecrethere==
tsigAlgo: hmac-sha256.
nameserver: dns.example.com:53
network:
# this should be publicly accessible for other peers and clients
advertiseAddr: 127.0.0.1
# the address that t should bind to
bindAddr: 0.0.0.0
multiplexer:
# if left to 0, a random port will be used. Peers will be discovered via Gossip
# if you are running in docker, it's better to have a defined port so you can expose it
peer: 0
# protocol for inter-peer communication. 1: Yamux, 2: Mplex, 3: QUIC
# client can specify the protocol when connecting with -protocol argument
protocol: 3
# sets this peer to respond to peer connection only and never initiate outgoing connection.
# this is useful where other peers are communicating via QUIC, but this peer is behind
# firewall that does not work with UDP hole punching, and can be only connected via TCP.
respondOnly: false
tls:
# peer certificates should be self-signed with "server auth" and "client auth"
# additionally, one of the SANs must be "t_Peer" (case sensitive)
# I recommend using cfssl if you are new to self-signing
peer:
ca: tls/ca.pem
cert: tls/peer.pem
key: tls/peer-key.pem
gossip:
port: 12345
keyring:
# can be generated with: openssl rand -base64 32
# must have at least one keyring to encrypt gossip traffic
- MxXOrj7VlgqtPEp5SLYXmr6PzZ9CCQEp3bQhvnLBBA0=
- ByZZSrG7ejvp271SRG3JfP1peK/9c+iuRMio+Ow0y8c=
# specify one of the peers is enough as they will discover each other via gossip
members:
- 127.0.0.1:12345
- 127.0.0.1:12346
- 127.0.0.1:12347