Bind9 -> rndc konfigurieren

[schwiz]

Hallo

Ich habe diese eine Anleitung http://books.google.ch/books?id=qs3M6QJ ... e&q&f=true und möchte meinen DNS-Server bind9 unter Debian installieren.

Leider kommt immer ein Fehler: bind9rndc connection failed 127.0.0.1#953: connection failed

Syslog Fehler: /etc/bind9/named.conf:11: missing ';' before '/'
/etc/bind9/named.conf:11: expected string near '/'

Was soll ich damit anfangen was soll mir die Fehlermeldung sagen? Ein Semikolon fehlt nirgends habe wie in der Anleitung angegeschrieben.


Nächste Frage wozu dient rndc? Ich kann den Server ja auch ohne rndc konfigurieren....Zudem steht ich kann unter Windows im command über den Shell rndc ausführen nun geht das gar nicht Windows kennt den Befehl gar nicht...



Danke fürs Helfen und Gruss
Nicolas

[schwiz]

Hat jemand eine Idee? Gibts hier DNS Experten oder welche die sich gut damit auskennen?

[rendegast]

/etc/bind9/.. ?

Die im default installierte named.conf hat erstmal nur 11 Zeilen

Code: Alles auswählen

# grep -n . /etc/bind/named.conf
1:// This is the primary configuration file for the BIND DNS server named.
2://
3:// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
4:// structure of BIND configuration files in Debian, *BEFORE* you customize
5:// this configuration file.
6://
7:// If you are just adding zones, please do that in /etc/bind/named.conf.local
9:include "/etc/bind/named.conf.options";
10:include "/etc/bind/named.conf.local";
11:include "/etc/bind/named.conf.default-zones";

Deine /etc/bind9/named.conf ist eine includierte Datei?
Deren Inhalt?

DESCRIPTION
rndc.conf is the configuration file for rndc, the BIND 9 name server control utility. ...

-> 'man rndc' (bind9utils)

[schwiz]

/etc/bind9/.. ?

Die im default installierte named.conf hat erstmal nur 11 Zeilen

Code: Alles auswählen

# grep -n . /etc/bind/named.conf
1:// This is the primary configuration file for the BIND DNS server named.
2://
3:// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
4:// structure of BIND configuration files in Debian, *BEFORE* you customize
5:// this configuration file.
6://
7:// If you are just adding zones, please do that in /etc/bind/named.conf.local
9:include "/etc/bind/named.conf.options";
10:include "/etc/bind/named.conf.local";
11:include "/etc/bind/named.conf.default-zones";

Deine /etc/bind9/named.conf ist eine includierte Datei?
Deren Inhalt?

Siehe Inhalt etc/bind/named.conf:

Code: Alles auswählen

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the 
// structure of BIND configuration files in Debian, *BEFORE* you customize 
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
 
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

[dufty2]

Statt

Code: Alles auswählen

inet 127.0.0.1 allow { localhost; } keys { rndc-key; };

probier mal

Code: Alles auswählen

inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };

sprich das rndc-key noch in Anführungszeichen eingeklammert.

