mirror of
https://github.com/fosrl/docs-v2.git
synced 2026-02-08 05:56:45 +00:00
many updates for 1.13
This commit is contained in:
miloschwartz
7
additional-resources/changelog.mdx
Normal file
7
additional-resources/changelog.mdx
Normal file
@@ -0,0 +1,7 @@
|
||||
---
|
||||
title: "Changelog"
|
||||
icon: "clipboard-list"
|
||||
---
|
||||
|
||||
To view the complete changelog, please visit our [GitHub Releases
|
||||
page](https://github.com/fosrl/pangolin/releases).
|
||||
9
additional-resources/trust-center.mdx
Normal file
9
additional-resources/trust-center.mdx
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "Trust Center"
|
||||
icon: "scale-balanced"
|
||||
---
|
||||
|
||||
- [Terms of Service](https://pangolin.net/terms-of-service.html)
|
||||
- [Privacy Policy](https://pangolin.net/privacy-policy.html)
|
||||
- [AGLPv3](https://www.gnu.org/licenses/gpl-3.0.en.html)
|
||||
- [Fossorial Commercial License (FCL)](https://pangolin.net/fcl.hmtl)
|
||||
@@ -1,3 +1,7 @@
|
||||
2025-12-10 Unknown <unknown@Milos-MacBook-Pro.local>
|
||||
|
||||
*
|
||||
|
||||
---
|
||||
title: "Changelog"
|
||||
description: "Updates and announcements"
|
||||
|
||||
@@ -7,9 +7,9 @@ This guide describes how to set up your local development environment for contri
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- NodeJS v20.10.0
|
||||
- NPM v10.2.3 (or similar)
|
||||
- Go v1.23.1
|
||||
- Node 24
|
||||
- NPM 11 or similar
|
||||
- Go 1.25
|
||||
- Git
|
||||
- Docker & Docker Compose
|
||||
|
||||
@@ -280,7 +280,7 @@ Windows users with Docker Desktop + WSL2: File change detection may not work pro
|
||||
|
||||
### Gerbil
|
||||
|
||||
- Go v1.23.1
|
||||
- Go 1.25
|
||||
|
||||
```bash
|
||||
make local
|
||||
@@ -288,7 +288,7 @@ make local
|
||||
|
||||
### Newt
|
||||
|
||||
- Go v1.23.1
|
||||
- Go 1.25
|
||||
|
||||
```bash
|
||||
make local
|
||||
@@ -296,7 +296,7 @@ make local
|
||||
|
||||
### Olm
|
||||
|
||||
- Go v1.23.1
|
||||
- Go 1.25
|
||||
|
||||
```bash
|
||||
make local
|
||||
|
||||
83
docs.json
83
docs.json
@@ -2,7 +2,7 @@
|
||||
"$schema": "https://mintlify.com/docs.json",
|
||||
"theme": "aspen",
|
||||
"name": "Pangolin Docs",
|
||||
"description": "Pangolin is a self-hosted alternative to Cloudflare Tunnels, designed to provide secure and highly-available ingress access to applications.",
|
||||
"description": "Pangolin is the easiest to use identity-based remote access platform based on WireGuard.",
|
||||
"colors": {
|
||||
"primary": "#F36117",
|
||||
"light": "#F36117",
|
||||
@@ -26,24 +26,55 @@
|
||||
"pages": [
|
||||
{
|
||||
"group": "Sites",
|
||||
"icon": "plug",
|
||||
"pages": [
|
||||
"manage/sites/add-site",
|
||||
"manage/sites/understanding-sites",
|
||||
"manage/sites/install-site",
|
||||
"manage/sites/install-kubernetes",
|
||||
"manage/sites/configure-site",
|
||||
"manage/sites/update-site"
|
||||
"manage/sites/update-site",
|
||||
"manage/sites/credentials"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Resources",
|
||||
"icon": "link",
|
||||
"pages": [
|
||||
"manage/resources/targets",
|
||||
"manage/resources/tcp-udp-resources",
|
||||
"manage/resources/client-resources"
|
||||
"manage/resources/understanding-resources",
|
||||
{
|
||||
"group": "Public Resources",
|
||||
"pages": [
|
||||
"manage/resources/public/authentication",
|
||||
"manage/resources/public/targets",
|
||||
"manage/healthchecks-failover",
|
||||
"manage/resources/public/raw-resources"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Private Resources",
|
||||
"pages": [
|
||||
"manage/resources/private/host",
|
||||
"manage/resources/private/cidr",
|
||||
"manage/resources/private/alias"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Clients",
|
||||
"icon": "desktop",
|
||||
"pages": [
|
||||
"manage/clients/add-client",
|
||||
"manage/clients/install-client",
|
||||
"manage/clients/configure-client",
|
||||
"manage/clients/update-client",
|
||||
"manage/clients/credentials"
|
||||
]
|
||||
},
|
||||
"manage/domains",
|
||||
{
|
||||
"group": "Access Control",
|
||||
"icon": "user-group",
|
||||
"pages": [
|
||||
"manage/access-control/create-user",
|
||||
"manage/access-control/rules",
|
||||
@@ -59,6 +90,7 @@
|
||||
},
|
||||
{
|
||||
"group": "Identity Providers",
|
||||
"icon": "id-card",
|
||||
"pages": [
|
||||
"manage/identity-providers/add-an-idp",
|
||||
"manage/identity-providers/auto-provisioning",
|
||||
@@ -70,17 +102,18 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Clients",
|
||||
"group": "Logs & Analytics",
|
||||
"icon": "chart-bar",
|
||||
"pages": [
|
||||
"manage/clients/add-client",
|
||||
"manage/clients/install-client",
|
||||
"manage/clients/configure-client"
|
||||
"manage/analytics/request",
|
||||
"manage/analytics/access",
|
||||
"manage/analytics/action"
|
||||
]
|
||||
},
|
||||
"manage/healthchecks-failover",
|
||||
"manage/blueprints",
|
||||
{
|
||||
"group": "Remote Nodes",
|
||||
"icon": "server",
|
||||
"pages": [
|
||||
"manage/remote-node/ha",
|
||||
"manage/remote-node/nodes",
|
||||
@@ -89,15 +122,6 @@
|
||||
"manage/remote-node/config-file"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Analytics",
|
||||
"pages": [
|
||||
"manage/analytics/request",
|
||||
"manage/analytics/access",
|
||||
"manage/analytics/action"
|
||||
]
|
||||
},
|
||||
"manage/domains",
|
||||
"manage/integration-api",
|
||||
"manage/branding"
|
||||
]
|
||||
@@ -156,11 +180,10 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Careers",
|
||||
"group": "Additional Resources",
|
||||
"pages": [
|
||||
"careers/join-us",
|
||||
"careers/software-engineer-full-stack",
|
||||
"careers/software-engineer-go"
|
||||
"additional-resources/changelog",
|
||||
"additional-resources/trust-center"
|
||||
]
|
||||
}
|
||||
]
|
||||
@@ -194,6 +217,9 @@
|
||||
]
|
||||
}
|
||||
},
|
||||
"interaction": {
|
||||
"drilldown": true
|
||||
},
|
||||
"logo": {
|
||||
"light": "/logo/light.png",
|
||||
"dark": "/logo/dark.png",
|
||||
@@ -201,15 +227,20 @@
|
||||
},
|
||||
"navbar": {
|
||||
"links": [
|
||||
{
|
||||
"label": "Log In",
|
||||
"href": "https://app.pangolin.net/auth/login"
|
||||
},
|
||||
{
|
||||
"label": "Contact Us",
|
||||
"href": "mailto:numbat@pangolin.net"
|
||||
"icon": "envelope",
|
||||
"href": "mailto:contact@pangolin.net"
|
||||
}
|
||||
],
|
||||
"primary": {
|
||||
"type": "button",
|
||||
"label": "Pangolin Dashboard",
|
||||
"href": "https://app.pangolin.net"
|
||||
"href": "https://app.pangolin.net/auth/signup"
|
||||
}
|
||||
},
|
||||
"footer": {
|
||||
|
||||
BIN
images/mac-client-preferences.png
Normal file
BIN
images/mac-client-preferences.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 471 KiB |
@@ -5,12 +5,12 @@ description: "Configure rules to allow or deny access to resources without authe
|
||||
|
||||
Rules allow you to either "allow" and bypass the Pangolin auth system (no pin, login, password), or "deny" and fully reject the request. After you create a resource you can select the "Rules" tab on the sidebar and enable rules.
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Allow Rules" icon="check">
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Bypass Auth" icon="check">
|
||||
Bypass authentication completely for matching requests. Users can access resources without any login or PIN.
|
||||
</Card>
|
||||
|
||||
<Card title="Deny Rules" icon="x">
|
||||
<Card title="Block Access" icon="x">
|
||||
Completely reject requests that match the rule. Useful for blocking admin paths or sensitive endpoints.
|
||||
</Card>
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: "Blueprints"
|
||||
icon: "file-code"
|
||||
description: "Pangolin Blueprints are declarative configurations that allow you to define your resources and their settings in a structured format"
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: "Branding"
|
||||
icon: "brush"
|
||||
description: "Learn how to customize the look your Pangolin dashboard and login pages with custom branding"
|
||||
---
|
||||
|
||||
|
||||
@@ -1,180 +1,70 @@
|
||||
---
|
||||
title: "Add Client"
|
||||
title: "Understanding Clients"
|
||||
description: "Create a client to connect to your Pangolin network from a remote computer"
|
||||
---
|
||||
|
||||
A client in Pangolin is a way to create a traditional VPN tunnel from your remote computer to your Newt site on your private network. Clients allow you to tunnel your computer back into your whole network and remotely access non-HTTP resources like file shares or use it as a bastion host to manage servers.
|
||||
A client is a way to access resources on sites remotely and privately via a virtual private network. Clients are used with private resources to faciliate zero-trust network access.
|
||||
|
||||
<Note>
|
||||
Client support in Pangolin is still in beta - things may not perform as expected. If you encounter bugs please report them on [GitHub in an issue](https://github.com/fosrl/pangolin).
|
||||
</Note>
|
||||
By default a client does not have access to any hosts on the local network of the site. Admins must explicitely define resources on the site and give specific users and roles access to the resources.
|
||||
|
||||
## How Clients Work
|
||||
Users must log in and connect from a Pangolin client for [Window, Mac, and Linux](/manage/clients/install-client). Machine (automated systems and servers) connect with an ID and secret.
|
||||
|
||||
### The Connection Process
|
||||
## Client Types
|
||||
|
||||
1. **Client Creation**: You create a client in Pangolin's dashboard
|
||||
2. **Olm Registration**: Olm registers with Pangolin using the client credentials
|
||||
3. **Tunnel Establishment**: Olm establishes a WireGuard tunnel to your network
|
||||
4. **Resource Access**: You can access resources on your private network through the tunnel
|
||||
There are two types of clients: user devices and machines.
|
||||
|
||||
### What Clients Are
|
||||
<CardGroup cols={2}>
|
||||
<Card title="User Devices">
|
||||
- Associated with a user in your Pangolin organization
|
||||
- Requires login to connect (password, 2fa, etc)
|
||||
- Available for download on Mac, Windows, and Linux
|
||||
</Card>
|
||||
|
||||
- A way to tunnel your computer back into your whole network
|
||||
- Remotely access non HTTP resources like file shares
|
||||
- A bastion host or "jump box" to manage servers
|
||||
<Card title="Machines">
|
||||
- Represent a server or automated system instead of a user
|
||||
- Connect with an ID and secret
|
||||
- Available in CLI form with Pangolin CLI or Olm CLI
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### What Pangolin Clients Are Not (Yet)
|
||||
### User Devices
|
||||
|
||||
- A mesh VPN like Tailscale, Netbird, or Netmaker
|
||||
- A slick desktop UI (coming soon)
|
||||
A user may download a client for their specific system. Before they can connect, they must select a Pangolin server to authenticate to using their provided Pangolin account. Users can log in as a Pangolin user or with your attached external identity provider.
|
||||
|
||||
You can install the [Olm](https://github.com/fosrl/olm) client on your computer and run it with the ID and secret values you generate in the dashboard. When it connects, it will create a virtual network adapter on your computer just like a traditional VPN.
|
||||
Examples include:
|
||||
|
||||
[Take a look at a quick video about clients](https://youtu.be/jg8Bb05hlnI)
|
||||
- **SSH**: Admins and developers can connect with their client to specific hosts for SSH.
|
||||
- **RDP**: Users can connect to a remote host using familiar remote desktop software.
|
||||
|
||||
## Prerequisites
|
||||
Then, just like in the Pangolin dashboard, a user selects the organization to connect to. Once connected, all resources made available to the user in that organization become available via the tunnel.
|
||||
|
||||
Before adding a client, ensure you have:
|
||||
### Machines
|
||||
|
||||
1. **Updated Components**: Make sure you have the required versions:
|
||||
- Pangolin ^1.8.0
|
||||
- Gerbil ^1.1.0
|
||||
- Newt ^1.4.0
|
||||
Machine clients are for servers and automated systems that are not associated with a specific user.
|
||||
|
||||
2. **Site Configuration**: Your Newt site must be configured to accept clients with the `--accept-clients` flag or `ACCEPT_CLIENTS=true` environment variable.
|
||||
Examples include:
|
||||
|
||||
3. **Port Configuration**: Ensure port 21820 is open on your VPS and added to your `docker-compose.yml`:
|
||||
- **CICD**: Access remote resources like a database in an automated deployment pipeline.
|
||||
- **Servers**: Provide a VPS with access to a resource running in a different network.
|
||||
|
||||
```yml title="docker-compose.yml" highlight={4}
|
||||
gerbil:
|
||||
ports:
|
||||
- 51820:51820/udp
|
||||
- 21820:21820/udp
|
||||
- 443:443
|
||||
- 80:80
|
||||
```
|
||||
Though you may connect a server via a user account using a CLI client, we reccomend you specifically use a machine client.
|
||||
|
||||
## Adding a Client
|
||||
|
||||
<Steps>
|
||||
<Step title="Navigate to Clients">
|
||||
In the Pangolin dashboard, go to the **Clients** section and click **Add Client**.
|
||||
</Step>
|
||||
|
||||
<Step title="Configure client details">
|
||||
Configure the basic information:
|
||||
- **Client Name**: A descriptive name for your client
|
||||
</Step>
|
||||
|
||||
<Step title="Generate Olm credentials">
|
||||
Pangolin will generate:
|
||||
- **Client ID**: Unique identifier for the Olm client
|
||||
- **Secret**: Authentication secret for secure connection
|
||||
- **Endpoint**: The Pangolin server endpoint
|
||||
</Step>
|
||||
|
||||
<Step title="Install Olm">
|
||||
Use the generated credentials to install and configure Olm on your remote computer. See [Install Olm](/manage/clients/install-client) for detailed instructions.
|
||||
</Step>
|
||||
|
||||
<Step title="Configure resources">
|
||||
Create [client resources](/manage/resources/client-resources) for what you would like to access through the client. For example, to SSH into a server, create a resource like `22:localhost:22`.
|
||||
</Step>
|
||||
|
||||
<Step title="Verify connection">
|
||||
Once Olm is running, the client status should show as "Online" in the dashboard. You can then connect to your network using the site's IP address.
|
||||
</Step>
|
||||
</Steps>
|
||||
Machine clients authenticate with an ID and secret string. These credentials are passed via arguments into one of the supported Pangolin CLI clients. They can be revoked and rotated.
|
||||
|
||||
## Client Modalities
|
||||
|
||||
Clients have two major operation modalities:
|
||||
Clients have two major operation modalities. A client will first attempt to hole punch before falling back to relaying.
|
||||
|
||||
### Relaying (Default)
|
||||
### Relaying
|
||||
|
||||
By default, Olm will relay traffic through your Pangolin VPS - through Gerbil specifically. Gerbil listens on UDP port 21820 for new WireGuard connections and forwards the packets down the Newt site tunnels to the right peers. This means your connections back to your site do not require firewall config and uses the existing NAT holepunching capabilities of Newt.
|
||||
Clients can relay traffic through a Pangolin server - through Gerbil specifically. Gerbil listens on UDP port 21820 for new WireGuard connections and forwards the packets down the Newt site tunnels to the right peers. This means your connections back to your site do not require firewall config and uses the existing NAT holepunching capabilities of Newt.
|
||||
|
||||
### NAT Hole Punching (Experimental)
|
||||
### NAT Hole Punching
|
||||
|
||||
<Note>
|
||||
Right now NAT hole punching is EXPERIMENTAL. While functional, it does not always connect reliably and can fall back to relaying. We plan to work to improve the reliability over time by implementing more methods for those behind CGNAT or hard nats.
|
||||
While functional, it does not always connect reliably and can fall back to relaying. We plan to work to improve the reliability over time by implementing more methods for those behind CGNAT or hard nats.
|
||||
|
||||
Take a look at [Tailscale docs](https://tailscale.com/kb/1361/firewall) for some firewall changes you might be able to make to improve HP performance.
|
||||
</Note>
|
||||
|
||||
This mode can be activated by using `--holepunch` in Olm. Instead of immediately relaying through the VPS, this will attempt to connect directly to the Newt site across NAT routers.
|
||||
Take a look at [these docs](https://tailscale.com/kb/1361/firewall) for some firewall changes you might be able to make to improve hole punch reliability and performance.
|
||||
|
||||
This should help to:
|
||||
- Increase performance (speed/bandwidth)
|
||||
- Reduce VPS transit costs
|
||||
|
||||
## Site Modalities
|
||||
|
||||
Sites have two operating modalities when accepting clients:
|
||||
|
||||
### Proxy Mode
|
||||
|
||||
When you run Newt with `--accept-clients` it will run fully in user space. This means you do not need to give the container or binary any special permissions. It will NOT create a virtual network interface on the host. Instead you should create [client resources](/manage/resources/client-resources) in Pangolin to configure what ports clients can hit and where they should go.
|
||||
|
||||
### Native Mode
|
||||
|
||||
<Note>
|
||||
Right now native mode only works on Linux.
|
||||
</Note>
|
||||
|
||||
In native mode with both `--accept-clients` and `--native`, Newt will create a native Linux tunnel interface on the host. This means that all traffic destined for the site can access anything on the host.
|
||||
|
||||
#### Remote Subnets
|
||||
|
||||
In native mode, you can add remote subnets to the site settings in Pangolin to forward remote networks through Newt. This can let Newt act as a traditional VPN server to route to anything on your local network.
|
||||
|
||||
<Frame caption="Pangolin UI showing remote subnets for clients.">
|
||||
<img src="/images/remote_subnets.png" alt="Remote Subnets"/>
|
||||
</Frame>
|
||||
|
||||
This will configure a route on the Olm side of the tunnel to route this subnet down the tunnel. When it reaches the other end, can be routed to the appropriate destination by the host.
|
||||
|
||||
This requires proper Linux routing configuration. Here's what happens in native mode:
|
||||
|
||||
1. **Olm forwards packets**: Your computer running Olm blindly forwards all packets destined for the remote subnet (e.g., 192.168.0.x) over the tunnel
|
||||
2. **Newt receives packets**: Newt creates a WireGuard network interface on the Linux host and receives these packets
|
||||
3. **Linux must route packets**: The Linux machine needs to know what to do with packets destined for 192.168.0.x
|
||||
|
||||
#### Required Configuration
|
||||
|
||||
**Enable IP forwarding:**
|
||||
```bash
|
||||
sudo nano /etc/sysctl.conf
|
||||
|
||||
net.ipv4.ip_forward = 1
|
||||
```
|
||||
|
||||
**Setup NAT masquerading:**
|
||||
```bash
|
||||
sudo iptables -t nat -A POSTROUTING -j MASQUERADE
|
||||
```
|
||||
|
||||
This rewrites the source address of packets from the tunnel to be the 192.168.0.x address of the Linux instance when packets leave the instance. This way, when devices on 192.168.0.x reply to the Olm client, they know to send the response back through the tunnel.
|
||||
|
||||
#### Troubleshooting Routing Issues
|
||||
|
||||
If you can connect to Newt (peer shows as connected in logs) but can't reach remote subnet resources:
|
||||
|
||||
1. **Check if packets reach the destination**: The connection to Newt is working, so this is likely a routing issue
|
||||
2. **Verify forwarding is enabled**: Use `sysctl net.ipv4.ip_forward` to confirm it's set to 1
|
||||
3. **Check iptables rules**: Ensure NAT masquerading is configured
|
||||
4. **Consider using proxy mode**: [Client resources](/manage/resources/client-resources) can be easier as Newt handles the proxying, though you'll need to address everything as the Newt IP and assign specific ports
|
||||
|
||||
<Note>
|
||||
NAT masquerading can affect other services on the Linux instance, so be aware of potential conflicts with existing network configurations.
|
||||
</Note>
|
||||
|
||||
## Notes
|
||||
|
||||
- Clients require Olm to be running on the remote computer
|
||||
- Each client can access multiple resources on the site
|
||||
- Connection status is monitored automatically
|
||||
- Olm creates a native tun interface and usually requires sudo/admin permissions
|
||||
- On Windows: Olm will run as a service
|
||||
- LXC containers need to be configured to allow tun access
|
||||
|
||||
@@ -1,25 +1,23 @@
|
||||
---
|
||||
title: "Configure Client"
|
||||
title: "Configure Clients"
|
||||
description: "Configure Olm for connecting to Pangolin clients"
|
||||
---
|
||||
|
||||
Olm is a WireGuard client designed to securely connect your remote computer to your Pangolin network. By using Olm, you can create a traditional VPN tunnel that allows you to access resources on your private network from anywhere.
|
||||
## Mac and Windows
|
||||
|
||||
## How Olm Works
|
||||
Each respective client has a preferences window with all currently available configuration parameters like DNS override and preferred DNS servers. In your desktop client, click the menu bar or system tray icon, select More in the menu, and click Preferences.
|
||||
|
||||
### Registers with Pangolin
|
||||
<Frame caption="Screenshot of how to access preferences window on Mac client. The steps are the same on Windows.">
|
||||
<img src="/images/mac-client-preferences.png" centered/>
|
||||
</Frame>
|
||||
|
||||
Using the Olm ID and a secret, the client will make HTTP requests to Pangolin to receive a session token. Using that token, it will connect to a websocket and maintain that connection. Control messages will be sent over the websocket.
|
||||
## Pangolin CLI
|
||||
|
||||
### Establishes WireGuard Tunnel
|
||||
Refer to the [documentation in the official repository](https://github.com/fosrl/cli/blob/main/docs/pangolin.md) for the available commands, default values, and more.
|
||||
|
||||
When Olm receives WireGuard control messages, it will use the information encoded (endpoint, public key) to bring up a WireGuard tunnel using native system interfaces. It will ping over the tunnel to ensure the peer on the Gerbil side is brought up.
|
||||
## Olm CLI
|
||||
|
||||
### Creates Virtual Network Interface
|
||||
|
||||
Olm creates a virtual network adapter on your computer just like a traditional VPN. This allows you to access resources on your private network as if you were physically connected to it.
|
||||
|
||||
## Configuration Arguments
|
||||
### Flags
|
||||
|
||||
<ResponseField name="id" type="string" required>
|
||||
Olm ID generated by Pangolin to identify the client.
|
||||
@@ -79,10 +77,6 @@ Olm creates a virtual network adapter on your computer just like a traditional V
|
||||
Enable NAT hole punching mode instead of relaying through the VPS.
|
||||
|
||||
**Default**: `false`
|
||||
|
||||
<Note>
|
||||
This is EXPERIMENTAL. While functional, it does not always connect reliably and can fall back to relaying.
|
||||
</Note>
|
||||
</ResponseField>
|
||||
|
||||
<ResponseField name="config-file" type="string">
|
||||
@@ -91,52 +85,14 @@ Olm creates a virtual network adapter on your computer just like a traditional V
|
||||
**Example**: `/etc/olm/config.yaml`
|
||||
</ResponseField>
|
||||
|
||||
## Configuration Examples
|
||||
|
||||
### Basic Configuration
|
||||
|
||||
```bash
|
||||
olm \
|
||||
--id 31frd0uzbjvp721 \
|
||||
--secret h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6 \
|
||||
--endpoint https://example.com
|
||||
```
|
||||
|
||||
### With Hole Punching
|
||||
|
||||
```bash
|
||||
olm \
|
||||
--id 31frd0uzbjvp721 \
|
||||
--secret h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6 \
|
||||
--endpoint https://example.com \
|
||||
--holepunch
|
||||
```
|
||||
|
||||
### With Custom MTU and DNS
|
||||
|
||||
```bash
|
||||
olm \
|
||||
--id 31frd0uzbjvp721 \
|
||||
--secret h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6 \
|
||||
--endpoint https://example.com \
|
||||
--mtu 1400 \
|
||||
--dns 1.1.1.1
|
||||
```
|
||||
|
||||
### With Health Check
|
||||
|
||||
```bash
|
||||
olm \
|
||||
--id 31frd0uzbjvp721 \
|
||||
--secret h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6 \
|
||||
--endpoint https://example.com \
|
||||
--health-file /tmp/olm-health
|
||||
```
|
||||
|
||||
## Environment Variables
|
||||
### Environment Variables
|
||||
|
||||
All CLI arguments can be set using environment variables as an alternative to command line flags. Environment variables are particularly useful when running Olm in containerized environments.
|
||||
|
||||
<Note>
|
||||
When both environment variables and CLI arguments are provided, CLI arguments take precedence.
|
||||
</Note>
|
||||
|
||||
<ResponseField name="PANGOLIN_ENDPOINT" type="string">
|
||||
Endpoint of your Pangolin server (equivalent to `--endpoint`)
|
||||
</ResponseField>
|
||||
@@ -192,36 +148,3 @@ All CLI arguments can be set using environment variables as an alternative to co
|
||||
<ResponseField name="OLM_CONFIG_FILE" type="string">
|
||||
Load the config from this file instead of command line arguments (equivalent to `--config-file`)
|
||||
</ResponseField>
|
||||
|
||||
<Note>
|
||||
When both environment variables and CLI arguments are provided, CLI arguments take precedence.
|
||||
</Note>
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Connection Issues
|
||||
|
||||
1. **Check credentials**: Ensure the ID and secret are correct
|
||||
2. **Verify endpoint**: Make sure the endpoint URL is accessible
|
||||
3. **Check firewall**: Ensure port 21820 is open on your VPS
|
||||
4. **Verify site configuration**: Make sure your Newt site has `--accept-clients` enabled
|
||||
|
||||
### Permission Issues
|
||||
|
||||
1. **Linux/macOS**: Run with sudo or ensure proper capabilities
|
||||
2. **Windows**: Run as administrator or install as a service
|
||||
3. **LXC containers**: Configure tun device access
|
||||
|
||||
### Performance Issues
|
||||
|
||||
1. **Try hole punching**: Use `--holepunch` for better performance
|
||||
2. **Adjust MTU**: Try different MTU values if experiencing packet loss
|
||||
3. **Check network**: Ensure stable internet connection
|
||||
|
||||
## Security Considerations
|
||||
|
||||
- Keep your client secret secure and private
|
||||
- Use HTTPS endpoints only
|
||||
- Regularly rotate client credentials
|
||||
- Monitor client connections in the dashboard
|
||||
- Use firewall rules to restrict access to specific resources
|
||||
|
||||
52
manage/clients/credentials.mdx
Normal file
52
manage/clients/credentials.mdx
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Client Credentials"
|
||||
description: "Understanding how client credentials work and how they can be rotated & regenerated"
|
||||
---
|
||||
|
||||
## Understanding Credentials
|
||||
|
||||
Every machine client is provisioned with a unique identifier (ID), secret, and endpoint. The client uses the combination of these three to establish a secure, encrypted connection to the server.
|
||||
|
||||
User devices use a special combination of credentials and temporary session tokens tied to the user account. Therefore, these credentials are obscured and can not be regenerated for user devices. To invalidate a user device, the user should logout via the client of choice.
|
||||
|
||||
### ID
|
||||
|
||||
Example: `ln8yqs6w85la5zg`
|
||||
|
||||
The ID represents the client connection in the system. Every machine client has an ID.
|
||||
|
||||
This value is not a secret and it is okay if made publically available.
|
||||
|
||||
### Secret
|
||||
|
||||
Example: `tfpwoc580jf1l1glfagix0o97p8kirjogdflqg604n0tr3to`
|
||||
|
||||
The secret represents the "password" of the client. This secret must match the secret hashed in the system for the relevant ID.
|
||||
|
||||
<Note>
|
||||
This is a _secret_! Only share it with trusted people and be sure to store it safely and securely.
|
||||
</Note>
|
||||
|
||||
When the client connects, it uses this secret as a first handshake with the server. The server then passes temporary session credentials back to the site before it can initiate a websocket connection. Once the websocket connection is established, ephemeral keys are used to establish tunnels using WireGuard.
|
||||
|
||||
### Endpoint
|
||||
|
||||
Example: `https://app.pangolin.net` or `https://pangolin.my-server.com`
|
||||
|
||||
The endpoint is how the client knows which server to connect to. This is the fully qualified hostname of the Pangolin server (the URL you use to access the dashboard). For Pangolin cloud, the endpoint is `https://app.pangolin.net`. The client uses this endpoint ot establish a websocket connection and receive control messages from the server.
|
||||
|
||||
## Rotating and Regenerating Credentials
|
||||
|
||||
<Note>
|
||||
This is an Enterprise Edition only feature.
|
||||
</Note>
|
||||
|
||||
Client credentials can be regenerated. Regenerating credentials will completely invalidate the previous ID and secret. Use this feature if you have lost the secret and need to reset the credentials, or if you wish to rotate credentials on a regular basis for extra security.
|
||||
|
||||
To regenerate credentials, visit Clients > Machines > Your Client > Credentials in the Pangolin admin dashboard.
|
||||
|
||||
### Regenerate vs. Regenerate and Disconnect
|
||||
|
||||
Regenerate simply recreates the credentials and invalidates the old ones. The client will remain connected until you restart it with the new credentials.
|
||||
|
||||
Regenerate and Disconnect recreates the credentials and invalides the old ones. The client will instantly disconnect and will require you to restart it with the new credentials.
|
||||
@@ -1,25 +1,65 @@
|
||||
---
|
||||
title: "Install Client"
|
||||
description: "Install Olm as a binary"
|
||||
title: "Install Clients"
|
||||
description: "Install native clients for Mac, Windows, and Linux"
|
||||
---
|
||||
|
||||
Olm can be installed as either a static binary executable or a Docker container. Configuration is passed via CLI arguments in both cases.
|
||||
## Windows
|
||||
|
||||
<Warning>
|
||||
You **must first create a client and copy the Olm config** in Pangolin before running Olm.
|
||||
</Warning>
|
||||
- [Pangolin for Windows Installer](https://pangolin.net/downloads/windows) - This is the official page to download the latest installer file for Windows.
|
||||
- [All Versions](https://github.com/fosrl/windows/releases) - The releases section of this repository contains release notes and download artifacts for the latest version and all older versions.
|
||||
|
||||
## Binary Installation
|
||||
## Mac
|
||||
|
||||
- [Pangolin for macOS Installer](https://pangolin.net/downloads/mac) - This is the official page to download the latest installer file for macOS.
|
||||
- [All Versions](https://github.com/fosrl/apple/releases) - The releases section of this repository contains release notes and download artifacts for the latest version and all older versions.
|
||||
|
||||
## Pangolin CLI (Linux)
|
||||
|
||||
Pangolin CLI is the recommended way to run a client using a command line interface on Mac or Linux. Support for Windows is coming soon.
|
||||
|
||||
Pangolin CLI supports running as user device with authentication or a machine client.
|
||||
|
||||
### Quick Install (Recommended)
|
||||
|
||||
Use this command to automatically install Pangolin CLI. It detects your system architecture automatically and always pulls the latest version, adding `pangolin` to your PATH:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://static.pangolin.net/get-cli.sh | bash
|
||||
```
|
||||
|
||||
### Manual Download
|
||||
|
||||
Binaries for Linux and macOS are available in the [GitHub releases](https://github.com/fosrl/cli/releases) for ARM and AMD64 (x86_64) architectures.
|
||||
|
||||
Download and install manually:
|
||||
|
||||
```bash
|
||||
wget -O pangolin "https://github.com/fosrl/cli/releases/download/{version}/pangolin-cli_{architecture}" && chmod +x ./pangolin
|
||||
```
|
||||
|
||||
<Note>
|
||||
Replace `{version}` with the desired version and `{architecture}` with your architecture. Check the [release notes](https://github.com/fosrl/cli/releases) for the latest information.
|
||||
</Note>
|
||||
|
||||
## Olm CLI
|
||||
|
||||
Olm CLI is the most basic form of a client. All other clients implement Olm under the hood in some form.
|
||||
|
||||
If you're looking for a CLI interface for a client, we recommend using Pangolin CLI where possible.
|
||||
|
||||
Olm CLI is mainly only used for machine clients. Though the Pangolin CLI can also be used for machine clients, use Pangolin CLI if you expect to log in as a user.
|
||||
|
||||
### Binary Installation
|
||||
|
||||
#### Quick Install (Recommended)
|
||||
|
||||
Use this command to automatically install Olm. It detects your system architecture automatically and always pulls the latest version, adding Olm to your PATH:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://pangolin.net/get-olm.sh | bash
|
||||
curl -fsSL https://static.pangolin.net/get-olm.sh | bash
|
||||
```
|
||||
|
||||
### Manual Download
|
||||
#### Manual Download
|
||||
|
||||
Binaries for Linux, macOS, and Windows are available in the [GitHub releases](https://github.com/fosrl/olm/releases) for ARM and AMD64 (x86_64) architectures.
|
||||
|
||||
@@ -78,11 +118,11 @@ WantedBy=multi-user.target
|
||||
Make sure to move the binary to `/usr/local/bin/olm` before creating the service!
|
||||
</Warning>
|
||||
|
||||
## Windows Service
|
||||
### Windows Service
|
||||
|
||||
On Windows, olm has to be installed and run as a Windows service. When running it with the cli args, it will attempt to install and run the service to function like a cli tool. You can also run the following:
|
||||
|
||||
### Service Management Commands
|
||||
#### Service Management Commands
|
||||
|
||||
```
|
||||
# Install the service
|
||||
@@ -109,7 +149,7 @@ olm.exe help
|
||||
|
||||
Note running the service requires credentials in `%PROGRAMDATA%\olm\olm-client\config.json`.
|
||||
|
||||
### Service Configuration
|
||||
#### Service Configuration
|
||||
|
||||
When running as a service, Olm will read configuration from environment variables or you can modify the service to include command-line arguments:
|
||||
|
||||
@@ -117,7 +157,7 @@ When running as a service, Olm will read configuration from environment variable
|
||||
2. Set the credentials in `%PROGRAMDATA%\olm\olm-client\config.json`. Hint: if you run olm once with --id and --secret this file will be populated!
|
||||
3. Start the service: `olm.exe start`
|
||||
|
||||
### Service Logs
|
||||
#### Service Logs
|
||||
|
||||
When running as a service, logs are written to:
|
||||
|
||||
@@ -130,7 +170,7 @@ You can view the Windows Event Log using Event Viewer or PowerShell:
|
||||
Get-EventLog -LogName Application -Source "OlmWireguardService" -Newest 10
|
||||
```
|
||||
|
||||
## Gotchas
|
||||
### Gotchas
|
||||
|
||||
Olm creates a native tun interface. This usually requires sudo / admin permissions. Some notes:
|
||||
|
||||
|
||||
73
manage/clients/update-client.mdx
Normal file
73
manage/clients/update-client.mdx
Normal file
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: "Update Clients"
|
||||
description: "Update your installed client to the latest version"
|
||||
---
|
||||
|
||||
## Mac and Windows
|
||||
|
||||
### Automatic Updates (Recommended)
|
||||
|
||||
The desktop clients for Mac and Windows will periodically check for updates in the background. When an update is available, they will request permission to update. However, you can manually check for updates in the menu bar or system tray menu, or by restarting the application.
|
||||
|
||||
Once you accept the update, these clients will automatically download the latest version and replace itself on your computer.
|
||||
|
||||
### Manual Updates
|
||||
|
||||
- **Mac**: Find the latest version in the [GitHub releases](https://github.com/fosrl/apple/releases).
|
||||
- **Windows**: Find the latest version in the [GitHub releases](https://github.com/fosrl/windows/releases).
|
||||
|
||||
You can download the latest installer files and restart the installation process to install the latest version. Visit [https://pangolin.net/downloads](https://pangolin.net/downloads) to find the latest official installers for your platform.
|
||||
|
||||
## Pangolin CLI
|
||||
|
||||
Find the latest version in the [GitHub releases](https://github.com/fosrl/cli/releases).
|
||||
|
||||
### Automatic Updates (Recommended)
|
||||
|
||||
If you already have Pangolin CLI installed, use the update command:
|
||||
|
||||
```bash
|
||||
pangolin update
|
||||
```
|
||||
|
||||
Or you can re-run the installation script:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://static.pangolin.net/get-cli.sh | bash
|
||||
```
|
||||
|
||||
### Manual Updates
|
||||
|
||||
Download the latest binary for your system from [GitHub releases](https://github.com/fosrl/cli/releases) and replace your existing binary.
|
||||
|
||||
```bash
|
||||
wget -O pangolin "https://github.com/fosrl/cli/releases/download/{version}/pangolin-cli_{architecture}" && chmod +x ./pangolin
|
||||
```
|
||||
|
||||
<Note>
|
||||
Replace `{version}` with the desired version and `{architecture}` with your architecture. Check the [release notes](https://github.com/fosrl/cli/releases) for the latest information.
|
||||
</Note>
|
||||
|
||||
## Olm CLI
|
||||
|
||||
Find the latest version in the [GitHub releases](https://github.com/fosrl/olm/releases).
|
||||
|
||||
### Automatic Updates (Recommended)
|
||||
|
||||
If you used the auto installer, simply run it again:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://static.pangolin.net/get-olm.sh | bash
|
||||
```
|
||||
|
||||
### Manual Updates
|
||||
|
||||
Download the latest binary for your system from [GitHub releases](https://github.com/fosrl/olm/releases) and replace your existing binary.
|
||||
|
||||
```bash
|
||||
wget -O olm "https://github.com/fosrl/olm/releases/download/{version}/olm_{architecture}" && chmod +x ./olm
|
||||
```
|
||||
|
||||
<Note>
|
||||
Replace `{version}` with the desired version and `{architecture}` with your architecture. Check the [release notes](https://github.com/fosrl/olm/releases) for the latest information.
|
||||
</Note>
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: "Domains"
|
||||
icon: "globe"
|
||||
description: "Learn how to configure domains for your Pangolin resources and understand the different domain types available"
|
||||
---
|
||||
|
||||
@@ -72,6 +73,10 @@ You then access your resources via subdomains like `app.example.com` or `db.exam
|
||||
|
||||
### For Domain Delegation
|
||||
|
||||
<Warning>
|
||||
Some domain providers, namely Cloudflare, do not allow adding NS records for the root of your domain. This would prevent you from delegating all `*.example` to Pangolin. However, you can usually delegate everything after the first level, like `*.subdomain.example.com`. If your provider restricts you in this way, you could either move your domain, or use CNAME records for individual subdomains of the root domain.
|
||||
</Warning>
|
||||
|
||||
When using domain delegation, you'll need to update your domain's nameservers:
|
||||
|
||||
**Example NS Records:**
|
||||
@@ -99,7 +104,3 @@ Type: CNAME
|
||||
Name: _acme-challenge.test.example.com
|
||||
Value: _acme-challenge.0nbn5rpcq4wthq6.cname.pangolin.net
|
||||
```
|
||||
|
||||
<Check>
|
||||
Once DNS is properly configured and propagated, your domain will be verified and ready to use with your Pangolin resources.
|
||||
</Check>
|
||||
|
||||
@@ -1,20 +1,9 @@
|
||||
---
|
||||
title: "Health Checks"
|
||||
description: "Configure automated health monitoring and failover for high availability"
|
||||
description: "Configure automated health monitoring and failover for resources"
|
||||
---
|
||||
|
||||
<iframe
|
||||
className="w-full aspect-video rounded-xl"
|
||||
src="https://www.youtube.com/embed/Xdme_2-AMas"
|
||||
title="YouTube video player"
|
||||
frameBorder="0"
|
||||
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowFullScreen
|
||||
></iframe>
|
||||
|
||||
## Overview
|
||||
|
||||
Pangolin provides automated health checking for [targets](/manage/resources/targets) to ensure traffic is only routed to healthy services. Health checks are essential for building highly available services, as they automatically remove unhealthy targets from traffic routing and load balancing.
|
||||
Pangolin provides automated health checking for targets to ensure traffic is only routed to healthy services. Health checks are essential for building highly available services, as they automatically remove unhealthy targets from traffic routing and load balancing.
|
||||
|
||||
## How Health Checks Work
|
||||
|
||||
@@ -22,16 +11,10 @@ Pangolin provides automated health checking for [targets](/manage/resources/targ
|
||||
|
||||
Health checks operate continuously in the background:
|
||||
|
||||
1. **Periodic Checks**: Pangolin sends requests to your target endpoints at configured intervals
|
||||
2. **Status Evaluation**: Responses are evaluated against your configured criteria
|
||||
3. **Traffic Management**: Healthy targets receive traffic, unhealthy targets are excluded
|
||||
4. **Automatic Recovery**: Targets are automatically re-enabled when they become healthy again
|
||||
|
||||
### Health Check vs Target Endpoint
|
||||
|
||||
<Card title="Flexible Monitoring">
|
||||
The health check endpoint can be the same as your target, but you can also monitor a different endpoint. This allows you to create dedicated health check endpoints that provide more detailed service status information.
|
||||
</Card>
|
||||
1. **Periodic Checks**: Pangolin sends requests to your target endpoints at configured intervals.
|
||||
2. **Status Evaluation**: Responses are evaluated against your configured criteria.
|
||||
3. **Traffic Management**: Healthy targets receive traffic, unhealthy targets are excluded.
|
||||
4. **Automatic Recovery**: Targets are automatically re-enabled when they become healthy again.
|
||||
|
||||
## Target Health States
|
||||
|
||||
@@ -87,109 +70,45 @@ Targets can exist in three distinct states that determine how traffic is routed:
|
||||
|
||||
### Endpoint Configuration
|
||||
|
||||
<Card title="Health Check Target">
|
||||
**Target Endpoint**: The URL or address to monitor for health status
|
||||
|
||||
**Default Behavior**: Usually the same as your target endpoint
|
||||
|
||||
**Custom Endpoints**: Can monitor different endpoints (e.g., `/health`, `/status`)
|
||||
</Card>
|
||||
- **Target Endpoint**: The URL or address to monitor for health status
|
||||
- **Default Behavior**: Usually the same as your target endpoint
|
||||
- **Custom Endpoints**: Can monitor different endpoints (e.g., `/health`, `/status`)
|
||||
|
||||
### Timing Configuration
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Healthy Interval">
|
||||
**Purpose**: How often to check targets that are currently healthy
|
||||
#### Healthy Interval
|
||||
|
||||
**Typical Range**: 30-60 seconds
|
||||
- **Purpose**: How often to check targets that are currently healthy
|
||||
- **Typical Range**: 30-60 seconds
|
||||
- **Consideration**: Less frequent checks reduce overhead
|
||||
|
||||
**Consideration**: Less frequent checks reduce overhead
|
||||
</Card>
|
||||
#### Unhealthy Interval
|
||||
|
||||
<Card title="Unhealthy Interval">
|
||||
**Purpose**: How often to check targets that are currently unhealthy
|
||||
|
||||
**Typical Range**: 10-30 seconds
|
||||
|
||||
**Consideration**: More frequent checks enable faster recovery
|
||||
</Card>
|
||||
</CardGroup>
|
||||
- **Purpose**: How often to check targets that are currently unhealthy
|
||||
- **Typical Range**: 10-30 seconds
|
||||
- **Consideration**: More frequent checks enable faster recovery
|
||||
|
||||
### Response Configuration
|
||||
|
||||
<Card title="Timeout Settings">
|
||||
**Request Timeout**: Maximum time to wait for a health check response
|
||||
#### Timeout Settings
|
||||
|
||||
**Default Behavior**: Requests exceeding timeout are considered failed
|
||||
- **Request Timeout**: Maximum time to wait for a health check response
|
||||
- **Default Behavior**: Requests exceeding timeout are considered failed
|
||||
- **Recommended**: Set based on your service's typical response time
|
||||
|
||||
**Recommended**: Set based on your service's typical response time
|
||||
</Card>
|
||||
#### HTTP Response Codes
|
||||
|
||||
<Card title="HTTP Response Codes">
|
||||
**Healthy Codes**: Which HTTP status codes indicate a healthy target
|
||||
|
||||
**Common Settings**: 200, 201, 202, 204
|
||||
|
||||
**Custom Codes**: Configure based on your service's health endpoint behavior
|
||||
</Card>
|
||||
|
||||
## Failover Behavior
|
||||
|
||||
### Automatic Traffic Exclusion
|
||||
|
||||
When a target becomes unhealthy:
|
||||
|
||||
<Steps>
|
||||
<Step title="Health Check Failure">
|
||||
Target fails to meet health check criteria (response code, timeout, etc.)
|
||||
</Step>
|
||||
|
||||
<Step title="Status Update">
|
||||
Target status changes from "Healthy" to "Unhealthy"
|
||||
</Step>
|
||||
|
||||
<Step title="Traffic Removal">
|
||||
Target is immediately removed from traffic routing configuration
|
||||
</Step>
|
||||
|
||||
<Step title="Load Balancer Update">
|
||||
Load balancing configuration is updated to exclude the unhealthy target
|
||||
</Step>
|
||||
|
||||
<Step title="Continued Monitoring">
|
||||
Health checks continue at the unhealthy interval for recovery detection
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
### Automatic Recovery
|
||||
|
||||
When an unhealthy target recovers:
|
||||
|
||||
<Steps>
|
||||
<Step title="Successful Health Check">
|
||||
Target begins responding correctly to health checks
|
||||
</Step>
|
||||
|
||||
<Step title="Status Update">
|
||||
Target status changes from "Unhealthy" to "Healthy"
|
||||
</Step>
|
||||
|
||||
<Step title="Traffic Restoration">
|
||||
Target is automatically added back to traffic routing
|
||||
</Step>
|
||||
|
||||
<Step title="Load Balancer Update">
|
||||
Load balancing resumes including the recovered target
|
||||
</Step>
|
||||
</Steps>
|
||||
- **Healthy Codes**: Which HTTP status codes indicate a healthy target
|
||||
- **Common Settings**: 200, 201, 202, 204
|
||||
- **Custom Codes**: Configure based on your service's health endpoint behavior
|
||||
|
||||
## High Availability Strategies
|
||||
|
||||
### Multi-Target Redundancy
|
||||
|
||||
<Card title="Service Redundancy">
|
||||
Deploy multiple instances of your service across different targets to ensure availability even when some targets fail.
|
||||
</Card>
|
||||
#### Service Redundancy
|
||||
|
||||
Deploy multiple instances of your service across different targets to ensure availability even when some targets fail.
|
||||
|
||||
```
|
||||
Resource: web-application
|
||||
@@ -202,9 +121,9 @@ Traffic routes to: Target 1 & Target 3 only
|
||||
|
||||
### Cross-Site Failover
|
||||
|
||||
<Card title="Geographic Distribution">
|
||||
Distribute targets across multiple sites to protect against site-level failures.
|
||||
</Card>
|
||||
#### Geographic Distribution
|
||||
|
||||
Distribute targets across multiple sites to protect against site-level failures.
|
||||
|
||||
```
|
||||
Resource: api-service
|
||||
|
||||
@@ -1,13 +1,16 @@
|
||||
---
|
||||
title: "Integration API"
|
||||
icon: "cube"
|
||||
description: "Learn how to use Pangolin's REST API to automate and script operations with fine-grained permissions"
|
||||
---
|
||||
|
||||
<Warning>
|
||||
Pangolin is in heavy development. The REST API routes and behavior may include braking changes between updates. We will do our best to document large changes.
|
||||
</Warning>
|
||||
|
||||
The API is REST-based and supports many operations available through the web interface. Authentication uses Bearer tokens, and you can create multiple API keys with specific permissions for different use cases.
|
||||
|
||||
<Info>
|
||||
For Pangolin Community Edition, the integration API must be enabled. Check out [the documentation](/self-host/advanced/integration-api) for how to enable the integration API.
|
||||
</Info>
|
||||
|
||||
## Authentication
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@ Before installing Pangolin, ensure you've opened the required port on your firew
|
||||
Connect to your server via SSH and download the installer:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://pangolin.net/get-node-installer.sh | bash
|
||||
curl -fsSL https://static.pangolin.net/get-node-installer.sh | bash
|
||||
```
|
||||
|
||||
The installer supports both AMD64 (x86_64) and ARM64 architectures.
|
||||
|
||||
@@ -1,79 +0,0 @@
|
||||
---
|
||||
title: "Client Resources"
|
||||
description: "Configure resources for Olm clients to access on a Newt site"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Site resources in Pangolin allow you to define specific ports and a destination that can be accessed through the VPN tunnel when using [Olm clients](/manage/clients/add-client). This is useful for exposing internal services to your remote clients securely.
|
||||
|
||||
<Note>
|
||||
Site resources are only for exposing services on a Newt site to Olm clients running remotely and do not get proxied.
|
||||
</Note>
|
||||
|
||||
## Internal Exposure with Clients
|
||||
|
||||
Internal exposure resources are only accessible when connected via an Olm client. This approach is perfect for secure access to services without exposing them to the public internet.
|
||||
|
||||
When you run Newt with `--accept-clients`, it operates fully in user space without creating a virtual network interface on the host. This means:
|
||||
|
||||
- **No special permissions required** for the container or binary
|
||||
- **No virtual network interface** created on the host
|
||||
- **Client-only access** through Pangolin's tunnel
|
||||
- **Secure internal routing** to your services
|
||||
|
||||
## Configuring Site Resources
|
||||
|
||||
To configure site resources:
|
||||
|
||||
<Steps>
|
||||
<Step title="Navigate to Resources">
|
||||
Navigate to the **Resources** section in the Pangolin dashboard.
|
||||
</Step>
|
||||
<Step title="Select Site Resources">
|
||||
In the toggle at the top of the table, select "Site Resources".
|
||||
</Step>
|
||||
<Step title="Add Resource">
|
||||
Click **Add Resource**.
|
||||
</Step>
|
||||
<Step title="Choose Resource Type">
|
||||
Choose the resource type (TCP or UDP).
|
||||
</Step>
|
||||
<Step title="Configure Port and Target">
|
||||
Specify the local port and the target address.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Accessing Site Resources
|
||||
|
||||
Once configured, you can access these resources from your remote clients using the Olm tunnel.
|
||||
|
||||
### Example: SSH Access
|
||||
|
||||
Here's how to set up SSH access to your server when connected with a client:
|
||||
|
||||
<Steps>
|
||||
<Step title="Create the resource">
|
||||
In the Pangolin dashboard, create a new client resource and set the port to `2022` (or any available port).
|
||||
|
||||
<Frame>
|
||||
<img src="/images/client_resource.png" width="400" centered/>
|
||||
</Frame>
|
||||
</Step>
|
||||
|
||||
<Step title="Connect and access">
|
||||
When connected with a Olm client, you can SSH to your server using `<site-address>:2022`.
|
||||
|
||||
```bash
|
||||
ssh user@100.90.128.0 -p 22
|
||||
```
|
||||
<Note>
|
||||
When accessing a site resource, you use the IP of the site found in the dashboard and the local port you configured for the resource.
|
||||
</Note>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Note>
|
||||
This approach is ideal for secure remote access without exposing SSH directly to the internet.
|
||||
</Note>
|
||||
|
||||
4
manage/resources/private/alias.mdx
Normal file
4
manage/resources/private/alias.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Aliases"
|
||||
description: "Set a friendly alias hostname that resolves to a host"
|
||||
---
|
||||
4
manage/resources/private/cidr.mdx
Normal file
4
manage/resources/private/cidr.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "CIDRs"
|
||||
description: "Provide access to an entire network range"
|
||||
---
|
||||
4
manage/resources/private/host.mdx
Normal file
4
manage/resources/private/host.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Hosts"
|
||||
description: "Provide access to a specific host on the network"
|
||||
---
|
||||
4
manage/resources/private/overview.mdx
Normal file
4
manage/resources/private/overview.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Overview"
|
||||
description: "Private resources are only accessible when connected with a Pangolin client"
|
||||
---
|
||||
36
manage/resources/public/authentication.mdx
Normal file
36
manage/resources/public/authentication.mdx
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Authentication"
|
||||
description: "Create identity and context aware rules to allow access"
|
||||
---
|
||||
|
||||
Though public resources are public and accessible to via a web browser, admins can create rules to enable a layer of authenticated protection in front of public resources. By default, all public resources have Pangolin auth (Platform SSO) enabled, but a number of other authentication methods are available.
|
||||
|
||||
When an unauthenticated user visits a resource in their web browser, they will be redirected to a Pangolin-controlled authentication page where they must complete authentication.
|
||||
|
||||
## User Login
|
||||
|
||||
- **Pangolin (Platform) SSO** - Users must log in with a valid Pangolin account before they can log in.
|
||||
- **External Identity Provider** - Enable log in to resoruces via your organization's identity provider of choice (Google, Azure, Okta, etc).
|
||||
- **Users and Roles** - Assign specific users accesss to resources. Group users by roles and assign entire roles access to resources.
|
||||
|
||||
## PIN and Passcode
|
||||
|
||||
Add simple PIN or passcode authentication to resources. Similarly to user login, users will need to first enter a PIN or passcode before they can gain access to the resource.
|
||||
|
||||
## Shareable Links and Access Tokens
|
||||
|
||||
Generate temporary self-destructing links that provide authenticated access to resources. Set specific expiration times for when all users who used the link will lose access and when the link becomes invalid. Links can optionally grant more permanent access with no expiration. Delete links when you want to revoke access.
|
||||
|
||||
You can also pass access tokens via query params or headers to resources to enable programmatic access.
|
||||
|
||||
## Email-based One Time Passcode (OTP)
|
||||
|
||||
First whitelist specific emails or wildcards, like `*@.example.com`. When users visit the resource, they will be prompted to enter an email. If the email they enter is on the whitelist, a temporary one time passcode will be sent to their email. Users can then enter this OTP to gain access to the resource.
|
||||
|
||||
## Rules to Access or Deny
|
||||
|
||||
Define ranked rules to either block or allow access from specific IPs, geolocation, URL paths, and more.
|
||||
|
||||
## More
|
||||
|
||||
Read about more authentication options and specific settings in [Access Control](/manage/access-control/) and [Identity Providers](/manage/identity-providers/).
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Raw TCP & UDP"
|
||||
title: "TCP & UDP"
|
||||
description: "Configure raw TCP and UDP traffic through Pangolin tunnels"
|
||||
---
|
||||
|
||||
@@ -15,6 +15,7 @@ In Pangolin Community Edition, ensure you have the flag enabled in the config fi
|
||||
flags:
|
||||
allow_raw_resources: true
|
||||
```
|
||||
|
||||
You map the resource to a port on the host Pangolin server, so you can access the resource from `<server-public-ip>:<mapped-port>`. This is useful if you want to access the resource over the public internet, such as exposing a game server like Minecraft.
|
||||
|
||||
## Proxied Resources
|
||||
@@ -3,14 +3,8 @@ title: "Targets"
|
||||
description: "Configure destination endpoints for resource routing and load balancing"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
When you create a resource in Pangolin, you define different targets that specify where traffic should be routed within your network. Each target represents a specific destination that the resource can proxy to when handling incoming requests.
|
||||
|
||||
<Note>
|
||||
Targets are created on the Newt tunnel, enabling traffic to reach destinations on the remote network without requiring additional routing configuration.
|
||||
</Note>
|
||||
|
||||
## How Targets Work
|
||||
|
||||
### Target Routing
|
||||
@@ -22,9 +16,9 @@ Targets function as destination endpoints for your resources:
|
||||
3. **Network Access**: Newt proxy routes traffic to the local network through the tunnel
|
||||
4. **Direct Connection**: No additional routing is necessary on the remote network
|
||||
|
||||
## Multi-Site Targets (v1.9.0+)
|
||||
## Multi-Site Targets
|
||||
|
||||
With the introduction of update 1.9.0, targets now have sites associated with them. This enhancement provides significant benefits for reliability and load distribution.
|
||||
Targets have sites associated with them. This provides significant benefits for reliability and load distribution described below.
|
||||
|
||||
### Site-Distributed Resources
|
||||
|
||||
@@ -38,11 +32,15 @@ You can now configure targets across different sites for the same resource:
|
||||
Set up load balancing across sites to distribute traffic in a round-robin fashion between all available targets.
|
||||
</Card>
|
||||
|
||||
### Load Balancing Requirements
|
||||
### Distributing Sites Load Across Servers
|
||||
|
||||
<Warning>
|
||||
Load balancing between different targets only works when sites are connected to the same node. In Pangolin instances with multiple remote nodes, ensure load balancing occurs on the same node.
|
||||
</Warning>
|
||||
<Note>
|
||||
This is an Enterprise Edition only feature.
|
||||
</Note>
|
||||
|
||||
This refers to having more than on Pangolin server node that a site can connect to. If one of the server nodes goes down, the site moves to another node. This has some implications for site-based load balancing, because DNS must can only route a FQDN to one Pangolin server node at a time.
|
||||
|
||||
Load balancing between different targets only works when sites are connected to the same Pangolin node. In Pangolin instances with multiple remote nodes, ensure load balancing occurs on the same node.
|
||||
|
||||
To ensure effective load balancing in multi-node environments:
|
||||
|
||||
@@ -50,10 +48,6 @@ To ensure effective load balancing in multi-node environments:
|
||||
newt --prefer-endpoint <specific-endpoint> <other-args>
|
||||
```
|
||||
|
||||
<Note>
|
||||
Pangolin currently does not load balance between nodes, only between targets on the same node.
|
||||
</Note>
|
||||
|
||||
## Path-Based Routing
|
||||
|
||||
Path-based routing allows you to direct traffic to different targets based on the request path. This enables sophisticated routing scenarios where different services can handle different parts of your application.
|
||||
@@ -71,23 +65,23 @@ When a request comes in, Pangolin evaluates the path against all targets and rou
|
||||
|
||||
Pangolin supports three different matching strategies:
|
||||
|
||||
<Card title="Exact Match">
|
||||
**exact**: The request path must match the configured path exactly.
|
||||
#### Exact Match
|
||||
|
||||
Example: Path `/api/users` with exact match only matches `/api/users`
|
||||
</Card>
|
||||
**exact**: The request path must match the configured path exactly.
|
||||
|
||||
<Card title="Prefix Match">
|
||||
**prefix**: The request path must start with the configured path.
|
||||
Example: Path `/api/users` with exact match only matches `/api/users`
|
||||
|
||||
Example: Path `/api` with prefix match matches `/api/users`, `/api/orders`, `/api/users/123`, etc.
|
||||
</Card>
|
||||
#### Prefix Match
|
||||
|
||||
<Card title="Regex Match">
|
||||
**regex**: The request path is matched against a regular expression pattern.
|
||||
**prefix**: The request path must start with the configured path.
|
||||
|
||||
Example: Path `^/api/users/[0-9]+$` with regex match matches `/api/users/123` but not `/api/users/abc`
|
||||
</Card>
|
||||
Example: Path `/api` with prefix match matches `/api/users`, `/api/orders`, `/api/users/123`, etc.
|
||||
|
||||
#### Regex Match
|
||||
|
||||
**regex**: The request path is matched against a regular expression pattern.
|
||||
|
||||
Example: Path `^/api/users/[0-9]+$` with regex match matches `/api/users/123` but not `/api/users/abc`
|
||||
|
||||
<Frame caption="Pangolin UI showing targets with path-based routing configuration">
|
||||
<img src="/images/targets_config_path_match.png" alt="Targets example"/>
|
||||
@@ -127,41 +121,41 @@ The rewriting happens after the path match evaluation but before the request rea
|
||||
|
||||
Pangolin supports four different rewriting strategies:
|
||||
|
||||
<Card title="Prefix Rewrite">
|
||||
**prefix**: Replaces the matched portion with a new prefix, preserving the rest of the path.
|
||||
#### Prefix Rewrite
|
||||
|
||||
- With Prefix Match: `/api` → `/v2/api` transforms `/api/users` into `/v2/api/users`
|
||||
- With Exact Match: `/old` → `/new` transforms `/old` into `/new`
|
||||
- With Regex Match: Uses the regex pattern with the rewrite value as replacement
|
||||
</Card>
|
||||
**prefix**: Replaces the matched portion with a new prefix, preserving the rest of the path.
|
||||
|
||||
<Card title="Exact Rewrite">
|
||||
**exact**: Replaces the matched path with the exact rewrite path.
|
||||
- With Prefix Match: `/api` → `/v2/api` transforms `/api/users` into `/v2/api/users`
|
||||
- With Exact Match: `/old` → `/new` transforms `/old` into `/new`
|
||||
- With Regex Match: Uses the regex pattern with the rewrite value as replacement
|
||||
|
||||
Example: Match path `/api/users` → Rewrite to `/users` transforms `/api/users` into `/users`
|
||||
</Card>
|
||||
#### Exact Rewrite
|
||||
|
||||
<Card title="Regex Rewrite">
|
||||
**regex**: Uses regular expression substitution to transform the path. Works with any match type.
|
||||
**exact**: Replaces the matched path with the exact rewrite path.
|
||||
|
||||
- With Regex Match: Uses the regex pattern directly
|
||||
- With Prefix Match: Automatically captures everything after the prefix with `(.*)`
|
||||
- With Exact Match: Matches the exact path
|
||||
Example: Match path `/api/users` → Rewrite to `/users` transforms `/api/users` into `/users`
|
||||
|
||||
Example: Match path `^/api/v1/(.*)` (regex) → Rewrite to `/api/v2/$1` transforms `/api/v1/users` into `/api/v2/users`
|
||||
</Card>
|
||||
#### Regex Rewrite
|
||||
|
||||
<Card title="Strip Prefix">
|
||||
**stripPrefix**: Removes the matched prefix from the path.
|
||||
**regex**: Uses regular expression substitution to transform the path. Works with any match type.
|
||||
|
||||
- With Prefix Match: Efficiently strips the prefix using Traefik's stripPrefix middleware
|
||||
- With Exact/Regex Match: Uses regex replacement to remove the matched portion
|
||||
- Optionally add a new prefix after stripping by providing a rewrite value
|
||||
- With Regex Match: Uses the regex pattern directly
|
||||
- With Prefix Match: Automatically captures everything after the prefix with `(.*)`
|
||||
- With Exact Match: Matches the exact path
|
||||
|
||||
Example: Match path `/api` (prefix) → Strip Prefix transforms `/api/users` into `/users`
|
||||
Example: Match path `^/api/v1/(.*)` (regex) → Rewrite to `/api/v2/$1` transforms `/api/v1/users` into `/api/v2/users`
|
||||
|
||||
Example with new prefix: Match path `/old` (prefix) → Strip Prefix + Rewrite to `/new` transforms `/old/users` into `/new/users`
|
||||
</Card>
|
||||
#### Strip Prefix
|
||||
|
||||
**stripPrefix**: Removes the matched prefix from the path.
|
||||
|
||||
- With Prefix Match: Efficiently strips the prefix using Traefik's stripPrefix middleware
|
||||
- With Exact/Regex Match: Uses regex replacement to remove the matched portion
|
||||
- Optionally add a new prefix after stripping by providing a rewrite value
|
||||
|
||||
Example: Match path `/api` (prefix) → Strip Prefix transforms `/api/users` into `/users`
|
||||
|
||||
Example with new prefix: Match path `/old` (prefix) → Strip Prefix + Rewrite to `/new` transforms `/old/users` into `/new/users`
|
||||
|
||||
<Frame caption="Pangolin UI showing path rewriting configuration">
|
||||
<img src="/images/targets_config_path_rewrite.png" alt="Targets with path rewriting"/>
|
||||
52
manage/resources/understanding-resources.mdx
Normal file
52
manage/resources/understanding-resources.mdx
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Understanding Resources"
|
||||
description: "Resources are any network address you want to make available to users"
|
||||
---
|
||||
|
||||
Resources respresent the applications, hosts, or ranges you make available for remote access to users. Resources exist on the remote networks of your sites. Users only ever think about connecting to resources and not specific sites.
|
||||
|
||||
By default, no resources are made available on sites. Admins must define resources with backend targets, and assign specific access policies before any users can gain access.
|
||||
|
||||
## Resources Types
|
||||
|
||||
There are two types of resources: public resources and private resources.
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Public Resources">
|
||||
- Reverse proxies to backend services
|
||||
- Optionally have authentication
|
||||
- Anyone with web browser can access
|
||||
</Card>
|
||||
|
||||
<Card title="Private Resources">
|
||||
- Zero-trust VPN
|
||||
- Access to every resources requires authentication
|
||||
- Users and machines access when connected with a client
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Public Resources
|
||||
|
||||
Public resources are protocol-aware and TCP/UDP proxies to services that are made available to the public internet.
|
||||
|
||||
#### HTTPS Resources
|
||||
|
||||
Examples of HTTP resources include, APIs, websites, and dashboards. These are served with a fully qualified domain name and HTTPS with a valid SSL certificate.
|
||||
|
||||
All requests go through an authenticated reverse proxy. **Thus, public resources do not require client-side software to be installed on user devices for access. Anyone with a web browser can access public resources.**
|
||||
|
||||
HTTP resources are also identity and context aware, meaning you can create policies and rules to only let certain users, roles, countries, IPs, CIDRs, etc have access. When users visit an authenticated public resource, they are greeted with a Pangolin login page where they must complete authentication in order to get to the underlying resource. Therefore, Pangolin acts as a frontdoor barrier to these resources.
|
||||
|
||||
#### Raw TCP/UDP Resources
|
||||
|
||||
Raw resources are a way to proxy any TCP and UDP traffic through the Pangolin reverse proxy. Instead of a fully qualified domain name and certificate, these resources are bound to one or more ports on the Pangolin host.
|
||||
|
||||
Since these resources are not protocol aware and are publically proxied, they do not support identity and context policies and rules.
|
||||
|
||||
### Private Resources
|
||||
|
||||
Private resources require users to be connected with Pangolin client in order for them to be accessed. Any TCP and UDP traffic can be made available.
|
||||
|
||||
**Private resources function like a zero-trust virtual private network (VPN).** Explicit access to resources must be granted for users and roles to be able to access them. For this reason, we recommend using private resources for all raw TCP/UDP traffic that doesn't need a public proxy, instead of relying on raw TCP/UDP public resources (as discussed above).
|
||||
|
||||
Private resources support single hosts or entire network ranges (CIDR). Private resources can also have internal DNS alias hostnames assigned for easy, human-readable naming. Users don't choose to connect to specific resources; rather, when they connect via a client to your organization, they can access all resources their account has access to at once.
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
title: "Add Site"
|
||||
description: "Create a site to connect to a remote network and expose resources"
|
||||
---
|
||||
|
||||
A site is a connection to a remote network that allows Pangolin to establish a tunnel to that network. Sites are the foundation for exposing resources because all resources exist on a site. Newt is the software connector that facilitates the connection and addresses the targets on the remote networks.
|
||||
|
||||
## How Sites Work
|
||||
|
||||
### The Connection Process
|
||||
|
||||
1. **Site Creation**: You create a site in Pangolin's dashboard
|
||||
2. **Newt Registration**: Newt registers with Pangolin using the site credentials
|
||||
3. **Tunnel Establishment**: Newt establishes a WireGuard tunnel to the remote network
|
||||
4. **Resource Exposure**: Resources on the remote network become accessible through the tunnel
|
||||
|
||||
### Why Sites Matter
|
||||
|
||||
Sites are the first step to exposing resources with Pangolin because:
|
||||
|
||||
- **Resources exist on sites**: All resources must be associated with a site
|
||||
- **Newt addresses targets**: Newt is what actually connects to the targets on remote networks
|
||||
- **Tunnel enables access**: The tunnel allows Pangolin to expose resources without opening ports or needing a public IP
|
||||
- **Secure communication**: All traffic flows through encrypted WireGuard tunnels
|
||||
|
||||
## Site Types
|
||||
|
||||
Pangolin supports three different types of sites, each designed for different use cases and deployment scenarios.
|
||||
|
||||
<Card title="Newt Tunnel (Recommended)">
|
||||
This site allows you to expose resources on a remote network via a fully managed tunnel. This requires the Newt connector to be running on the remote network. It's the easiest to use and requires the least amount of setup. No NAT configuration required.
|
||||
</Card>
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Local Site">
|
||||
Use this if you want to expose resources on the same host as the Pangolin server (this is for self-hosted Pangolin only). No tunnels are created. Ports must be opened on the host running Pangolin (this has to happen anyway for Pangolin to work).
|
||||
</Card>
|
||||
|
||||
<Card title="Basic WireGuard">
|
||||
This is self-hosted only. This uses a raw WireGuard connection without Newt, thus there is no websocket connection, requiring more manual management. These sites require NAT to address targets running on other hosts on the remote network. Otherwise, you can only expose resources on the remote WireGuard peer itself.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Adding a Site
|
||||
|
||||
<Steps>
|
||||
<Step title="Navigate to Sites">
|
||||
In the Pangolin dashboard, go to the **Sites** section and click **Add Site**.
|
||||
</Step>
|
||||
|
||||
<Step title="Configure site details">
|
||||
Configure the basic information:
|
||||
- **Site Name**: A descriptive name for your site
|
||||
</Step>
|
||||
|
||||
<Step title="Choose site type">
|
||||
Select the appropriate site type based on your needs:
|
||||
- **Newt Tunnel**: For remote networks with Newt connector
|
||||
- **Local Site**: For resources on the same host as Pangolin
|
||||
- **Basic WireGuard**: For direct WireGuard connections
|
||||
</Step>
|
||||
|
||||
<Step title="Generate Newt credentials">
|
||||
Pangolin will generate:
|
||||
- **Newt ID**: Unique identifier for the Newt client
|
||||
- **Secret**: Authentication secret for secure connection
|
||||
- **Endpoint**: The Pangolin server endpoint
|
||||
</Step>
|
||||
|
||||
<Step title="Install Site">
|
||||
Use the generated credentials to configure the site on the remote network. See [Install Site](/manage/sites/install-site) for detailed instructions on how to install Newt.
|
||||
</Step>
|
||||
|
||||
<Step title="Verify connection">
|
||||
Once Newt is running, the site status should show as "Online" in the dashboard. Sometimes it takes a few moments for the status to update.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Notes
|
||||
|
||||
- Sites require Newt to be running on the remote network
|
||||
- Each site can host multiple resources
|
||||
- Connection status is monitored automatically
|
||||
@@ -1,30 +1,9 @@
|
||||
---
|
||||
title: "Configure Site"
|
||||
title: "Configure Sites"
|
||||
description: "Configure Newt for connecting to Pangolin sites"
|
||||
---
|
||||
Newt is a fully user space [WireGuard](https://www.wireguard.com/) tunnel client and TCP/UDP proxy, designed to securely expose private resources controlled by Pangolin. By using Newt, you don't need to manage complex WireGuard tunnels and NATing.
|
||||
|
||||
## Preview
|
||||
|
||||
<Frame caption="Newt interface preview">
|
||||
<img src="/images/newt-preview.png" alt="Newt Preview"/>
|
||||
</Frame>
|
||||
|
||||
## How Newt Works
|
||||
|
||||
### Registers with Pangolin
|
||||
|
||||
Using the Newt ID and a secret, the client will make HTTP requests to Pangolin to receive a session token. Using that token, it will connect to a websocket and maintain that connection. Control messages will be sent over the websocket.
|
||||
|
||||
### Receives WireGuard Control Messages
|
||||
|
||||
When Newt receives WireGuard control messages, it will use the information encoded (endpoint, public key) to bring up a WireGuard tunnel using [netstack](https://github.com/WireGuard/wireguard-go/blob/master/tun/netstack/examples/http_server.go) fully in user space. It will ping over the tunnel to ensure the peer on the Gerbil side is brought up.
|
||||
|
||||
### Receives Proxy Control Messages
|
||||
|
||||
When Newt receives proxy control messages, it will use the information encoded to create a local low level TCP and UDP proxies attached to the virtual tunnel in order to relay traffic to programmed targets.
|
||||
|
||||
## Configuration Arguments
|
||||
## Flags
|
||||
|
||||
<ResponseField name="id" type="string" required>
|
||||
Newt ID generated by Pangolin to identify the client.
|
||||
@@ -110,8 +89,8 @@ When Newt receives proxy control messages, it will use the information encoded t
|
||||
**Example**: `/path/to/client.p12`
|
||||
</ResponseField>
|
||||
|
||||
<ResponseField name="accept-clients" type="boolean">
|
||||
Enable WireGuard server mode to accept incoming Olm client connections.
|
||||
<ResponseField name="disable-clients" type="boolean">
|
||||
Prevent Pangolin Clients from connecting to resources on this site.
|
||||
|
||||
**Default**: `false`
|
||||
</ResponseField>
|
||||
@@ -144,6 +123,10 @@ When Newt receives proxy control messages, it will use the information encoded t
|
||||
|
||||
All CLI arguments can be set using environment variables as an alternative to command line flags. Environment variables are particularly useful when running Newt in containerized environments.
|
||||
|
||||
<Note>
|
||||
When both environment variables and CLI arguments are provided, CLI arguments take precedence.
|
||||
</Note>
|
||||
|
||||
<ResponseField name="PANGOLIN_ENDPOINT" type="string">
|
||||
Endpoint of your Pangolin server (equivalent to `--endpoint`)
|
||||
</ResponseField>
|
||||
@@ -240,113 +223,6 @@ All CLI arguments can be set using environment variables as an alternative to co
|
||||
Load the config JSON from this file instead of in the home folder.
|
||||
</ResponseField>
|
||||
|
||||
<Note>
|
||||
When both environment variables and CLI arguments are provided, CLI arguments take precedence.
|
||||
</Note>
|
||||
|
||||
## Basic Configuration Examples
|
||||
|
||||
### Binary Example
|
||||
|
||||
```bash
|
||||
newt \
|
||||
--id 31frd0uzbjvp721 \
|
||||
--secret h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6 \
|
||||
--endpoint https://example.com
|
||||
```
|
||||
|
||||
### Docker Compose with Environment Variables (Recommended)
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
services:
|
||||
newt:
|
||||
image: fosrl/newt
|
||||
container_name: newt
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- PANGOLIN_ENDPOINT=https://app.pangolin.net
|
||||
- NEWT_ID=2ix2t8xk22ubpfy
|
||||
- NEWT_SECRET=nnisrfsdfc7prqsp9ewo1dvtvci50j5uiqotez00dgap0ii2
|
||||
- HEALTH_FILE=/tmp/healthy
|
||||
```
|
||||
|
||||
### Docker Compose with CLI Arguments
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
services:
|
||||
newt:
|
||||
image: fosrl/newt
|
||||
container_name: newt
|
||||
restart: unless-stopped
|
||||
command:
|
||||
- --id 31frd0uzbjvp721
|
||||
- --secret h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6
|
||||
- --endpoint https://app.pangolin.net
|
||||
- --health-file /tmp/healthy
|
||||
```
|
||||
|
||||
## Advanced Features
|
||||
|
||||
### Accept Client Connections
|
||||
|
||||
When the `--accept-clients` flag is enabled (or `ACCEPT_CLIENTS=true` environment variable is set), Newt operates as a WireGuard server that can accept incoming client connections from other devices. This enables peer-to-peer connectivity through the Newt instance.
|
||||
|
||||
#### Client Tunneling Modes
|
||||
|
||||
Newt supports two WireGuard tunneling modes:
|
||||
|
||||
##### Userspace Mode (Default)
|
||||
|
||||
By default, Newt uses a fully userspace WireGuard implementation using [netstack](https://github.com/WireGuard/wireguard-go/blob/master/tun/netstack/examples/http_server.go). This mode:
|
||||
|
||||
- **Does not require root privileges**
|
||||
- **Works on all supported platforms** (Linux, Windows, macOS)
|
||||
- **Does not require WireGuard kernel module** to be installed
|
||||
- **Runs entirely in userspace** - no system network interface is created
|
||||
- **Is containerization-friendly** - works seamlessly in Docker containers
|
||||
|
||||
<Note>
|
||||
This is the recommended mode for most deployments, especially containerized environments.
|
||||
</Note>
|
||||
|
||||
##### Native Mode (Linux only)
|
||||
|
||||
When using the `--native` flag or setting `USE_NATIVE_INTERFACE=true`, Newt uses the native WireGuard kernel module. This mode:
|
||||
|
||||
- **Requires root privileges** to create and manage network interfaces
|
||||
- **Only works on Linux** with the WireGuard kernel module installed
|
||||
- **Creates a real network interface** (e.g., `newt0`) on the system
|
||||
- **May offer better performance** for high-throughput scenarios
|
||||
- **Requires proper network permissions** and may conflict with existing network configurations
|
||||
|
||||
<Warning>
|
||||
Native mode requires Linux with WireGuard kernel module and must run as root.
|
||||
</Warning>
|
||||
|
||||
#### Native Mode Requirements
|
||||
|
||||
To use native mode:
|
||||
|
||||
1. Run on a Linux system
|
||||
2. Install the WireGuard kernel module
|
||||
3. Run Newt as root (`sudo`)
|
||||
4. Ensure the system allows creation of network interfaces
|
||||
|
||||
**Docker Compose example:**
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
services:
|
||||
newt:
|
||||
image: fosrl/newt
|
||||
container_name: newt
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- PANGOLIN_ENDPOINT=https://app.pangolin.net
|
||||
- NEWT_ID=2ix2t8xk22ubpfy
|
||||
- NEWT_SECRET=nnisrfsdfc7prqsp9ewo1dvtvci50j5uiqotez00dgap0ii2
|
||||
- ACCEPT_CLIENTS=true
|
||||
```
|
||||
|
||||
### Docker Socket Integration
|
||||
|
||||
Newt can integrate with the Docker socket to provide remote inspection of Docker containers. This allows Pangolin to query and retrieve detailed information about containers running on the Newt client, including metadata, network configuration, port mappings, and more.
|
||||
@@ -429,32 +305,3 @@ Newt supports mutual TLS (mTLS) authentication if the server has been configured
|
||||
- Public certificate
|
||||
- CA certificate
|
||||
- Encrypted PKCS12 files are currently not supported
|
||||
|
||||
**Binary Example:**
|
||||
|
||||
```bash
|
||||
newt \
|
||||
--id 31frd0uzbjvp721 \
|
||||
--secret h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6 \
|
||||
--endpoint https://example.com \
|
||||
--tls-client-cert ./client.p12
|
||||
```
|
||||
|
||||
**Docker Compose Example:**
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
services:
|
||||
newt:
|
||||
image: fosrl/newt
|
||||
container_name: newt
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- PANGOLIN_ENDPOINT=https://app.pangolin.net
|
||||
- NEWT_ID=2ix2t8xk22ubpfy
|
||||
- NEWT_SECRET=nnisrfsdfc7prqsp9ewo1dvtvci50j5uiqotez00dgap0ii2
|
||||
- TLS_CLIENT_CERT=./client.p12
|
||||
```
|
||||
|
||||
<Note>
|
||||
Get your `id` and `secret` from the Pangolin dashboard when creating a Newt client.
|
||||
</Note>
|
||||
|
||||
50
manage/sites/credentials.mdx
Normal file
50
manage/sites/credentials.mdx
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Site Credentials"
|
||||
description: "Understanding how site credentials work and how they can be rotated & regenerated"
|
||||
---
|
||||
|
||||
## Understanding Credentials
|
||||
|
||||
Every site is provisioned with a unique identifier (ID), secret, and endpoint. The site uses the combination of these three to establish a secure, encrypted connection to the server.
|
||||
|
||||
### ID
|
||||
|
||||
Example: `ln8yqs6w85la5zg`
|
||||
|
||||
The ID represents the site connection type in the system. Every Newt site has an ID.
|
||||
|
||||
This value is not a secret and it is okay if made publically available.
|
||||
|
||||
### Secret
|
||||
|
||||
Example: `tfpwoc580jf1l1glfagix0o97p8kirjogdflqg604n0tr3to`
|
||||
|
||||
The secret represents the "password" of the site. This secret must match the secret hashed in the system for the relevant ID.
|
||||
|
||||
<Note>
|
||||
This is a _secret_! Only share it with trusted people and be sure to store it safely and securely.
|
||||
</Note>
|
||||
|
||||
When the site connects, it uses this secret as a first handshake with the server. The server then passes temporary session credentials back to the site before it can initiate a websocket connection. Once the websocket connection is established, ephemeral keys are used to establish tunnels using WireGuard.
|
||||
|
||||
### Endpoint
|
||||
|
||||
Example: `https://app.pangolin.net` or `https://pangolin.my-server.com`
|
||||
|
||||
The endpoint is how the site knows which server to connect to. This is the fully qualified hostname of the Pangolin server (the URL you use to access the dashboard). For Pangolin cloud, the endpoint is `https://app.pangolin.net`. The site uses this endpoint ot establish a websocket connection and receive control messages from the server.
|
||||
|
||||
## Rotating and Regenerating Credentials
|
||||
|
||||
<Note>
|
||||
This is an Enterprise Edition only feature.
|
||||
</Note>
|
||||
|
||||
Site credentials can be regenerated. Regenerating credentials will completely invalidate the previous ID and secret. Use this feature if you have lost the secret and need to reset the credentials, or if you wish to rotate credentials on a regular basis for extra security.
|
||||
|
||||
To regenerate credentials, visit Sites > Your Site > Credentials in the Pangolin admin dashboard.
|
||||
|
||||
### Regenerate vs. Regenerate and Disconnect
|
||||
|
||||
Regenerate simply recreates the credentials and invalidates the old ones. The site will remain connected until you restart it with the new credentials.
|
||||
|
||||
Regenerate and Disconnect recreates the credentials and invalides the old ones. The site will instantly disconnect and will require you to restart it with the new credentials.
|
||||
@@ -9,95 +9,76 @@ This guide assumes you already are familiar with Kubernetes concepts and you ful
|
||||
|
||||
## Global Prerequisites
|
||||
|
||||
<Check>
|
||||
- Kubernetes Cluster (v1.28.15+)
|
||||
- Access to the Kubernetes Cluster
|
||||
- Helm (v3.0+) installed, see <Link href="https://helm.sh/docs/intro/install/">Helm install docs</Link>
|
||||
</Check>
|
||||
|
||||
<Tip>
|
||||
**Recommended**: Helm Chart Installation.
|
||||
</Tip>
|
||||
## Helm Installation
|
||||
|
||||
---
|
||||
All Fossorial Helm charts are available on Artifact Hub. See <Link href="https://artifacthub.io/packages/search?org=fosrl">Fossorial Charts</Link>.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Helm">
|
||||
<Steps>
|
||||
<Step title="Add Fossorial Helm repo">
|
||||
```bash
|
||||
helm repo add fossorial https://charts.fossorial.io
|
||||
helm repo update fossorial
|
||||
helm search repo fossorial
|
||||
```
|
||||
</Step>
|
||||
<Step title="Prepare Installation files">
|
||||
|
||||
# Helm Installation
|
||||
Prepare your Newt credentials:
|
||||
```env title="newt-cred.env"
|
||||
PANGOLIN_ENDPOINT=<your-endpoint>
|
||||
NEWT_ID=<your-id>
|
||||
NEWT_SECRET=<your-secret>
|
||||
```
|
||||
|
||||
<Tip>
|
||||
All Fossorial Helm charts are available on Artifact Hub. See <Link href="https://artifacthub.io/packages/search?org=fosrl">Fossorial Charts</Link>.
|
||||
</Tip>
|
||||
Prepare a values file with your desired configuration.
|
||||
|
||||
## Install Newt
|
||||
<Tip>See <Link href="https://github.com/fosrl/helm-charts/tree/main/charts/newt">Newt chart values configuration options</Link>.</Tip>
|
||||
|
||||
<Steps>
|
||||
<Step title="Add Fossorial Helm repo">
|
||||
```bash
|
||||
helm repo add fossorial https://charts.fossorial.io
|
||||
helm repo update fossorial
|
||||
helm search repo fossorial
|
||||
```
|
||||
</Step>
|
||||
<Step title="Prepare Installation files">
|
||||
```yaml title="values-newt.yaml"
|
||||
newtInstances:
|
||||
- name: main
|
||||
enabled: true
|
||||
auth:
|
||||
existingSecretName: newt-cred
|
||||
keys:
|
||||
endpointKey: PANGOLIN_ENDPOINT
|
||||
idKey: NEWT_ID
|
||||
secretKey: NEWT_SECRET
|
||||
```
|
||||
</Step>
|
||||
<Step title="Newt Installation">
|
||||
|
||||
Prepare your Newt credentials:
|
||||
```env title="newt-cred.env"
|
||||
PANGOLIN_ENDPOINT=<your-endpoint>
|
||||
NEWT_ID=<your-id>
|
||||
NEWT_SECRET=<your-secret>
|
||||
```
|
||||
Create a Kubernetes Secret from the env file created earlier:
|
||||
```bash
|
||||
kubectl create secret generic newt-cred -n newt --from-env-file=newt-cred.env
|
||||
```
|
||||
|
||||
Prepare a values file with your desired configuration.
|
||||
Install Newt with Helm:
|
||||
```bash
|
||||
helm install my-newt fossorial/newt \
|
||||
-n newt --create-namespace \
|
||||
-f values-newt.yaml
|
||||
```
|
||||
|
||||
<Tip>See <Link href="https://github.com/fosrl/helm-charts/tree/main/charts/newt">Newt chart values configuration options</Link>.</Tip>
|
||||
|
||||
```yaml title="values-newt.yaml"
|
||||
newtInstances:
|
||||
- name: main
|
||||
enabled: true
|
||||
auth:
|
||||
existingSecretName: newt-cred
|
||||
keys:
|
||||
endpointKey: PANGOLIN_ENDPOINT
|
||||
idKey: NEWT_ID
|
||||
secretKey: NEWT_SECRET
|
||||
```
|
||||
</Step>
|
||||
<Step title="Newt Installation">
|
||||
|
||||
Create a Kubernetes Secret from the env file created earlier:
|
||||
```bash
|
||||
kubectl create secret generic newt-cred -n newt --from-env-file=newt-cred.env
|
||||
```
|
||||
|
||||
Install Newt with Helm:
|
||||
```bash
|
||||
helm install my-newt fossorial/newt \
|
||||
-n newt --create-namespace \
|
||||
-f values-newt.yaml
|
||||
```
|
||||
|
||||
Change the release name (`my-newt`), namespace (`newt`), and values filename as needed.
|
||||
</Step>
|
||||
<Step title="Upgrade or rollback">
|
||||
```bash
|
||||
# Update repo to get latest charts
|
||||
helm repo update fossorial
|
||||
# Upgrade Newt (after editing values)
|
||||
helm upgrade my-newt fossorial/newt -n newt -f values-newt.yaml
|
||||
```
|
||||
```bash
|
||||
# Roll back to a previous revision
|
||||
helm rollback my-newt 1 -n newt
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
---
|
||||
Change the release name (`my-newt`), namespace (`newt`), and values filename as needed.
|
||||
</Step>
|
||||
<Step title="Upgrade or rollback">
|
||||
```bash
|
||||
# Update repo to get latest charts
|
||||
helm repo update fossorial
|
||||
# Upgrade Newt (after editing values)
|
||||
helm upgrade my-newt fossorial/newt -n newt -f values-newt.yaml
|
||||
```
|
||||
```bash
|
||||
# Roll back to a previous revision
|
||||
helm rollback my-newt 1 -n newt
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Customizing Your Values
|
||||
|
||||
@@ -105,8 +86,6 @@ All configuration options are documented in the respective repositories:
|
||||
|
||||
- <Link href="https://github.com/fosrl/helm-charts/tree/main/charts/newt">Newt Helm chart values</Link>
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- <Link href="https://github.com/fosrl/helm-charts">All Fossorial Helm Charts repo</Link>
|
||||
|
||||
@@ -1,29 +1,9 @@
|
||||
---
|
||||
title: "Install Site"
|
||||
title: "Install Sites"
|
||||
description: "Install Newt as a binary or Docker container"
|
||||
---
|
||||
|
||||
Newt can be installed as either a static binary executable or a Docker container. Configuration is passed via CLI arguments in both cases.
|
||||
|
||||
<Warning>
|
||||
You **must first create a site and copy the Newt config** in Pangolin before running Newt.
|
||||
</Warning>
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Binary Installation" icon="download">
|
||||
- Static executable
|
||||
- Cross-platform support
|
||||
- Easy to install and run
|
||||
- Systemd service support
|
||||
</Card>
|
||||
|
||||
<Card title="Docker Installation" icon="docker">
|
||||
- Containerized deployment
|
||||
- Environment variables
|
||||
- Docker Compose support
|
||||
- Easy management
|
||||
</Card>
|
||||
</CardGroup>
|
||||
Newt can be installed as either a static binary executable or a Docker container. You must first create a site and copy the Newt config in Pangolin before running Newt.
|
||||
|
||||
## Binary Installation
|
||||
|
||||
@@ -32,7 +12,7 @@ You **must first create a site and copy the Newt config** in Pangolin before run
|
||||
Use this command to automatically install Newt. It detects your system architecture automatically and always pulls the latest version, adding Newt to your PATH:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://pangolin.net/get-newt.sh | bash
|
||||
curl -fsSL https://static.pangolin.net/get-newt.sh | bash
|
||||
```
|
||||
|
||||
### Manual Download
|
||||
@@ -59,15 +39,6 @@ newt \
|
||||
--secret h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6 \
|
||||
--endpoint https://example.com
|
||||
```
|
||||
|
||||
### Permanent Installation
|
||||
|
||||
Install to your PATH (may need to run as root):
|
||||
|
||||
```bash
|
||||
mv ./newt /usr/local/bin
|
||||
```
|
||||
|
||||
<Note>
|
||||
The quick installer will do this step for you.
|
||||
</Note>
|
||||
@@ -130,7 +101,7 @@ services:
|
||||
- NEWT_SECRET=nnisrfsdfc7prqsp9ewo1dvtvci50j5uiqotez00dgap0ii2
|
||||
```
|
||||
|
||||
#### Config file injected as Compose Secret
|
||||
#### Config File Injected as Compose Secret
|
||||
|
||||
A safer but slightly more complex way is to use [Compose Secrets](https://docs.docker.com/compose/how-tos/use-secrets/). First, create a `JSON` file containing your configuration:
|
||||
|
||||
|
||||
55
manage/sites/understanding-sites.mdx
Normal file
55
manage/sites/understanding-sites.mdx
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Understanding Sites"
|
||||
description: "Create a site to connect to a remote network and expose resources"
|
||||
---
|
||||
|
||||
A site is a connection to a remote network that allows Pangolin to provide access to resources, whether public or private, to users anywhere. Sites are the foundation for exposing resources because all resources exist on one or more sites. Newt is Pangolin's custom software connector that facilitates the connection and addresses the targets on the remote networks.
|
||||
|
||||
## The Basics
|
||||
|
||||
- **Tunneled sites should always run behind a firewall.** Never provide public access to a site.
|
||||
- **Users do not connect to a site directly.** Instead, admins define public (browser-based) or private resources on the local network of the site and Pangolin provides acess to these resources.
|
||||
- **You can run one or multiple sites per network.** You need at least on site to facilitate access to resources, but you can run more than one site in the same network for redundancy, for example. It's up to your preferred deployment method.
|
||||
- **Sites are software-defined proxies and deny all traffic by default.** Just because a site is deployed to a network doesn't mean users have access to resources on the network. By default, sites don't allow any traffic to hosts on the network. Admins must define explicit resources and delegate access to users.
|
||||
|
||||
## Site Types
|
||||
|
||||
Pangolin supports three different types of sites, each designed for different use cases and deployment scenarios.
|
||||
|
||||
### Newt Site (Recommended)
|
||||
|
||||
This site allows you to expose resources on a remote network via a fully managed tunnel and websocket. This requires the Newt connector to be running on the remote network. It's the easiest to use and requires the least amount of setup. No NAT configuration required.
|
||||
|
||||
We recommend using Newt sites in almost all cases. Newt is the primary connector type and supports the most features.
|
||||
|
||||
Newt sites support:
|
||||
- Public HTTPS proxied resources
|
||||
- Private resources
|
||||
- Load balancing
|
||||
- Health checking
|
||||
- Docker socket scanning
|
||||
- And more...
|
||||
|
||||
|
||||
### Local Site
|
||||
|
||||
Use this if you want to expose resources on the same host as the Pangolin server (this is for self-hosted Pangolin only). No tunnels are created. Ports must be opened on the host running Pangolin (this has to happen anyway for Pangolin to work).
|
||||
|
||||
Use local sites if you want to expose a public resource on the same host as your self-hosted Pangolin server.
|
||||
|
||||
Local sites do not support:
|
||||
- Private resources
|
||||
- Health checking
|
||||
- Docker socket scanning
|
||||
|
||||
### Basic WireGuard Site
|
||||
|
||||
This is self-hosted only. This uses a raw WireGuard connection without Newt, thus there is no websocket connection, requiring more manual management. These sites require NAT to address targets running on other hosts on the remote network. Otherwise, you can only expose resources on the remote WireGuard peer itself.
|
||||
|
||||
Generally, we do not reccomend you use basic WireGuard sites unless you have a specific use case.
|
||||
|
||||
Basic WireGuard sites do not support:
|
||||
- Using LAN-style addresses as targets
|
||||
- Private resources
|
||||
- Health checking
|
||||
- Docker socket scanning
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Update Site"
|
||||
title: "Update Sites"
|
||||
description: "Update Newt to the latest version"
|
||||
---
|
||||
|
||||
@@ -32,7 +32,7 @@ docker compose up -d newt
|
||||
If you used the auto installer, simply run it again.
|
||||
|
||||
```bash
|
||||
curl -fsSL https://pangolin.net/get-newt.sh | bash
|
||||
curl -fsSL https://static.pangolin.net/get-newt.sh | bash
|
||||
```
|
||||
|
||||
### Manual Installation
|
||||
|
||||
@@ -17,7 +17,7 @@ Have a look at this [Community guide](/self-host/community-guides/geolite2automa
|
||||
You can use the installer to download and place the database for you, just grab the latest installer:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://pangolin.net/get-installer.sh | bash
|
||||
curl -fsSL https://static.pangolin.net/get-installer.sh | bash
|
||||
```
|
||||
Then run the installer again:
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ Before installing Pangolin, ensure you've set up DNS for your domain(s) and open
|
||||
Connect to your server via SSH and download the installer:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://pangolin.net/get-installer.sh | bash
|
||||
curl -fsSL https://static.pangolin.net/get-installer.sh | bash
|
||||
```
|
||||
|
||||
The installer supports both AMD64 (x86_64) and ARM64 architectures.
|
||||
|
||||
Reference in New Issue
Block a user