Interne Dienste von überall erreichen

Ihrem Team ermöglichen, einen internen Dienst von überall zu öffnen, ohne ihn ins öffentliche Internet zu stellen. Etwa 30 Minuten.

Was Sie erreichen werden

Ihr Team öffnet einen internen Dienst von überall aus. Niemand sonst im Internet kann ihn erreichen.

Am Ende erreicht ein Notebook einen Dienst über seinen Namen, ein nicht berechtigtes Notebook nicht.

Wann Sie das brauchen

Nutzen Sie diese Anleitung, wenn das Ziel ein Dienst auf einer Maschine ist, auf der Sie Software installieren können:

Ein internes Wiki oder HR-Portal, das Personen von zu Hause aus brauchen.
Eine Staging-Seite, die nie öffentlich sein darf.
Eine Datenbank, die Entwickler mit einem Desktop-Client öffnen.
Ein Admin-Bereich, für den heute jemand im Büro sitzen muss.

Soll ein ganzes Büro oder Cloud-Netz erreichbar sein? Den passenden Aufbau wählen führt Sie zur richtigen Anleitung.

Was Sie brauchen

Die als Erforderlich markierten Zeilen genügen; die übrigen sind für später.

	Was	Wozu
Erforderlich	Die Rolle Owner oder Admin im Dashboard	Die Schritte 2 und 4 brauchen sie. Ein Network Admin kann die Gruppen und die Regel anlegen, aber weder den Schlüssel noch die Gruppen eines Mitglieds festlegen
Erforderlich	Der laufende Dienst und seine Portnummer	Die Regel nennt den Port
Erforderlich	Ein Notebook zum Testen	Schritt 5 installiert die SXAccess-App darauf. Nur das Notebook belegt, dass es funktioniert
Erforderlich	Root-Rechte oder sudo auf dem Server	Der Server tritt über einen kleinen Agenten bei
Optional	Das restliche Team	Beginnen Sie mit sich selbst und nehmen Sie die anderen danach hinzu
Optional	Eine Geräteanforderung	Nur wenn der Zugriff vom Notebook abhängen soll: Geräteanforderungen
Fortgeschritten	Eine zweite Maschine im selben Netz	Nur wenn sich der Agent nicht auf dem Host des Dienstes installieren lässt

Bevor Sie beginnen

Zwei Maschinen, ein Tunnel, eine Regel, die ihn erlaubt.

Auf dem Notebook läuft die SXAccess-App, auf dem Server der Agent. Beide bauen ihre Verbindungen nach außen auf, deshalb öffnen Sie keinen Port in Ihrer Firewall. Lässt sich auf dem Server nichts installieren? Siehe Erweiterte Konfiguration.

Einrichtung

1
Die beiden Gruppen anlegen
People › Groups › Create group. Geben Sie den Namen ein und wählen Sie Create group. So legen Sie zwei Gruppen an:
- engineering - wer Zugriff bekommt.
- internal-wiki - was erreicht wird. Benennen Sie die Gruppe nach dem Dienst, nicht nach dem Server.
Warum: Regeln nennen Gruppen. Eine Regel für engineering bleibt deshalb richtig, wenn jemand ein neues Notebook bekommt.

Sie sehen: zwei neue, leere Gruppen. Das ist im Moment richtig so.
2
Einen Registrierungsschlüssel anlegen
Access › Enrollment keys › Create enrollment key:
- Name - wiki-server.
- Make this key reusable - aus. Eine Maschine.
- Expires in - 1 Tag. Sie nutzen ihn gleich.
- Temporary devices und Allow Extra DNS Labels - aus.
- Auto-assigned groups - internal-wiki, damit der Server beim Beitritt in dieser Gruppe landet.
Wählen Sie Create enrollment key.

Sie sehen: Enrollment key created successfully! und den Schlüssel. Kopieren Sie ihn jetzt über das Kopiersymbol rechts neben dem Schlüssel, denn er wird nicht noch einmal angezeigt. Lassen Sie das Fenster für Schritt 3 offen.
3
Den Agenten auf dem Server installieren
In einem Terminal auf dem Server; die Befehle sind für Linux. Auf einem Server meldet sich niemand an, also tritt er mit dem Schlüssel bei.