Hoffe, dass in Deiner /etc/bind/rndc.key der key auch als
key "rndc-key" {
und nicht etwas als
key "rndc_key" {
hinterlegt ist.

[schwiz]

Bin etwas weiter gekommen hoffe ich zumindest:
Habe anhand dieser Anleitung versucht meine Zonen und Bind zu konfigurieren http://wiki.ubuntuusers.de/DNS-Server_Bind.

Jedoch klappt das auch nicht so ganz. Syslog zeigt u.a

Code: Alles auswählen

Dec 23 16:27:19 webserver2 named[1382]: reading built-in trusted keys from file '/etc/bind/bind.keys'
Dec 23 16:27:19 webserver2 named[1382]: using default UDP/IPv4 port range: [1024, 65535]
Dec 23 16:27:19 webserver2 named[1382]: using default UDP/IPv6 port range: [1024, 65535]
Dec 23 16:27:19 webserver2 named[1382]: listening on IPv6 interfaces, port 53
Dec 23 16:27:19 webserver2 named[1382]: listening on IPv4 interface lo, 127.0.0.1#53
Dec 23 16:27:19 webserver2 named[1382]: listening on IPv4 interface eth0, 192.168.1.39#53
Dec 23 16:27:19 webserver2 named[1382]: generating session key for dynamic DNS
Dec 23 16:27:19 webserver2 named[1382]: set up managed keys zone for view _default, file 'managed-keys.bind'
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: 254.169.IN-ADDR.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: 100.51.198.IN-ADDR.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: 113.0.203.IN-ADDR.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: D.F.IP6.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: 8.E.F.IP6.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: 9.E.F.IP6.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: A.E.F.IP6.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: B.E.F.IP6.ARPA
Dec 23 16:27:19 webserver2 named[1382]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
Dec 23 16:27:19 webserver2 named[1382]: command channel listening on 127.0.0.1#953
Dec 23 16:27:19 webserver2 named[1382]: the working directory is not writable
Dec 23 16:27:19 webserver2 named[1382]: zone 0.in-addr.arpa/IN: loaded serial 1
Dec 23 16:27:19 webserver2 named[1382]: zone 127.in-addr.arpa/IN: loaded serial 1
Dec 23 16:27:19 webserver2 named[1382]: zone 1.168.192.in-addr.arpa/IN: loading from master file /etc/bind/db.1.168.192 failed: file not found
Dec 23 16:27:19 webserver2 named[1382]: zone 1.168.192.in-addr.arpa/IN: not loaded due to errors.
Dec 23 16:27:19 webserver2 named[1382]: zone 255.in-addr.arpa/IN: loaded serial 1
Dec 23 16:27:19 webserver2 named[1382]: zone localhost/IN: loaded serial 2
Dec 23 16:27:19 webserver2 named[1382]: zone nicichat.tk/IN: has no NS records
Dec 23 16:27:19 webserver2 named[1382]: zone nicichat.tk/IN: not loaded due to errors.
Dec 23 16:27:19 webserver2 named[1382]: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found
Dec 23 16:27:19 webserver2 named[1382]: managed-keys-zone ./IN: loaded serial 0
Dec 23 16:27:19 webserver2 named[1382]: running

Inhalt db.nicichat.tk:

Code: Alles auswählen

;; db.nicichat.tk
;; Forwardlookupzone für nicichat.tk
;;
$TTL 3600
@       IN      SOA     ns01.nicichat.tk. hostmaster.nici-chat.tk. (
    2014031700 ; serial
    3600       ; refresh
    1800       ; retry
    604800     ; expire
    600  )      ; ttl

www.nicichat.tk. IN A 83.219.113.135
nicichat.tk. IN A 83.219.113.135
ns01.nicichat.tk. IN NS 83.219.113.135

Inhalt db.tk.nicichat

Code: Alles auswählen

;; db.1.168.192
;; Reverselookupzone für tk.nicichat
;;
;;
$TTL 3600
@       IN      SOA     ns01.nicichat.tk. hostmaster.nici-chat.tk. (
    2014031700 ; serial
    3600       ; refresh
    1800       ; retry
    604800     ; expire
    600  )     ; ttl

@ IN NS ns01.nicichat.tk.
XXX IN PTR www.nicichat.tk. 
XXX IN PTR nicichat.tk.

Was muss ich den bei "XXX" einsetzen? Meine LAN IP ist 192.168.1.39 und die letzten Byts von 39 sind dann wieviel byts wie finde ich das heraus?


Frohe Weinachten und einen guten Rutsch.
Nicolas

[dufty2]

A)
In Deiner db.nicichat.tk fehlt die Zeile
@ IN NS ns01.nicichat.tk

B) Der Mail-Empfänger ist vermutlich "hostmaster.nicichat.tk" und nicht "hostmaster.nici-chat.tk", richtig?
Also ohne Bindestrich.

C) Die korrekte Reverse-Zone wäre dann entsprechend
113.219.83.in-addr.arpa
Die gehört aber - vermutlich - nicht Dir, sondern Deinem Internetprovider.

[schwiz]

