public/headscale
1
0 Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-11-04 04:34:07 +09:00
Code Issues Packages Projects Releases Wiki Activity

Deployed d0e10f2d to development with ProperDocs 1.6.7 and mike 2.2.0

Browse Source
This commit is contained in:
github-actions committed 2026-11-02 19:35:59 +00:00
1 parent fba2d78143
commit 251f8caaff
3 files changed
+3 -3
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

development/ref/derp/index.html
+1 -1
View File
@@ -9,7 +9,7 @@
</span><span id=__span-1-4><a id=__codelineno-1-4 name=__codelineno-1-4 href=#__codelineno-1-4></a><span class=w> </span><span class=nt>ipv4</span><span class=p>:</span><span class=w> </span><span class="l l-Scalar l-Scalar-Plain">198.51.100.1</span>
</span><span id=__span-1-5><a id=__codelineno-1-5 name=__codelineno-1-5 href=#__codelineno-1-5></a><span class=w> </span><span class=nt>ipv6</span><span class=p>:</span><span class=w> </span><span class="l l-Scalar l-Scalar-Plain">2001:db8::1</span>
</span><span id=__span-1-6><a id=__codelineno-1-6 name=__codelineno-1-6 href=#__codelineno-1-6></a><span class=hll><span class=w> </span><span class=nt>urls</span><span class=p>:</span><span class=w> </span><span class="p p-Indicator">[]</span>
</span></span></code></pre></div> <div class="admonition warning"> <p class=admonition-title>Single point of failure</p> <p>Removing Tailscale's DERP servers means that there is now just a single DERP server available for clients. This is a single point of failure and could hamper connectivity.</p> <p><a href=#check-derp-server-connectivity>Check DERP server connectivity</a> with your embedded DERP server before removing Tailscale's DERP servers.</p> </div> <h3 id=customize-derp-map>Customize DERP map<a class=headerlink href=#customize-derp-map title="Permanent link">&para;</a></h3> <p>The DERP map offered to clients can be customized with a <a href=https://github.com/juanfont/headscale/blob/main/derp-example.yaml>dedicated YAML-configuration file</a>. The file extension picks the format: <code>.yaml</code> or <code>.yml</code>, or the JSON format Tailscale serves DERP maps in as <code>.json</code> or <code>.hujson</code>. This allows to modify previously loaded DERP maps fetched via URL or to offer your own, custom DERP servers to nodes.</p> <div class="tabbed-set tabbed-alternate" data-tabs=1:2><input checked=checked id=__tabbed_1_1 name=__tabbed_1 type=radio><input id=__tabbed_1_2 name=__tabbed_1 type=radio><div class=tabbed-labels><label for=__tabbed_1_1>Remove specific DERP regions</label><label for=__tabbed_1_2>Provide custom DERP servers</label></div> <div class=tabbed-content> <div class=tabbed-block> <p>The free-to-use <a href=https://tailscale.com/docs/reference/derp-servers>DERP servers</a> are organized into regions via a region ID. You can explicitly disable a specific region by setting its region ID to <code>null</code>. The following sample <code>derp.yaml</code> disables the New York DERP region (which has the region ID 1):</p> <div class="language-yaml highlight"><span class=filename>derp.yaml</span><pre><span></span><code><span id=__span-2-1><a id=__codelineno-2-1 name=__codelineno-2-1 href=#__codelineno-2-1></a><span class=nt>regions</span><span class=p>:</span>
</span></span></code></pre></div> <div class="admonition warning"> <p class=admonition-title>Single point of failure</p> <p>Removing Tailscale's DERP servers means that there is now just a single DERP server available for clients. This is a single point of failure and could hamper connectivity.</p> <p><a href=#check-derp-server-connectivity>Check DERP server connectivity</a> with your embedded DERP server before removing Tailscale's DERP servers.</p> </div> <h3 id=customize-derp-map>Customize DERP map<a class=headerlink href=#customize-derp-map title="Permanent link">&para;</a></h3> <p>The DERP map offered to clients can be customized with a <a href=https://github.com/juanfont/headscale/blob/main/derp-example.yaml>dedicated YAML-configuration file</a>. The file extension picks the format: <code>.yaml</code> or <code>.yml</code>, or the JSON format Tailscale serves DERP maps in as <code>.json</code> or <code>.hujson</code>. Both JSON extensions are read as <a href=https://github.com/tailscale/hujson>HuJSON</a>, so comments and trailing commas are allowed. This allows to modify previously loaded DERP maps fetched via URL or to offer your own, custom DERP servers to nodes.</p> <div class="tabbed-set tabbed-alternate" data-tabs=1:2><input checked=checked id=__tabbed_1_1 name=__tabbed_1 type=radio><input id=__tabbed_1_2 name=__tabbed_1 type=radio><div class=tabbed-labels><label for=__tabbed_1_1>Remove specific DERP regions</label><label for=__tabbed_1_2>Provide custom DERP servers</label></div> <div class=tabbed-content> <div class=tabbed-block> <p>The free-to-use <a href=https://tailscale.com/docs/reference/derp-servers>DERP servers</a> are organized into regions via a region ID. You can explicitly disable a specific region by setting its region ID to <code>null</code>. The following sample <code>derp.yaml</code> disables the New York DERP region (which has the region ID 1):</p> <div class="language-yaml highlight"><span class=filename>derp.yaml</span><pre><span></span><code><span id=__span-2-1><a id=__codelineno-2-1 name=__codelineno-2-1 href=#__codelineno-2-1></a><span class=nt>regions</span><span class=p>:</span>
</span><span id=__span-2-2><a id=__codelineno-2-2 name=__codelineno-2-2 href=#__codelineno-2-2></a><span class=w> </span><span class=nt>1</span><span class=p>:</span><span class=w> </span><span class="l l-Scalar l-Scalar-Plain">null</span>
</span></code></pre></div> <p>Use the following configuration to serve the default DERP map (excluding New York) to nodes:</p> <div class="language-yaml highlight"><span class=filename>config.yaml</span><pre><span></span><code><span id=__span-3-1><a id=__codelineno-3-1 name=__codelineno-3-1 href=#__codelineno-3-1></a><span class=nt>derp</span><span class=p>:</span>
</span><span id=__span-3-2><a id=__codelineno-3-2 name=__codelineno-3-2 href=#__codelineno-3-2></a><span class=w> </span><span class=nt>server</span><span class=p>:</span>
development/ref/dns/index.html
+1 -1
View File
@@ -21,7 +21,7 @@
</span><span id=__span-1-10><a id=__codelineno-1-10 name=__codelineno-1-10 href=#__codelineno-1-10></a><span class=w> </span><span class=nt>"value"</span><span class=p>:</span><span class=w> </span><span class=s2>"100.64.0.3"</span>
</span><span id=__span-1-11><a id=__codelineno-1-11 name=__codelineno-1-11 href=#__codelineno-1-11></a><span class=w> </span><span class=p>}</span>
</span><span id=__span-1-12><a id=__codelineno-1-12 name=__codelineno-1-12 href=#__codelineno-1-12></a><span class=p>]</span>
</span></code></pre></div> <p>Headscale picks up changes to the above JSON file automatically.</p> <div class="admonition tip"> <p class=admonition-title>Good to know</p> <ul> <li>The <code>dns.extra_records_path</code> option in the <a href=../configuration/ >configuration file</a> needs to reference the file containing extra DNS records. Its extension picks the format: <code>.json</code>, <code>.hujson</code>, <code>.yaml</code> or <code>.yml</code>.</li> <li>Be sure to "sort keys" and produce a stable output in case you generate the JSON file with a script. Headscale uses a checksum to detect changes to the file and a stable output avoids unnecessary processing.</li> </ul> </div> </div> </div> </div> </li> <li> <p>Verify that DNS records are properly set using the DNS querying tool of your choice:</p> <div class="tabbed-set tabbed-alternate" data-tabs=2:2><input checked=checked id=__tabbed_2_1 name=__tabbed_2 type=radio><input id=__tabbed_2_2 name=__tabbed_2 type=radio><div class=tabbed-labels><label for=__tabbed_2_1>Query with dig</label><label for=__tabbed_2_2>Query with drill</label></div> <div class=tabbed-content> <div class=tabbed-block> <div class="language-console highlight"><pre><span></span><code><span id=__span-2-1><a id=__codelineno-2-1 name=__codelineno-2-1 href=#__codelineno-2-1></a><span class=go>dig +short grafana.myvpn.example.com</span>
</span></code></pre></div> <p>Headscale picks up changes to the above JSON file automatically.</p> <div class="admonition tip"> <p class=admonition-title>Good to know</p> <ul> <li>The <code>dns.extra_records_path</code> option in the <a href=../configuration/ >configuration file</a> needs to reference the file containing extra DNS records. Its extension picks the format: <code>.json</code>, <code>.hujson</code>, <code>.yaml</code> or <code>.yml</code>. A <code>.json</code> file is read as <a href=https://github.com/tailscale/hujson>HuJSON</a>, so it may contain comments and trailing commas.</li> <li>Be sure to "sort keys" and produce a stable output in case you generate the JSON file with a script. Headscale uses a checksum to detect changes to the file and a stable output avoids unnecessary processing.</li> </ul> </div> </div> </div> </div> </li> <li> <p>Verify that DNS records are properly set using the DNS querying tool of your choice:</p> <div class="tabbed-set tabbed-alternate" data-tabs=2:2><input checked=checked id=__tabbed_2_1 name=__tabbed_2 type=radio><input id=__tabbed_2_2 name=__tabbed_2 type=radio><div class=tabbed-labels><label for=__tabbed_2_1>Query with dig</label><label for=__tabbed_2_2>Query with drill</label></div> <div class=tabbed-content> <div class=tabbed-block> <div class="language-console highlight"><pre><span></span><code><span id=__span-2-1><a id=__codelineno-2-1 name=__codelineno-2-1 href=#__codelineno-2-1></a><span class=go>dig +short grafana.myvpn.example.com</span>
</span><span id=__span-2-2><a id=__codelineno-2-2 name=__codelineno-2-2 href=#__codelineno-2-2></a><span class=go>100.64.0.3</span>
</span></code></pre></div> </div> <div class=tabbed-block> <div class="language-console highlight"><pre><span></span><code><span id=__span-3-1><a id=__codelineno-3-1 name=__codelineno-3-1 href=#__codelineno-3-1></a><span class=go>drill -Q grafana.myvpn.example.com</span>
</span><span id=__span-3-2><a id=__codelineno-3-2 name=__codelineno-3-2 href=#__codelineno-3-2></a><span class=go>100.64.0.3</span>
development/search/search_index.json
+1 -1
View File
@@ -1 +1 @@
{"config":{"lang":["en"],"separator":"[\\s\\-,:!=\\[\\]()\"`/]+|\\.(?!\\d)|&[lg]t;|(?!\\b)(?=[A-Z][a-z])","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Welcome to headscale","text":"<p>Headscale is an open source, self-hosted implementation of the Tailscale control server.</p> <p>This page contains the documentation for the latest version of headscale. Please also check our FAQ.</p> <p>Join our Discord server for a chat and community support.</p>"},{"location":"#design-goal","title":"Design goal","text":"<p>Headscale aims to implement a self-hosted, open source alternative to the Tailscale control server. Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. It implements a narrow scope, a single Tailscale network (tailnet), suitable for a personal use, or a small open-source organisation.</p>"},{"location":"#supporting-headscale","title":"Supporting headscale","text":"<p>Please see Sponsor for more information.</p>"},{"location":"#contributing","title":"Contributing","text":"<p>Headscale is \"Open Source, acknowledged contribution\", this means that any contribution will have to be discussed with the Maintainers before being submitted.</p> <p>Please see Contributing for more information.</p>"},{"location":"#about","title":"About","text":"<p>Headscale is maintained by Kristoffer Dalby and Juan Font.</p>"},{"location":"about/clients/","title":"Client and operating system support","text":"<p>We aim to support the last 10 releases of the Tailscale client on all provided operating systems and platforms. Some platforms might require additional configuration to connect with headscale.</p> OS Supports headscale Linux Yes OpenBSD Yes FreeBSD Yes Windows Yes (see docs and <code>/windows</code> on your headscale for more information) Android Yes (see docs for more information) macOS Yes (see docs and <code>/apple</code> on your headscale for more information) iOS Yes (see docs and <code>/apple</code> on your headscale for more information) tvOS Yes (see docs and <code>/apple</code> on your headscale for more information)"},{"location":"about/contributing/","title":"Contributing","text":"<p>Headscale is \"Open Source, acknowledged contribution\", this means that any contribution will have to be discussed with the maintainers before being added to the project. This model has been chosen to reduce the risk of burnout by limiting the maintenance overhead of reviewing and validating third-party code.</p>"},{"location":"about/contributing/#why-do-we-have-this-model","title":"Why do we have this model?","text":"<p>Headscale has a small maintainer team that tries to balance working on the project, fixing bugs and reviewing contributions.</p> <p>When we work on issues ourselves, we develop first hand knowledge of the code and it makes it possible for us to maintain and own the code as the project develops.</p> <p>Code contributions are seen as a positive thing. People enjoy and engage with our project, but it also comes with some challenges; we have to understand the code, we have to understand the feature, we might have to become familiar with external libraries or services and we think about security implications. All those steps are required during the reviewing process. After the code has been merged, the feature has to be maintained. Any changes reliant on external services must be updated and expanded accordingly.</p> <p>The review and day-1 maintenance adds a significant burden on the maintainers. Often we hope that the contributor will help out, but we found that most of the time, they disappear after their new feature was added.</p> <p>This means that when someone contributes, we are mostly happy about it, but we do have to run it through a series of checks to establish if we actually can maintain this feature.</p>"},{"location":"about/contributing/#what-do-we-require","title":"What do we require?","text":"<p>A general description is provided here and an explicit list is provided in our pull request template.</p> <p>All new features have to start out with a design document, which should be discussed on the issue tracker (not discord). It should include a use case for the feature, how it can be implemented, who will implement it and a plan for maintaining it.</p> <p>All features have to be end-to-end tested (integration tests) and have good unit test coverage to ensure that they work as expected. This will also ensure that the feature continues to work as expected over time. If a change cannot be tested, a strong case for why this is not possible needs to be presented.</p> <p>The contributor should help to maintain the feature over time. In case the feature is not maintained probably, the maintainers reserve themselves the right to remove features they redeem as unmaintainable. This should help to improve the quality of the software and keep it iLine truncated
{"config":{"lang":["en"],"separator":"[\\s\\-,:!=\\[\\]()\"`/]+|\\.(?!\\d)|&[lg]t;|(?!\\b)(?=[A-Z][a-z])","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Welcome to headscale","text":"<p>Headscale is an open source, self-hosted implementation of the Tailscale control server.</p> <p>This page contains the documentation for the latest version of headscale. Please also check our FAQ.</p> <p>Join our Discord server for a chat and community support.</p>"},{"location":"#design-goal","title":"Design goal","text":"<p>Headscale aims to implement a self-hosted, open source alternative to the Tailscale control server. Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. It implements a narrow scope, a single Tailscale network (tailnet), suitable for a personal use, or a small open-source organisation.</p>"},{"location":"#supporting-headscale","title":"Supporting headscale","text":"<p>Please see Sponsor for more information.</p>"},{"location":"#contributing","title":"Contributing","text":"<p>Headscale is \"Open Source, acknowledged contribution\", this means that any contribution will have to be discussed with the Maintainers before being submitted.</p> <p>Please see Contributing for more information.</p>"},{"location":"#about","title":"About","text":"<p>Headscale is maintained by Kristoffer Dalby and Juan Font.</p>"},{"location":"about/clients/","title":"Client and operating system support","text":"<p>We aim to support the last 10 releases of the Tailscale client on all provided operating systems and platforms. Some platforms might require additional configuration to connect with headscale.</p> OS Supports headscale Linux Yes OpenBSD Yes FreeBSD Yes Windows Yes (see docs and <code>/windows</code> on your headscale for more information) Android Yes (see docs for more information) macOS Yes (see docs and <code>/apple</code> on your headscale for more information) iOS Yes (see docs and <code>/apple</code> on your headscale for more information) tvOS Yes (see docs and <code>/apple</code> on your headscale for more information)"},{"location":"about/contributing/","title":"Contributing","text":"<p>Headscale is \"Open Source, acknowledged contribution\", this means that any contribution will have to be discussed with the maintainers before being added to the project. This model has been chosen to reduce the risk of burnout by limiting the maintenance overhead of reviewing and validating third-party code.</p>"},{"location":"about/contributing/#why-do-we-have-this-model","title":"Why do we have this model?","text":"<p>Headscale has a small maintainer team that tries to balance working on the project, fixing bugs and reviewing contributions.</p> <p>When we work on issues ourselves, we develop first hand knowledge of the code and it makes it possible for us to maintain and own the code as the project develops.</p> <p>Code contributions are seen as a positive thing. People enjoy and engage with our project, but it also comes with some challenges; we have to understand the code, we have to understand the feature, we might have to become familiar with external libraries or services and we think about security implications. All those steps are required during the reviewing process. After the code has been merged, the feature has to be maintained. Any changes reliant on external services must be updated and expanded accordingly.</p> <p>The review and day-1 maintenance adds a significant burden on the maintainers. Often we hope that the contributor will help out, but we found that most of the time, they disappear after their new feature was added.</p> <p>This means that when someone contributes, we are mostly happy about it, but we do have to run it through a series of checks to establish if we actually can maintain this feature.</p>"},{"location":"about/contributing/#what-do-we-require","title":"What do we require?","text":"<p>A general description is provided here and an explicit list is provided in our pull request template.</p> <p>All new features have to start out with a design document, which should be discussed on the issue tracker (not discord). It should include a use case for the feature, how it can be implemented, who will implement it and a plan for maintaining it.</p> <p>All features have to be end-to-end tested (integration tests) and have good unit test coverage to ensure that they work as expected. This will also ensure that the feature continues to work as expected over time. If a change cannot be tested, a strong case for why this is not possible needs to be presented.</p> <p>The contributor should help to maintain the feature over time. In case the feature is not maintained probably, the maintainers reserve themselves the right to remove features they redeem as unmaintainable. This should help to improve the quality of the software and keep it iLine truncated