Install SXAccess im Fenster aus Schritt 2 zeigt dieselben Stufen: das Installationsskript, sxaccess start --enrollment-key <schlüssel>, dann sxaccess info. Der Block unten hält den Schlüssel außerdem aus der Shell-Historie und der Prozessliste heraus und gibt dem Server seinen Namen. Nehmen Sie nicht den Linux-Reiter unter Add device: Er startet ohne Schlüssel, und der Server würde als Ihr eigenes Gerät beitreten.

Führen Sie den Block in bash oder zsh als root aus. Fügen Sie den ganzen Block ein und drücken Sie einmal Enter. Sobald Enrollment key: erscheint, fügen Sie den Schlüssel ein, und nur ihn, und drücken Sie Enter. Der Schlüssel wird nicht angezeigt, und bei einer leeren Zeile fragt der Block erneut. Die Schlüsseldatei wird am Ende gelöscht, ob der Beitritt gelungen ist oder nicht. Haben Sie den Block mit Strg+C abgebrochen, löschen Sie sie mit rm -f /run/secrets/sxaccess-key.

Sie sehen: This device is now connected, danach beginnt sxaccess info mit Connected. This device is already connected bedeutet: Die Maschine war schon beigetreten und hat ihre bisherige Identität behalten, ohne die Gruppe des Schlüssels. Öffnen Sie sie unter Devices, ergänzen Sie internal-wiki unter Assigned groups und wählen Sie Save changes.
shell
```
curl -fsSL https://pkgs.sxaccess.com/install.sh | sh{  install -d -m 700 /run/secrets  install -m 600 /dev/null /run/secrets/sxaccess-key  KEY=''  until [ -n "$KEY" ]; do printf 'Enrollment key: '; read -rs KEY || break; echo; done  [ -n "$KEY" ] && printf '%s' "$KEY" > /run/secrets/sxaccess-key && unset KEY &&    sxaccess start --enrollment-key-file /run/secrets/sxaccess-key --hostname wiki-server &&    sxaccess info  rm -f /run/secrets/sxaccess-key}
```
4
Der Person die Gruppe engineering zuweisen
Die Gruppen einer Person werden beim Mitglied festgelegt, unter Auto-assigned groups:
- Bereits Mitglied: People › Members › die Person › Access. Fügen Sie engineering unter Auto-assigned groups hinzu und wählen Sie Save Changes.
- Noch kein Mitglied: People › Members › Invite member. Füllen Sie Full name und Email address aus, tragen Sie engineering unter Auto-assigned groups ein und wählen Sie Send Invitation. Wer neu bei SXAccess ist, bekommt dann eine E-Mail: Accept invitation öffnet Complete your invite, wo die Person das Passwort festlegt, das sie in Schritt 5 braucht.
Warum an der Person: Die Gruppe gilt dann für jedes Gerät, das die Person registriert; die standardmäßig eingeschaltete Gruppenweitergabe überträgt sie auch auf ihre vorhandenen Geräte.

Sie sehen: engineering im Reiter Access des Mitglieds.
5
Die SXAccess-App auf dem Notebook installieren
Installieren und öffnen Sie die SXAccess-App auf dem Notebook: macOS (Mac App Store oder direkter Download), Windows (der Installer unter Add device), iOS und Android (App Store, Google Play).

Am Notebook sitzt eine Person, also meldet es sich an und braucht keinen Schlüssel. Wählen Sie Sign in with SXAccess account (macOS, Windows); auf dem Smartphone tippen Sie auf Allow VPN configuration und dann auf Sign in. Die Anmeldung selbst läuft im Browser, mit E-Mail-Adresse oder über Continue with Google. Bestätigen Sie die VPN-Berechtigung, nach der das Betriebssystem fragt.

Sie sehen: Die App ist verbunden, und das Notebook steht im Dashboard unter Devices.
6
Prüfen, ob beide Maschinen da sind
Devices. Zwei Einträge, beide online (unter Last seen steht Just now): das Notebook mit engineering, wiki-server mit internal-wiki. Das +1 neben jeder Gruppe ist die eingebaute Gruppe All.

Warum jetzt: Fehlt eine Gruppe, entsteht eine scheinbar korrekte Regel, die nichts gewährt.
7
Die Zugriffsregel anlegen
Access › Access rules › Create access rule. Die Regel liest sich wie ein Satz:

Allow engineering to reach internal-wiki over TCP on ports 443.
- Access rule name - die Absicht, etwa Engineering erreicht das interne Wiki.
- Allow und to reach - die beiden Gruppen. Lassen Sie die eingebaute Gruppe All weg, die beide Felder anbieten, denn sie enthält jedes Gerät.
- over - TCP. Eine neue Regel beginnt mit any protocol, was jeden Port öffnet.
- on ports - klicken Sie in das Feld, tippen Sie 443 (oder den Port Ihres Dienstes) und drücken Sie Enter: Das Feld zeigt dann 443 statt All. Bleibt es leer, öffnet die Regel jeden Port.
- Direction - auf One-way lassen. Der Server hat keinen Grund, von sich aus eine Verbindung zu einem Notebook aufzubauen.
Wählen Sie Create access rule. Solange keine Regel es erlaubt, erreichen die beiden Maschinen einander nicht.

Sie sehen: die Regel in der Liste, eingeschaltet. Sie erreicht beide Maschinen von selbst; nichts muss neu gestartet werden.

Die Liste „Devices“ mit Adresse, Gruppen, letztem Kontakt und Betriebssystem jedes Geräts. — Die Liste Devices. In Schritt 6 erscheinen hier Ihre beiden Maschinen, jede mit ihrer Gruppe; das +1 neben einer Gruppe ist die eingebaute Gruppe All.

Das Fenster „Edit access rule“ mit der Regel als Satz: „Allow“, eine Quellgruppe, „to reach“, eine Zielgruppe, „over“ TCP, „on ports“ 443 und 80, Richtung „One-way“. — Der Regeleditor aus Schritt 7, hier beim Bearbeiten einer bestehenden Regel, die zusätzlich Port 80 öffnet. Ihre Regel öffnet sich als „Create access rule“ und bekommt nur Port 443.

Prüfen

Prüfen Sie vom Notebook aus. Das Dashboard zeigt, was Sie konfiguriert haben; nur das Notebook zeigt, was funktioniert.

Erwartetes Ergebnis

Öffnen Sie in der SXAccess-App Devices: wiki-server steht dort und ist Online. Die App führt nur die Geräte auf, mit denen eine Regel sie verbindet; die Regel ist also angekommen. Öffnen Sie den Eintrag: Unter FQDN steht der volle Name, er beginnt mit wiki-server. Auf einem Notebook mit dem CLI-Agenten statt der App zeigt sxaccess info -d den Eintrag wiki-server mit seinem Path.

Port 443 muss unter diesem Namen antworten. Führen Sie den ersten Befehl unten für Ihr System aus, mit diesem Namen statt <voller-name>. Er muss gelingen; in PowerShell heißt das TcpTestSucceeded : True.

Ein Browser zeigt unter https://<voller Name>/ meist zuerst eine Zertifikatswarnung, denn das Zertifikat nennt den üblichen Hostnamen des Dienstes. Akzeptieren Sie die Warnung für diesen Test. Für den Dauerbetrieb stellen Sie dem Dienst ein Zertifikat für seinen SXAccess-Namen aus, am besten unter einer eigenen Domain für Geräte.

Dann die Hälfte prüfen, die fehlschlagen sollte

Das belegt, dass die Regel eng gefasst und nicht bloß vorhanden ist. Melden Sie sich auf einer zweiten Maschine an, die nicht in engineering ist: wiki-server fehlt in ihrem Bildschirm Devices, und der Dienst antwortet nicht.

Kein zweites Konto? Versuchen Sie unter macOS oder Linux, einen Port zu erreichen, den Ihre Regel nicht nennt (der zweite Befehl). Der Versuch muss nach 5 Sekunden in ein Timeout laufen, denn SXAccess verwirft stillschweigend, was keine Regel erlaubt. Ein Connection refused belegt nichts: Die Anfrage hat den Server dann erreicht.

shell - vom Notebook aus, unter macOS

nc -vz -G 5 <voller-name> 443nc -vz -G 5 <voller-name> 22

shell - vom Notebook aus, unter Linux

nc -vz -w 5 <voller-name> 443nc -vz -w 5 <voller-name> 22