C) Die korrekte Reverse-Zone wäre dann entsprechend
113.219.83.in-addr.arpa
Die gehört aber - vermutlich - nicht Dir, sondern Deinem Internetprovider.

Aha. Was heisst das nun muss ich mir eine eigene IP-Adresse mieten damit man einen eigenen DNS-Server haben kann oder was muss ich tun?

[dufty2]

DNS-Nameserver haben - in der Regel - feste IP-Adressen, die Internetanschlüsse "für den Hausgebrauch" wechseln mal gerne.
Wenn ich mir nun

Code: Alles auswählen

$ dig -x 83.219.113.135

;; ANSWER SECTION:
135.113.219.83.in-addr.arpa. 2284 IN    PTR     135-113-219-83.dyn.cable.fcom.ch.

so anschaue, sieht das jetzt, ohne die tatsächlichen Verhältnisse vor Ort zu kennen, nach einer dynamischen sprich nicht-festen IP aus.
Deshalb lässt man den DNS-Betrieb gerne den Internetprovider selbst machen oder man hat einen Vserver (oder einen root-server (mit jeweils fester IP)) oder man bekommt von seinem Internetdienstleister eine feste IP zugewiesen (evtl. gegen einen Obulus).

Die weitere Frage wäre, warum Du unbedingt einen Reverse-Zonen-Eintrag haben möchtest.

[schwiz]

Ja es ist eine dynamische IP-Adresse. Ich will nur ausprobieren wie ein Nameserver funktioniert und meine Domain will ich darüber laufen lassen.

Was heisst das nun wenn ich eine Reverse-Zonen Eintrag mache wird der Nameserver meines ISP antworten und nicht meiner?

Um zurück zum Thema zu kommen. Auf der Seite http://wiki.ubuntuusers.de/DNS-Server_Bind steht wie ich die Konfigurationen vornehmen muss:

.....
@ IN NS rechnername.domainname.
10 IN PTR rechnername.domainname.
200 IN PTR rechner1.domainname.
201 IN PTR rechner2.domainname.

Man beachte die PTR-Records, die für die Rückwärtsübersetzung von IP-Adressen in Namen zuständig sind. Die Zahlen in der ersten Spalte stellen dabei das letzte Byte der IP-Adresse dar. Wichtig ist, dass die übersetzten Namen FQDNs (mit Punkt am Ende) sind.

Wie finde ich den heraus welches das letzte Bit der IP-Adresse ist in dieser Reverse IP-Adresse? Ich kann zwar eine binäre Schreibweise der IP-Adresse notieren und weiss auch das die IP-Adresse aus 8 mal 4 Bits bestehen also 32 Bit aber wieviel Byte nun 192.168.1.39 hat keine Ahung...

[dufty2]

Wie finde ich den heraus welches das letzte Bit der IP-Adresse ist in dieser Reverse IP-Adresse? Ich kann zwar eine binäre Schreibweise der IP-Adresse notieren und weiss auch das die IP-Adresse aus 8 mal 4 Bits bestehen also 32 Bit aber wieviel Byte nun 192.168.1.39 hat keine Ahung...

Eine IP(v4)-Adresse besteht aus 4 Bytes (= 32 bits) und diese werden voneinander durch einen Punkt (.) getrennt:
erstesByte.zweitesByte.drittesByte.letztesByte

Also ist bei Dir das letzte Byte die 39 und folglich würde in "db.1.168.192" stehen:
39 IN PTR http://www.nicichat.tk.

Ein Byte wird hierbei nicht als Folge von 8 Nullen&Einsen beschrieben, sondern durch eine Dezimalzahl (welche einen Wert zwischen 0 und 255 annehmen kann); diese Darstellung nennt man auch "dotted-decimal".

[schwiz]

C) Die korrekte Reverse-Zone wäre dann entsprechend
113.219.83.in-addr.arpa
Die gehört aber - vermutlich - nicht Dir, sondern Deinem Internetprovider.

Heisst das, dass mein Reverse-Zonen Eintrag nicht funkktioniert oder wie? Und was soll das heissen meine korrekture Reverse-Zone ist "113.219.83.in-addr.arpa"?

