Latest revision as of 07:24, 20 July 2024

 

Home

 

Download

 

News

 

Support

 

Admin

 

Dev

 

Screen Shots

 

Grid List

 

Bugs

Languages:

English    Deutsch

[edit] Einführung

Dies sind Anweisungen, um eine OpenSimulator-Installation durch eine Firewall oder einen Router extern zugänglich zu machen. Bitte beachten Sie, dass Sie, wenn Sie Hardware für Heimnetzwerke verwenden, einen Router benötigen, der NAT-Loopback unterstützt. Siehe NAT Loopback Routers, wenn Sie sowohl LAN- als auch externe Benutzerzugriffe ermöglichen möchten.

Für Hilfe bei allgemeinen Verbindungsproblemen siehe Troubleshooting#Networking and config issues.

[edit] Standalone-Modus

[edit] TCP

   TCP/9000

Der im Abschnitt [Network] von OpenSim.ini konfigurierte http_listener_port muss extern zugänglich sein. Standardmäßig ist dies 9000.

Im Standalone-Modus bietet dies

   HTTP-Zugang zum Simulator (erforderlich für das Kapazitätsprotokoll und andere Dinge).
   HTTP-Zugang zu öffentlichen Diensten wie Login.

Im Standalone-Modus wird kein privater Dienstport exponiert, da alle Simulator-zu-Dienst-Kommunikation intern innerhalb des OpenSim.exe-Prozesses erfolgt.

Wenn Sie XMLRPC für In-World-Skripte aktiviert haben (http://wiki.secondlife.com/wiki/Category:LSL_XML-RPC) (dies ist standardmäßig nicht aktiv), müssen Sie auch den im Abschnitt [XMLRPC] von OpenSim.ini konfigurierten XmlRpcPort extern zugänglich machen. Standardmäßig ist dies TCP/20800.

[edit] UDP

   UDP/9000-9xxx

Der konfigurierte InternalPort jeder Region muss für UDP-Verkehr vom Viewer aus zugänglich sein (zum Austausch von Bewegungsdaten, Objektinformationen usw.). Diese Konfigurationsdateien befinden sich im Verzeichnis bin/Regions/. Der übliche Port für die erste Region ist 9000, aber jede Region benötigt ihren eigenen Port (normalerweise dann 9001, 9002 usw.). Es können jedoch auch andere Portsets konfiguriert werden.

[edit] IP-Adresse

In den Region-Konfigurationsdateien im Verzeichnis bin/Regions/ hat jede Region eine konfigurierte ExternalHostName. Zum Beispiel:

ExternalHostName = 82.73.39.77

Damit Viewer außerhalb Ihres LANs Ihre Installation kontaktieren können, muss dies von deren Standort aus direkt zugänglich sein. Im einfachsten Fall wäre Ihr Server direkt aus dem Internet zugänglich. Rufen Sie Ihren external_host_name ab Holen Sie sich Ihre internal_ip_address (mit ipconfig für Windows oder ifconfig für Linux) Stellen Sie sicher, dass die Einstellungen übereinstimmen

Wenn Sie einen Simulator zu Hause betreiben, ist es viel wahrscheinlicher, dass der Zugriff auf Ihr LAN über einen Router erfolgt, der Ihren Computer nicht über das Internet zugänglich macht. Weitere Informationen dazu finden Sie im Abschnitt NAT und Portweiterleitung unten.

[edit] Grid-Modus

[edit] Simulator

   TCP/9000
   UDP/9000-9xxx

Für jeden Simulator in Ihrem Grid müssen dieselben Ports wie oben für die Standalone-Situation beschrieben für externe Viewer zugänglich sein. Obwohl öffentliche Dienste in dieser Konfiguration nicht von OpenSim.exe verwaltet werden, muss der HTTP-Port des Simulators weiterhin für andere Viewer-zu-Simulator-Kommunikationsmechanismen (z.B. Kapazitäten) verfügbar sein.

[edit] Dienste

   TCP/8002
   TCP/8003 (nur intern, siehe unten)

In der Standalone-Konfiguration sind sowohl Simulator als auch Dienste in einem einzigen Prozess (OpenSim.exe) enthalten.

In der Grid-Konfiguration werden Dienste jedoch separat in einer oder mehreren Robust.exe-Shells ausgeführt.

Einige dieser Dienste, wie Login, müssen für Viewer zugänglich sein.

In der Standardkonfiguration von Robust.exe werden diese alle auf dem öffentlichen Port 8002 bereitgestellt. Diese müssen für externe Viewer zugänglich sein.

In der Grid-Konfiguration gibt es jedoch auch eine Reihe privater Dienste (Asset, Inventar usw.). Standardmäßig laufen diese auf Port 8003 (nur TCP) und sollten nicht für Viewer zugänglich gemacht werden. In einem geschlossenen Grid sollte Port 8003 nur für die Maschinen zugänglich sein, die das Grid betreiben. Wenn Robust und alle OpenSim-Instanzen, die Regionen ausführen, auf einer einzigen Maschine laufen, sollte kein externer Zugriff auf Port 8003 erlaubt sein.

[edit] Optionale und Add-on Modul-spezifische Ports

[edit] FreeSWITCH Voice

   TCP+UDP 5060 - SIP-Ports (5060 für das Standardanrufprofil)
   TCP+UDP 1720 - H.323-Ports für Anrufaufbau

Weitere Details zu den verwendeten FreeSWITCH-Ports und Firewall-Konfigurationsdetails finden Sie unter:

   Freeswitch Module#Firewall Config
   http://wiki.freeswitch.org/wiki/Firewall

[edit] Mumble Voice

   SIP-Ports
   ICE-Ports

[edit] NAT und Portweiterleitung

[edit] Einfach

Wenn Ihr Host keine öffentliche IP-Adresse hat (z.B. er ist hinter einem Heimrouter versteckt), haben Sie Probleme beim Hosting von Grid- und Regionsservern, wenn Sie planen, Clients sowohl auf der Router-Seite als auch auf der anderen Seite zu verbinden. Dies kann jedoch durch die Verwendung von Portweiterleitung und IP-Weiterleitung umgangen werden. Dies behebt auch Probleme, bei denen der Client beim Region-Handshake hängt.

   Setzen Sie die internal_ip_address auf Ihre lokale LAN-IP (z.B. 192.168.2.1) (regions.ini-Datei)
   Setzen Sie den external_host_name auf Ihre externe IP-Adresse (nicht auf einen Hostnamen, da DNS-Auflösung nicht ordnungsgemäß funktioniert) (regions.ini-Datei)
   Leiten Sie die entsprechenden Ports sowohl auf UDP als auch auf TCP an den OpenSim-Server weiter (Router-Konfiguration)
   Öffnen Sie die entsprechenden Ports in der Firewall des OpenSim-Servers sowohl auf UDP als auch auf TCP

   Leiten Sie den Verkehr um für Linux:
   ** iptables -t nat -A OUTPUT --dst EXTERNAL_IP -p tcp --dport 9000:9010 -j DNAT --to-destination INTERNAL_IP
   ** iptables -t nat -A OUTPUT --dst EXTERNAL_IP -p udp --dport 9000:9010 -j DNAT --to-destination INTERNAL_IP
   ** service iptables restart

Diese iptables-Zeilen leiten jeden Verkehr, der zu EXTERNAL_IP auf den Ports 9000 bis 9010 geht, zu INTERNAL_IP um. Die interne IP ist die LAN-IP Ihres Servers und die externe IP ist Ihre Internet-IP. Verwenden Sie den obigen iptables-Befehl auf allen internen Maschinen außer Ihrem Gateway/Router. Dies setzt voraus, dass Ihre Gateway/Router-Maschine nicht auch Ihren Simulator hostet. Dies setzt auch voraus, dass Sie eine Standard-ACCEPT-Politik auf Ihren internen Maschinen haben. Um sich von innerhalb Ihres LANs zu verbinden, verwenden Sie die obigen iptables-Befehle, um den Verkehr zur internen IP des Servers umzuleiten.

   Leiten Sie den Verkehr um für Windows:
   ** netsh (diese Methode benötigt Experimente und Ausarbeitung. Bitte sehen Sie sich die [[Talk
   Settings|Diskussionsseite]] für einige Vermutungen an, wo Sie anfangen können)
   *** Hinweis von paulieFlomar: Ich habe versucht, Windows-eigene Tools wie Firewall, netsh und IP Security Policy zu verwenden. Meine Erfahrung mit diesen Tools war erfolglos. Ich habe dann versucht, eine ausgehende Regel mit einigen Drittanbieter-Firewall-Produkten zu erstellen. Ich habe ZoneAlarm und Sunbelt Firewall ausprobiert. Keines dieser Produkte erlaubte mir, ausgehende Regeln zu erstellen. Schließlich habe ich versucht, eine ausgehende Regel in meiner Linux-IP-Tables-Firewall zu erstellen. Dies funktionierte. Ich habe 2 Regeln erstellt, die ich in einem Firewall-Skript vor meiner NAT-Regel platziert habe. Die Regeln waren:

iptables -t nat -A PREROUTING --dst EXTERNAL_IP -p tcp --dport 9000:9010 -j DNAT --to-destination INTERNAL_IP

iptables -t nat -A PREROUTING --dst EXTERNAL_IP -p udp --dport 9000:9010 -j DNAT --to-destination INTERNAL_IP

Diese Regeln funktionierten. Ich kann jetzt von meinem LAN aus auf meine Region zugreifen.

Optional:

• Registrieren Sie einen externen Domain-Namen (für externe Verbindungen)
• Verwenden Sie Bind für die interne Domain-Namensauflösung

[edit] DynDNS-Loopback

Diese Methode wurde erfolgreich getestet, indem www.dyndns.com (erstellt eine virtuelle Domain für Ihren PC/IP, wie yourcomputer.ath.cx) als Loopback für Geräte in einem LAN mit drei Maschinen (Pentium 2.8GHz mit Windows XP - Internet-Server, AMD Opteron mit Ubuntu 7.10 64bit - als OpenSim-Server - und MacBook mit OSX 10.4.11 - als Client), ein Modem (Thomson/Alcatel SpeedTouch 330) und ein Mini-Switch (dessen Marke niemand kennt) verwendet wurde. Die Verbindung dieser Maschinen erfolgt wie folgt: Modem -> Win-PC -> Switch -> Mac und Ubuntu. DynDNS wird verwendet, um zum Win-PC zurückzuleiten, und dann leitet es die Anforderung an den internen LAN-OpenSim-Server weiter, der alles für den Client freigibt. Was den Client betrifft, so ist er innerhalb des privaten LAN nun tatsächlich jemand im Internet, der um Zugriff auf den OpenSim-Server bittet. Wenn der Client also jemand im Internet ist, wird er auch so behandelt. Knifflig? Weitere Details folgen:

Methode:

• Setzen Sie die IP-Adresse des Simulators auf Ihre DynDNS-Domain - bearbeiten Sie opensim/bin/Regions/Regions.ini; und ändern Sie den external_host_name in external_host_name="yourcomputer.ath.cx". Lassen Sie internal_ip_address auf "0.0.0.0" und port "9000".
• Setzen Sie den Client (SecondLife Viewer) -loginuri auf "yourcomputer.ath.cx:8002" (der verwendete Port war 8002, Ihrer kann anders sein, wenn Sie ihn so konfiguriert haben, z.B. "yourcomputer.ath.cx:9000 im Standalone-Modus) - ich habe das -loginserver-Flag auch nicht verwendet. Dies kann im Grid-Manager der meisten Drittanbieter-Viewer eingestellt werden.
• Leiten Sie die oben genannten Ports auf dem Internet-Server weiter (in diesem Fall Windows XP). Dies tun Sie, indem Sie Ausnahmen in der Windows-Firewall für die oben genannten Ports erstellen, und zwar für beide Verbindungen: Internetverbindung und LAN - dies hält die Ports offen, damit die Webanforderungen über das private Netzwerk reisen können.
• Bearbeiten Sie die Datei "hosts" (unter Windows ist dies C:\Windows\System32\Drivers\etc\hosts und unter Unix-ähnlichen Systemen ist dies /etc/hosts) Eintrag auf Ihrem Internet-Server (in diesem Fall der Win XP Box) und fügen Sie die folgende Zeile hinzu: xxx.xxx.xxx.xxx yourcomputer.ath.cx. Natürlich ist xxx.xxx.xxx.xxx Ihre interne LAN-IP des OpenSim-Servers.

yourcomputer.ath.cx ist nun für alle verfügbar und Sie können sich mit dem Client anmelden!

[edit] DynDNS und die kostenlose IPCop Linux Firewall

Hier eine weitere Möglichkeit mit der IPCop Linux Firewall, DynDNS und einem OpenSimulator-Server

• Richten Sie eine IPCop-Firewall mit 3 Schnittstellen ein (rot, grün, orange) und platzieren Sie den OpenSimulator-Server auf der orangefarbenen Schnittstelle (alle OpenSimulator-Server auf einem Linux-Box). Rot ist das Internet, grün ist Ihr LAN.
• Richten Sie den DynDNS-Dienst auf der IPCop-Firewall ein.
• Ändern Sie den external_host_name in der default.xml in den DynDNS-Namen.
• Ändern Sie die internal_ip_address in der default.XML nicht, sie sollte 0.0.0.0 sein.
• Wenn vorhanden, löschen Sie alle Loopbacks in /etc/hosts, nur 127.0.0.1 sollte localhost sein.
• Passen Sie das Port-Forwarding auf der IPCop-Firewall an (8002 TCP, 9000 UDP/TCP und für jede zusätzliche Region 900X UDP/TCP). Das Port-Forwarding sollte auf die (orangefarbene) Schnittstellenadresse der OpenSimulator-Box gesetzt werden.

Dann sollte es möglich sein, sich von innerhalb des LAN (grün) zu verbinden und es ist auch möglich, sich vom Internet (über die rote Schnittstelle) zu verbinden. (Nun, die Verbindungen innerhalb des LAN werden jetzt auch über die rote Schnittstelle hergestellt, aber da dies im selben ISP-Netzwerk erfolgt, sollte es ziemlich schnell sein ;-).

• Achtung: Die Ports auf der IPCop-Firewall müssen auch geöffnet sein, wenn Sie sich von innen (grün) mit Ihrem OpenSimulator-Grid verbinden!

Wenn Sie das OS WebGui verwenden, vergessen Sie nicht, das "SMTP AUTH" in Ihrem E-Mail-Server zu setzen. Die meisten dynamischen IPs sind auf ISP-Ebene blockiert, sodass die neuen Benutzer keine Bestätigungs-E-Mail erhalten.

Dies wurde mit dem Hippo OpenSimulator Viewer und mit der Login-URL: http://DynDNSName:8002 getestet.

[edit] Lokale Verbindungen mit ZyXEL DSL-Modem/Router und NAT/Port-Weiterleitung

Diese Lösung funktioniert mit dem ZyXEL Prestige 660ME-61 DSL-Router. Es kann auch mit anderen Modellen von ZyXEL funktionieren.

Methode:

• Verbinden Sie sich per TELNET mit Ihrem ZyXEL DSL-Modem. Verwenden Sie dieselbe IP-Adresse, die Sie auch bei der Verwendung der Weboberfläche verwenden würden. Zum Beispiel ist die Standard-IP bei den meisten Embarq ZyXEL DSL-Modems 192.168.2.1.

telnet 192.168.2.1

• Geben Sie Ihr Passwort ein. Wenn Sie es nicht wissen, versuchen Sie einfach <ENTER> zu drücken oder fragen Sie Ihren ISP nach dem Passwort. Sie können es Ihnen geben oder nicht.

• Wählen Sie die Menüoption "24. System Maintenance" aus dem Menü.

Copyright (c) 1994 - 2004 ZyXEL Communications Corp. Prestige 660ME-61 Hauptmenü Getting Started Erweiterte Verwaltung 1. General Setup 21. Filter Set Configuration 2. WAN Backup Setup 22. SNMP Configuration 3. LAN Setup 23. System Password 4. Internet Access Setup 24. System Maintenance

                                    25. IP Routing Policy Setup

Advanced Applications 26. Schedule Setup 11. Remote Node Setup 12. Static Routing Setup 15. NAT Setup 99. Exit

                         Geben Sie die Menünummer ein:

• Wählen Sie die Menüoption "8. Command Interpreter Mode" aus dem Menü.

                         Menü 24 - Systemwartung
                        1.  Systemstatus
                        2.  Systeminformationen und Konsolengeschwindigkeit
                        3.  Log und Trace
                        4.  Diagnose
                        5.  Konfigurationssicherung
                        6.  Konfigurationswiederherstellung
                        7.  Firmware-Upload
                        8.  Befehl Interpreter Modus
                        9.  Anrufsteuerung
                        10. Zeit- und Datumseinstellung
                        11. Fernverwaltung
                         Geben Sie die Menünummer ein:

• Geben Sie an der Eingabeaufforderung "ip nat loopback on" ein.

Copyright (c) 1994 - 2004 ZyXEL Communications Corp. Sprint > ip nat loopback on

• Geben Sie an der Eingabeaufforderung "exit" ein.

Sprint> exit

• Wählen Sie die Menüoption "99. Exit".

• Folgen Sie allen anderen Schritten zum Konfigurieren und Starten Ihres Servers wie im Getting Started beschrieben.

[edit] Lokale Verbindungen mit dem DLink GamerLounge Extreme N Router

Netzwerk- und Routerkonfigurationen waren für 98 % aller Probleme verantwortlich, die ich bei der Einrichtung und dem Betrieb der OpenSimulator-Region-Server-Software hatte. Sicherzustellen, dass Sie einen fähigen Router richtig konfiguriert haben, sollte der erste Punkt auf der Liste der Konfigurationskontrollen für einen reibungslosen und problemlosen Betrieb der OpenSimulator-Software im GridMode sein.

Unten finden Sie eine Reihe von Screenshots mit den wichtigsten Seiten meiner Router-Konfigurationsoberfläche und den entsprechenden Einstellungen.

Die unten stehenden Einstellungen gehen davon aus, dass Sie eine ansonsten funktionierende Verbindung haben und nicht auf Themen wie Portkonflikte oder die Anmeldung Ihres Netzwerks beim ISP-Anbieternetzwerk eingehen.

1.Status

2.Advanced > Gaming

3.Routing

4.Firewall

5.Advanced network settings

• Vorausgesetzt, dass alle Informationen, die in ~opensim/bin/OpenSim.ini und in Ihren ~opensim/Regions/*.xml angegeben sind, richtig konfiguriert sind, sollten Sie startklar sein.

== Lokale und Internetverbindungen mit Linux iptables und NAT/Port-Weiterleitung == Bitte kopieren Sie dies nicht wörtlich - viel mehr sollte in eine Firewall-Konfiguration einfließen, aber dies wird zumindest das NAT mit Weiterleitung an Ihren OpenSimulator-Server sowohl innerhalb als auch außerhalb Ihres LANs zum Laufen bringen.

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
modprobe nf_conntrack_ftp
modprobe nf_nat_ftp
 
INT = "eth0" # Ihre interne Netzwerkkarte an der Firewall
EXT = "eth1" # Ihre externe Netzwerkkarte an der Firewall
IPTABLES = "/sbin/iptables" # Pfad zu Ihrem iptables-Ausführungsprogramm
 
OPENSIMEXT = "66.102.1.103/32" # Beispiel für eine externe IP - ersetzen Sie diese durch Ihre eigene
OPENSIMINT = "192.168.1.240/32" # Interne IP Ihres OpenSimulator-Servers
INTSUBNET = "192.168.1.0/24" # Ihr internes Subnetz
 
# Regeln löschen, wenn wir das Skript neu starten
$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t mangle
 
# Sane Defaults einrichten
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD DROP
 
# Erlauben Sie alle Verbindungen aus dem Netzwerk zur Firewall auf allen Ports
$IPTABLES -A INPUT -i $INT -j ACCEPT
# Erlauben Sie alle ausgehenden Verbindungen von innen. Viel besser ist es, dies zu begrenzen...
$IPTABLES -A FORWARD -o $EXT -j ACCEPT
 
# Basis-NAT konfigurieren
$IPTABLES -A FORWARD -i $EXT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $EXT -j SNAT --to-source $OUTNAT
 
# Weiterleitung für OpenSimulator konfigurieren (Sie müssen Ports hinzufügen, wenn Sie nicht im Standalone-Modus laufen oder wenn Sie mehr als eine Region betreiben)
$IPTABLES -A PREROUTING -p tcp -d $OPENSIMEXT --dport 9000 -j DNAT --to-destination $OPENSIMINT
$IPTABLES -A PREROUTING -p udp -d $OPENSIMEXT --dport 9000 -j DNAT --to-destination $OPENSIMINT
 
# Jetzt kommt der magische Saft, der es sowohl internen als auch externen Benutzern ermöglicht, auf Ihren Server zuzugreifen
# Konfigurieren Sie, dass Benutzer des internen Netzwerks den OpenSimulator-Server mit der externen IP-Adresse erreichen können. Dies behebt Verbindungsfehler zu Regionen über UDP aufgrund der NAT-Konfiguration.
# Stellen Sie sicher, dass Sie die richtige externe IP für jede Ihrer Regionen konfigurieren.
$IPTABLES -t nat -A PREROUTING -i $INT -s $INTSUBNET -d $OPENSIMEXT -j DNAT --to-destination $OPENSIMINT
$IPTABLES -t nat -A POSTROUTING -o $INT -s $INTSUBNET -d $OPENSIMINT -j SNAT --to-source $OPENSIMEXT

HINWEIS: Entgegen dem oben angezeigten sind DHCP-Dienste nicht erforderlich, um die OpenSimulator-Server-Software zu betreiben.

[edit] NAT LoopBack Router Auflistung

opensimulator.org/wiki/NAT_Loopback_Routers

[edit] VMware VMXNET3 NIC Problem

Beim Betrieb von OpenSimulator in einer 64-Bit CentOS 6 VM unter VMware ESXi 5, mit den neuesten VMware-Tools installiert und der Verwendung der VMXNET3 vNIC, stellte ich (smxy) fest, dass mein Viewer konsequent etwa 12 Minuten nach dem Verbinden von meinem Grid getrennt wurde (wobei die Child Agents früher starben, wie durch das Rotwerden der Regionen in der Mini-Map angezeigt), wobei ACK-Timeouts in den Regionskonsolen gemeldet wurden. Dieses Verhalten war zu 100 % wiederholbar. Ich entdeckte, dass das Löschen der VMXNET3 vNIC und das Ersetzen durch die E1000 vNIC (bei Beibehaltung der gleichen MAC-Adresse) das Problem vollständig beseitigte.

Einige Wochen später bemerkte ich, dass jemand (LilinEnyo) ACK-Timeouts im IRC meldete. Es stellte sich heraus, dass sie "ubuntu 64bit" unter ESXi 5 mit installierten VMware-Tools und der Verwendung der VMXNET3 vNIC betrieb. In ihrem Fall trennten die ACK-Timeouts ihren Viewer etwa 5 Minuten nach dem Verbinden. Ich ließ sie zur E1000 vNIC wechseln und das Problem wurde auch bei ihr beseitigt.

[edit] Historisch

[edit] OpenSimulator Grid - Ports für Grid-Dienste - bis Version 0.6.9

Beachten Sie, dass dies nicht mehr die aktuelle Version ist...

• TCP/8000 - Reserviert
• TCP/8001 - Grid-Server - Regionen und andere Grid-Dienste sprechen damit
• TCP/8002 - Benutzer- und Anmeldedienste - Clients, Regionen und andere Grid-Dienste sprechen damit
• TCP/8003 - Asset-Dienste - Regionen und andere Grid-Dienste sprechen damit
• TCP/8004 - Inventar-Dienste - Regionen und andere Grid-Dienste sprechen damit
• TCP/8005 - Reserviert (Dispatch-Dienste)
• TCP/8006 - Nachrichtendienste
• TCP/8895 - In frühen Versionen für die Kommunikation von Region zu Region verwendet