PowerShell - vom Notebook aus, unter Windows

Test-NetConnection <voller-name> -Port 443

Fehlersuche

Funktioniert es nicht, gehen Sie die Tabelle der Reihe nach durch. Für die ersten Fragen brauchen Sie kein technisches Wissen, und die ersten vier decken die meisten Fälle ab.

Frage	Wenn nein	Wo
Meldet die SXAccess-App, dass sie verbunden ist?	Solange sie das nicht tut, funktioniert nichts. Melden Sie sich erneut an: Ein Gerät, das per Anmeldung registriert wurde, hat eine Sitzung, die abläuft, standardmäßig nach 24 Stunden.	Die App, dann Anmeldung
Sind beide Maschinen unter Devices online?	Ist der Server offline, zeigt `sxaccess info` auf ihm den Grund: Einen gestoppten Agenten starten Sie mit `sudo sxaccess agent start`, verbinden lässt er sich mit `sxaccess start`.	Devices
Hat jede Maschine die richtige Gruppe?	Die häufigste Ursache für eine Regel, die richtig aussieht und nichts gewährt. Ein Server, der schon früher beigetreten war, behält seine alten Gruppen: Ergänzen Sie die Gruppe auf seiner Seite unter Assigned groups und wählen Sie Save changes. Bei einem Notebook prüfen Sie die Auto-assigned groups des Mitglieds und ob Enable user group propagation (People › Groups › Settings) eingeschaltet ist.	Devices, Members
Ist die Regel eingeschaltet, mit richtigem Protokoll und Port?	Eine Regel für 443 öffnet nicht 8080. Prüfen Sie den Port, den der Dienst wirklich nutzt, ob die Regel TCP nennt und ob unter Advanced options das Häkchen bei Access rule is active gesetzt ist.	Access rules
Antwortet der Dienst auf dem Server selbst?	Führen Sie dort `ss -tln` aus. Der Port des Dienstes muss auf `0.0.0.0`, `*`, `[::]` oder der SXAccess-Adresse des Servers lauschen. Ein Dienst, der nur an `127.0.0.1` oder eine LAN-Adresse gebunden ist, lehnt Verbindungen ab, die über SXAccess ankommen. Fehlt der Port ganz, starten Sie den Dienst.	Ein Terminal auf dem Server
Kommen Sie immer noch nicht weiter?	Zerlegen Sie die Verbindung Stufe für Stufe.	Nachvollziehen, warum eine Verbindung blockiert wird

Erweiterte Konfiguration

Nichts davon ist für einen funktionierenden Aufbau nötig.

Auf der Maschine kann der Agent nicht laufen

Eine Appliance, eine verwaltete Datenbank, ein Drucker. Installieren Sie den Agenten auf einer anderen Maschine im selben Netz, einem Routing-Gerät, und veröffentlichen Sie das Ziel als Ressource eines Netzwerks. Siehe Standorte vor Ort.

Weitere Server für denselben Dienst

Registrieren Sie jeden mit einem neuen Schlüssel, der internal-wiki unter Auto-assigned groups hat (der Schlüssel aus Schritt 2 galt nur einmal), oder ergänzen Sie die Gruppe auf der Seite eines Servers, der schon beigetreten ist. Die Regel nennt die Gruppe und deckt die Server deshalb ab, sobald sie hinzukommen.

Ein ganzer Bereich statt einer Maschine

Ein Bereich wie 10.20.0.0/24 gewährt alles darin, auch was nächstes Jahr dazukommt. Er kann außerdem kollidieren: Die meisten Heimrouter vergeben 192.168.1.0/24. Ist das Ihr Bereich, kann ein Notebook zu Hause nicht gleichzeitig Ihren Bereich und sein Heimnetz erreichen. Benennen Sie Maschinen einzeln, wo es geht; sonst lesen Sie zuerst Standorte vor Ort.

Aus einem Skript

sxaccess start liest den Pfad der Schlüsseldatei auch aus SX_ENROLLMENT_KEY_FILE (Umgebungsvariablen). Für Gruppen, Registrierungsschlüssel, Mitglieder und Zugriffsregeln gibt es keine CLI-Befehle: Skripten Sie sie über die REST-API, siehe Öffentliche API.