Der RNDC-Key ist korrekt also rndc-key und nicht rdc_key in /etc/bind9/rndc-key.
Die weiteren Fehler von oben habe ich korrigiert.

Nach dem Neustart habe ich noch einen letzten Fehler den ich selber nicht beheben kann:

Code: Alles auswählen

Dec 26 16:07:31 webserver2 named[1102]: zone nicichat.tk/IN: loaded serial 2014122601
Dec 26 16:07:31 webserver2 named[1102]: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found
Dec 26 16:07:31 webserver2 named[1102]: managed-keys-zone ./IN: loaded serial 0
Dec 26 16:07:31 webserver2 named[1102]: running

Wird gesucht und nicht gefunden einen "bind.keys" jedoch existiert. Was will mit die Fehlermeldung da sagen?

Ich habe nun mal versucht über den shell "dig @127.0.0.1 nicichat.tk" den Domainnamen aufzulösen das klappte. Nun wenn ich anstelle vom localhost 127.0.0.1 die OpenDNS-Server von Google 8.8.8.8 eingebe wird der Name nicht aufgelöst. Weshalb?

Konfiguration des NATs am Router:

Name | Anschluss-Port | IP-Adresse
Server-Linux_DNS 53 192.168. 1. 39

[dufty2]

C) Die korrekte Reverse-Zone wäre dann entsprechend
113.219.83.in-addr.arpa
Die gehört aber - vermutlich - nicht Dir, sondern Deinem Internetprovider.

Heisst das, dass mein Reverse-Zonen Eintrag nicht funkktioniert oder wie? Und was soll das heissen meine korrekture Reverse-Zone ist "113.219.83.in-addr.arpa"?

Yep, denn wir lesen ab:

Code: Alles auswählen

$ dig -x 83.219.113.136
<snip>
;; ANSWER SECTION:
136.113.219.83.in-addr.arpa. 3600 IN    PTR     136-113-219-83.dyn.cable.fcom.ch.
<snap>

Wird gesucht und nicht gefunden einen "bind.keys" jedoch existiert. Was will mit die Fehlermeldung da sagen?

Die von bind nicht gefundene Datei heisst nicht "bind.keys" sondern "managed-keys.bind".
Jene sucht er - vermutlich - unterhalb von "/var/cache/bind".
Somit

Code: Alles auswählen

# touch /var/cache/bind/managed-keys.bind
# chown bind:bind /var/cache/bind/managed-keys.bind

Ich habe nun mal versucht über den shell "dig @127.0.0.1 nicichat.tk" den Domainnamen aufzulösen das klappte. Nun wenn ich anstelle vom localhost 127.0.0.1 die OpenDNS-Server von Google 8.8.8.8 eingebe wird der Name nicht aufgelöst. Weshalb?

Konfiguration des NATs am Router:

Name | Anschluss-Port | IP-Adresse
Server-Linux_DNS 53 192.168. 1. 39

Das kann viele Ursachen haben. Derzeit ist laut DNS

Code: Alles auswählen

$ dig ns nicichat.tk    
;; ANSWER SECTION:
nicichat.tk.            91      IN      NS      ns02.nicichat.tk.
nicichat.tk.            91      IN      NS      ns01.nicichat.tk.

$ dig ns01.nicichat.tk    
;; ANSWER SECTION:
ns01.nicichat.tk.       6972    IN      A       83.219.113.136

Aber vielleicht hast Du die "83.219.113.136" gar nicht mehr, sondern die "83.219.113.135" (wieder) oder "83.219.113.137". Wer weiss?
Oder Du hast noch iptables eingeschaltet? Oder der bind lauscht nur auf 127.0.0.1?

PS:
Die IPs der OpenDNS-Server lauten
208.67.222.222
208.67.220.220

Die IPs der Google-DNS-Server sind
8.8.8.8
8.8.4.4

[schwiz]

Ich habe nun mal versucht über den shell "dig @127.0.0.1 nicichat.tk" den Domainnamen aufzulösen das klappte. Nun wenn ich anstelle vom localhost 127.0.0.1 die OpenDNS-Server von Google 8.8.8.8 eingebe wird der Name nicht aufgelöst. Weshalb?

