Hier eine Beschreibung meines Zugangs zum HamNet an meinem QTH im Testbetrieb.
Die grundsätzliche Einrichtung erfolgte nach DL1NUX.
Es wurde eine Ubiquiti NanoStation Loco M2 (airMAX NanoStation M2, NSM2) als AP gewählt
Bei der Auswahl das Geräts darauf achten, dass es die für Hamnet benötigte Bandbreite beherscht. Auf 13cm sind 5MHz Bandbreite üblich. Viele neuere Geräte können so schmal nicht mehr.
Der Einwahlknoten steht ca. 3km nördlich am Raichberg: HAMNET-DB0RAB-USER-SUED der ARIG-MN.
Ein erstes Erfolgserlebnis ist, wenn bei der Abfrage der Gegenstationen der Einwahlknoten mit Namen angezeigt wird.
Beim Updaten der NanoStation muss auf den Board-Typ geachtet werden: XW oder XM
Firmware-Version: XW.v6.3.11 Build-Nummer: 33396
Bei der geringen Entfernung komme ich mit einer Sendeleistung von -4 dBm aus. Das ist das Minimum der Nanostation.
109dB Freiraumdämpfung, 8dBi auf meiner Seite, 8(?)dBi beim Einwahlknoten sind 93dB Übertragungsdämpfung. Das ergibt rechnerisch -97dBm Empfangsleistung am Knoten. Die Empfangsleistung bei mir laut NanoStation beträgt -57dBm.
Es gibt im Hamnet keine einfache Übersicht darüber, wie gut man beim Einwahlknoten ankommt. Man kann es aber grob abschätzen durch die eigene Empfangsleistung. Für eine genauere Betrachtung bezieht man Antennengewinn und Abstrahlcharakteristik in die Freiraumdämpfung mit ein.
Der Testserver ist aktuell ein Apache, der im LAN auf einem PC mit Debian läuft. Es ist geplant, später einen Raspberry Pi zu nutzen. Der AP und der Raspi sollen über ein Solarpanel versorgt werden. Die weiteren Anmerkungen basieren auf dem stationären Betrieb an einem Standort mit Internet und einem einheitlichen LAN. Beim unabhängigen Betrieb sind einige Aspekte anders zu betrachten.
Netzwerk im LAN
Der AP zum HamNet sieht seine Welt so, dass das Hamnet das WAN („das Internet“) ist und er damit das Standard-Gateway im LAN sein muss. In einem normalen Haushalt wird man einen DSL-Router (beispielsweise eine Fritz!Box) haben, die ebenfalls sich als Standard-Gateway im LAN ansieht und darüber den Zugriff ins „echte“ Internet erlaubt. Die Geräte innerhalb des LAN holen sich typischerweise ihre Netzwerkkonfiguration über DHCP vom DSL-Router. Damit haben sie keine Route („Weg“) ins Hamnet, denn der Einzige, der etwas vom Hamnet weiß, ist der AP.
Damit das LAN weiterhin wie gewohnt funktioniert, darf der AP nicht als DHCP-Server konfiguriert werden, sondern er muss umgekehrt ein Client beim DHCP-Server des DSL-Routers sein, so wie alle anderen Geräte im LAN auch.
Um das zu lösen, muss eine statische Route definiert werden. Das kann man entweder auf jedem Gerät im LAN einzeln machen, oder man definiert es einmal für alle im DSL-Router. Dort landen ohnehin alle Pakete, weil der das Standard-Gateway ist. Die Pakete für das HamNet werden dann vom DSL-Router zum AP weitergeleitet. So sieht das in einer Fritz!Box aus, wenn der AP die IP 10.1.1.128 hat:
Hier ein Beispiel für einen Eintrag auf einem Linux-PC, wenn der AP die IP 10.0.0.50 hat. Diese direkte Konfiguration auf den einzelnen Rechnern kann sinnvoll sein, wenn nicht jeder Rechner im LAN ins HamNet kommen soll.
route add -net 44.224.0.0 netmask 255.254.0.0 gw 10.0.0.50 route add -net 44.128.0.0 netmask 255.192.0.0 gw 10.0.0.50 route add -net 44.0.0.0 netmask 255.128.0.0 gw 10.0.0.50
Um einen Service im HamNet anzubieten, muss dieser als erster Schritt im LAN angeboten werden. Wenn er im LAN ganz normal funktioniert, kann im AP ein Port-Forward eingerichtet werden. Das funktioniert im Prinzip genauso wie ein Service im LAN, der im Internet angeboten werden soll. Pakete, die auf einem bestimmten Port aus dem HamNet auf dem AP ankommen, werden einem Server im LAN durchgereicht. Bei Bedarf kann man dabei auch die Port-Nummer ändern. Man muss aber beachten, dass das Protokoll dabei nicht umgesetzt wird. Eine Weiterleitung von Port 80/tcp auf Port 443/tcp wird also nicht sinnvoll funktionieren. Auch darf umgekehrt der Service den Port 80 nicht per http-Redirect auf Port 443 mit TLS (“SSL”) weiterleiten. Für das HamNet sollte der Webserver das http-Protokoll unverschlüsselt auf Port 80 anbieten. Hier ein Beispiel, wenn der Webserver im LAN die IP 10.1.1.25 hat:
Wenn alles funktioniert, kann man den Administrator des Einstiegsknotens ins HamNet um einen statischen Eintrag bitten, sodass einem zum einen immer die gleiche IP zugewiesen wird und man zum anderen einen DNS-Eintrag bekommt. Es ist allerdings zu beachten, dass ein dauerhaft betriebener Sender eine Genehmigung von der BNetzA benötigt. Der AP ins HamNet ist formal ein Transceiver und darf erst mal nur beaufsichtigt betrieben werden. Soll er dauerhaft laufen, muss er formal ähnlich wie eine Relaisstation betrachtet werden.
Wichtig ist dabei zu verstehen, dass bei dieser Konfiguration im LAN nur die statische Route ins HamNet definiert wird. Außer dem AP sollte kein weiteres Gerät eine spezielle Konfiguration für das Hamnet benötigen. Man kann das anders konfigurieren, aber das vereinfacht es nicht.
Hier alles zusammen als Schaubild. Der AP bekommt aus dem HamNet die IP, hier 44.1.2.3 . Über NAT stellt er den Zugang aus dem LAN zur Verfügung. Der DSL-Router bekommt vom ISP seine IP, hier die 27.1.2.3. Er stellt darüber das Internet im LAN per NAT zur Verfügung. Noch weiß im LAN aber keiner vom HamNet. Daher werden im DSL-Router statische Routen eingetragen. Im NAT des AP wird gegebenenfalls noch als Port-Forward eingetragen, wo im LAN der Webserver zu finden ist. In der Netzwerk-Konfiguration der Clients im LAN muss dann nichts speziell für das HamNet eingetragen werden. Falls der Webserver allerdings für name-based Virtual-Hosts konfiguriert ist, muss ihm noch gesagt werden, wie er im HamNet heißen soll.
Default Route ins Internet
Die Default-Route der NanoStation liegt per Default im WAN, welches aktuell das WLAN, also das Hamnet ist. Damit erreicht man das Internet effektiv nicht. Die Web-GUI erlaubt die Umstellung nicht. An der ssh-Konsole geht es mit den üblichen Linux-Befehlen dagegen schon. Sobald das so eingerichtet ist, wird insbesondere der Update-Server von Ubiquiti und auch die NTP-Server im Internet gefunden.
- Nutze ssh-Interface, gleiches Passwort wie an der Web-Oberfläche
ssh ubnt@[IP im LAN]
- Prüfe aktuelle Routen
route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ... 0.0.0.0 [Gateway im HamNet] 0.0.0.0 UG 0 0 0 ath0
- Lösche Route ins WLAN (ath0)
route del -net 0.0.0.0 netmask 0.0.0.0 dev ath0
- Setze Route ins Internet (eth0)
route add -net 0.0.0.0 gw [Gateway im Internet] netmask 0.0.0.0 dev eth0
- Prüfe neue Routen
route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ... 0.0.0.0 [Gateway im Internet] 0.0.0.0 UG 0 0 0 eth0
Wenn das korrekt eingerichtet ist, funktioniert auch die Prüfung auf die aktuelle Version der Firmware:
Wie man das Reboot-fest ablegt, habe ich noch nicht heraus.