Das kann viele Ursachen haben. Derzeit ist laut DNS

Code: Alles auswählen

$ dig ns nicichat.tk    
;; ANSWER SECTION:
nicichat.tk.            91      IN      NS      ns02.nicichat.tk.
nicichat.tk.            91      IN      NS      ns01.nicichat.tk.

$ dig ns01.nicichat.tk    
;; ANSWER SECTION:
ns01.nicichat.tk.       6972    IN      A       83.219.113.136

Aber vielleicht hast Du die "83.219.113.136" gar nicht mehr, sondern die "83.219.113.135" (wieder) oder "83.219.113.137". Wer weiss?
Oder Du hast noch iptables eingeschaltet? Oder der bind lauscht nur auf 127.0.0.1?

Sorry, hatte mich da mal mit der IP-Adresse verschrieben die richtige lautet 83.219.113.136 und diese habe ich seit etwa Juli 2014. Ich habe kein iptables installiert auf dem Server. Ob bind nur auf 127.0.0.1 lausch könnte ein anhaltspunkt sein. Was heisst das aber konkret? Was muss ich wo anpassen?

[dufty2]

So wie es ausschaut, funktioniert Dein bind, aber nur TCP (auf Port 53).
UDP (Port 53) ist aber das häufigere Protokoll, welches für DNS benutzt wird.

Musst mal gucken, evtl. liegt es am NAT Deines Routers, dass dort nochmal explicit UDP (für Port 53 / DNS) freigeschalten werden muss.

[schwiz]

So wie es ausschaut, funktioniert Dein bind, aber nur TCP (auf Port 53).
UDP (Port 53) ist aber das häufigere Protokoll, welches für DNS benutzt wird.

Musst mal gucken, evtl. liegt es am NAT Deines Routers, dass dort nochmal explicit UDP (für Port 53 / DNS) freigeschalten werden muss.

Danke für die schnelle Antwort werde ich tun.

Oder der bind lauscht nur auf 127.0.0.1?

Weiter habe ich folgende gefunden auf http://wiki.ubuntuusers.de/DNS-Server_B ... figuration:

Code: Alles auswählen

Standardmäßig lauscht der Bind-Daemon auf allen verfügbaren Netzwerkschnittstellen. Dies kann unerwünscht sein, wenn man ihn bspw. auf einem Gateway betreibt, ohne die interne Zone im Internet preisgeben zu wollen. In diesem Fall muss man in einem Editor mit Root-Rechten [2] die Datei named.conf.options bearbeiten und die folgende Zeile in den options-Block eintragen:
        listen-on { 127.0.0.1; 192.168.0.10; };
Die Angabe der IP-Adresse 192.168.0.10 muss natürlich an die IP-Adresse des Bind-Servers im lokalen Netzwerk angepasst werden. Wichtig ist auch, den Localhost, also 127.0.0.1, nicht zu vergessen, sowie auf die korrekte Verwendung der Semikolons zu achten.

Meinst du das? Ich kann die Direktive "listen-on" nicht finden. Du meinst er lausche nur auf den localhost wo finde ich diesen Befehl? Ich kann in den Konfigs nichts finden.

[dufty2]

Dann ist ja gut, wenn die listen-direktive nicht vorhanden ist, sollte er - wie im Artikel beschrieben - nicht nur auf localhost lauschen.
Kannst ja mal testen, statt
"dig @127.0.0.1 nicichat.tk"
dann das
"dig @192.168.1.39 nicichat.tk"
zu nehmen.

PS
Mit TCP geht per
dig +tcp @192.168.1.39 nicichat.tk

Mit UDP geht per
dig +notcp @192.168.1.39 nicichat.tk

[schwiz]

So wie es ausschaut, funktioniert Dein bind, aber nur TCP (auf Port 53).
UDP (Port 53) ist aber das häufigere Protokoll, welches für DNS benutzt wird.

Musst mal gucken, evtl. liegt es am NAT Deines Routers, dass dort nochmal explicit UDP (für Port 53 / DNS) freigeschalten werden muss.

So wie es aussieht ist der Port 53 UDP und 53 TCP freigeschalten. An dem liegts also wohl nicht.

[schwiz]

Dann ist ja gut, wenn die listen-direktive nicht vorhanden ist, sollte er - wie im Artikel beschrieben - nicht nur auf localhost lauschen.
Kannst ja mal testen, statt
"dig @127.0.0.1 nicichat.tk"
dann das
"dig @192.168.1.39 nicichat.tk"
zu nehmen.

PS
Mit TCP geht per
dig +tcp @192.168.1.39 nicichat.tk

Mit UDP geht per
dig +notcp @192.168.1.39 nicichat.tk

Habe ich versucht alles ging und wurde korrekt aufgelöst auch über UDP:

; <<>> DiG 9.7.3 <<>> +notcp @192.168.1.39 nicichat.tk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52447
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;nicichat.tk. IN A

;; ANSWER SECTION:
nicichat.tk. 1800 IN A 83.219.113.136

;; AUTHORITY SECTION:
nicichat.tk. 1800 IN NS ns01.nicichat.tk.

;; ADDITIONAL SECTION:
ns01.nicichat.tk. 1800 IN A 83.219.113.136

[dufty2]

So wie es aussieht ist der Port 53 UDP und 53 TCP freigeschalten. An dem liegts also wohl nicht.

Aha, und woran machst Du fest, dass auch UDP freigeschalten ist?
Diese HTTP & (S)FTP sind allesamt "TCP-Protokolle".

Code: Alles auswählen

$ dig +tcp www.nicichat.tk @83.219.113.136
;; ANSWER SECTION:
www.nicichat.tk.        1800    IN      A       83.219.113.136

$ dig +notcp www.nicichat.tk @83.219.113.136
;; connection timed out; no servers could be reached

[schwiz]

So wie es aussieht ist der Port 53 UDP und 53 TCP freigeschalten. An dem liegts also wohl nicht.

Aha, und woran machst Du fest, dass auch UDP freigeschalten ist?
Diese HTTP & (S)FTP sind allesamt "TCP-Protokolle".

Code: Alles auswählen

$ dig +tcp www.nicichat.tk @83.219.113.136
;; ANSWER SECTION:
www.nicichat.tk.        1800    IN      A       83.219.113.136

$ dig +notcp www.nicichat.tk @83.219.113.136
;; connection timed out; no servers could be reached

Na gut, wenn der Hersteller des Router festlegt das man DNS bei NAT freischalten kann nehme ich schwer an das der Port 53 für UDP und TCP definiert ist (siehe Screenshot beim Dropdown-Menu rechts neben dem Dienstnamen). Soll ich zur Sicherheit den Hersteller anfragen?

Ich frag mal beim Hersteller.

[dufty2]

Bei "Dienstname" hast Du (im 2. Feld) "User Defined" ausgewählt.
Ich würde es dort mal mit "DNS" probieren.

[schwiz]

Bei "Dienstname" hast Du (im 2. Feld) "User Defined" ausgewählt.
Ich würde es dort mal mit "DNS" probieren.

Habe ich gemacht. Das User Define bleibt nachdem ich alles neu eingestellt habe.
Das wird wohl so maskiert bleiben als User Define.

[dufty2]

Mmh, um zu schauen, ob das NAT funktioniert, könntest Du nochmal
dig +notcp @8.8.8.8 nicichat.tk
probieren und gleichzeitig einen tcpdump laufen lassen auf Deinen Linux-Server, um zu sehen, ob
DNS-Anfrage von 8.8.8.8 reinkommen.

[schwiz]

Mmh, um zu schauen, ob das NAT funktioniert, könntest Du nochmal
dig +notcp @8.8.8.8 nicichat.tk
probieren und gleichzeitig einen tcpdump laufen lassen auf Deinen Linux-Server, um zu sehen, ob
DNS-Anfrage von 8.8.8.8 reinkommen.

Also habe ich nun das Programm installiert und gestartet nun wenn die Aufzeichnung des Datenverkehrs läuft kann ich keine weiteren Eingaben machen: