Gratis Internet (2): DNS Tunnel und auth. NS mit einer statischen IP

Aus NOBAQ
Zur Navigation springenZur Suche springen
Isc.gif

Ich komme nun zum zweiten Teil meines Artikels: Der Serverendpunkt für einen DNS Tunnel. Wie in Gratis Internet (1): Australien, DNS- und ICMP-Tunnel beschrieben ist, ist dies mit ozymandns einfach, wenn man einfach eine statische IP Adresse hat auf der noch kein DNS Server authoritiv tätig ist. Ist dies aber der Fall, so gibt es einige Hürden zu überwinden....


Auf meiner einzigen statischen IP Adresse (193.154.229.55) läuft bereits ein authoritiver Nameserver, der u.a. für nobaq.net. verantwortlich ist. Macht nichts, dachte ich mir, mit bind kann man gewiss Anfragen für die Tunneldomain “tunnel.nobaq.net” an einen anderen NS weiterleiten. Nämlich an nomde.pl, der auf einem anderen Port lauscht. Gesagt, getan, nomde.pl wurde so geändert, dass Ozymandns auf Port 10053 lauscht. Einfach in der Datei ganz runter scrollen und für LocalPort folgendes setzen: 

my $ns = Net::DNS::Nameserver->new(
	LocalPort => 10053,
	ReplyHandler => \&reply_handler,
	Verbose => 2,
	) || die "couldn't create nameserver object\n";


Für forwarders muss Rekursion aktiv sein

In meiner named.conf befindet sich folgender Abschnitt für meine normale Domain “nobaq.net”: 

zone "nobaq.net." {
	type master;
	file "/etc/bind/db.nobaq.net";
	allow-transfer {
		62.99.247.88; // slave.nobaq.net.
		129.27.203.100; // oeh.htu.tugraz.at.
	};
};

Was liegt nun näher als folgenden Eintrag hinzuzufügen: 

zone "tunnel.nobaq.net." {
	type forward;
	forward only;
	forwarders { 192.168.200.113 port 10015; };
};

Befrage ich nun den DNS Server nach meinem schönen neuen Tunnel schlägt dies aber fehl: 

$ dig @192.168.200.113 data.tunnel.nobaq.net. TXT
; <<>> DiG 9.3.4 <<>> @192.168.200.113 data.tunnel.nobaq.net.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49579
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; QUESTION SECTION:
;data.tunnel.nobaq.net. IN A
;; AUTHORITY SECTION:
. 3600000 IN NS L.ROOT-SERVERS.NET.
. 3600000 IN NS M.ROOT-SERVERS.NET.
. 3600000 IN NS A.ROOT-SERVERS.NET.
. 3600000 IN NS B.ROOT-SERVERS.NET.
. 3600000 IN NS C.ROOT-SERVERS.NET.
. 3600000 IN NS D.ROOT-SERVERS.NET.
. 3600000 IN NS E.ROOT-SERVERS.NET.
. 3600000 IN NS F.ROOT-SERVERS.NET.
. 3600000 IN NS G.ROOT-SERVERS.NET.
. 3600000 IN NS H.ROOT-SERVERS.NET.
. 3600000 IN NS I.ROOT-SERVERS.NET.
. 3600000 IN NS J.ROOT-SERVERS.NET.
. 3600000 IN NS K.ROOT-SERVERS.NET.
;; Query time: 44 msec
;; SERVER: 192.168.200.113#53(192.168.200.113)
;; WHEN: Tue Dec 18 20:38:55 2007
;; MSG SIZE rcvd: 251

Nach langem Hin&Her bin ich dann draufgekommen: Ich hatte - da es sich ja nur um einen authoritiven Server für “nobaq.net” handelt die Rekursion abgeschalten um einen OpenDNS zu vermeiden. Setzt man in der named.conf 

recursion yes;

ist der Spuk vorbei und der Tunnelserver antwortet brav :-)


Nächster Versuch: Eigene Domain für den Tunnel

Aber es wollte immer noch nicht klappen. Ich habe in die Zone "nobaq.net." folgenden Eintrag hinzugefügt: 

tunnel.nobaq.net. IN NS ns1.nobaq.net.

Damit sollte "tunnel" an den gleichen NS deligiert werden wie ns1.nobaq.net. Das funktionierte wenn man mit dig den Server direkt befragt. Aber sonst erhielt man immer Endlosschleifen.

Also war die nächste naheliegende Idee für mich: Wenn es nobaq.net. bereits gibt, kann es keinen forward für tunnel.nobaq.net. geben. Also habe ich voller Euphorie den NS Record für nobaq.dnstunnel.de geholt und meine named.conf wie folgt abgeändert: 

zone "nobaq.dnstunnel.de." {
	type forward;
	forward only;
	forwarders { 192.168.200.113 port 10015; };
};

Aber das Problem blieb immer das gleiche: Wenn man den NS direkt mit dig befragt läuft alles. Wenn man aber über einen anderen DNS Server abfragt (z.B. über den des Providers) bekommt man immer Antworten über die Rootserver in einer Endlosschleife.


Bind kanns einfach nicht :-(

Die Antwort brachte mir eine eingehende Recherche mit groups.google.com. Die Lösung lautet: Forwarders in Bind funktionieren nur mit rekursiven Abfragen. Nameserver unter sich fragen aber i.d.R. iterativ ab! Das erklärt auch das Verhalten des Tests:

  1. Frage ich direkt mit dig @ns1.nobaq.net ab geht es. Wieso? dig sendet eine rekursive Anfrage
  2. Frage ich mit dem “+trace”-Flag an erhalte ich eine zirkuläre Abhängigkeit bei meinem Bind: Nachdem “+trace” eine iterative Anfrage impliziert wird der forwarders-Block komplett ignoriert. Da sonst mein Nameserver keine weiteren Informationen zur Anfrage hat, verweist er einfach wieder auf die Root-Server
  3. Frage ich normal über einen anderen DNS Server an, erhalte ich einfach den SOA Record von nobaq.net. als Ergebnis. Technisch gesehen funktioniert das gleiche wie bei (2).


Die Lösung: dnsmasq

Es steht nun eines fest: Der mächtige bind9 kann einfach das (für mich solche selbstverständlichen Dinge!) einfach nicht. Damit ist es sozusagen nicht möglich, einen NS hinter einer NAT Firewall als authoritiven NS zu betreiben, wobei ein anderer bind an der öffentlichen IP als “Reverse Proxy” fungiert. Also entweder ich bastle selbst etwas oder ich habe das Glück und finde so eine Art "DNS Proxy".

Die Lösung heisst dnsmasq. Obwohl es für etwas ganz anderes konzipiert ist, lässt sich dnsmasq so konfigurieren dass es Anfragen einfach passend an andere Nameserver weiterleitet. Im Gegensatz zu Bind hat dnsmasq nicht das Problem einfach nur rekursive Anfragen weiterzuleiten, sondern tut dies auch mit iterativen!

Zusätzlich zu nomde.pl weise ich nun auch Bind an, an einem anderen Port zu lauschen. In die named.conf kommt: 

listen-on port 1053 { 192.168.200.113; };

In Debian ist dnsmasq relativ schnell installiert: 

aptitude install dnsmasq

Die /etc/dnsmasq.conf sieht dann so aus: 

no-hosts
no-resolv
no-poll
domain-needed
no-negcache
cache-size=0
server=/tunnel.nobaq.net/192.168.200.113#10053
server=/nobaq.net/stiftingtal.net/hammler.info/nobaq.eu/192.168.200.113#1053

Diese Konfiguration dreht den eingebauten DHCP-Server einmal komplett ab. Zusätzlich wird /etc/hosts und /etc/resolv.conf komplett ignoriert - der Part, für der dnsmasq eigentlich gut ist. Nun werden zwei Weiterleitungen definiert: Der Tunnel und meine authoritiven Domains. Kommt eine Anfrage für tunnel.nobaq.net. rein, wird diese an ozymandns (nomde.pl) weitergeleitet. Kommt eine Anfrage für die authoritiven Domains rein, wird diese an Bind weitergeleitet.

Bind braucht nun nur mehr iterativ antworten, d.h. es kann wieder 

recursion no;

gesetzt werden. Weiters verhält sich dnsmasq hier genauso wie man es erwarten würde: tunnel.nobaq.net. "überschreibt" nobaq.net. D.h. die Tunneldomain kann nun doch eine Subdomain des gleichen Servers sein! Wie es nun mit dem NS Eintrag für "tunnel" in "nobaq.net" aussieht ist ziemlich egal, denn diese Anfrage würde den bind nie erreichen, da sie dnsmasq bereits zu ozymandns leitet. "Spasshalber" hab ich den NS Record aber trotzdem drinnen gelassen.

Weiters ist zu erkennen dass keine andere Weiterleitung definiert ist. Anfragen an andere Domains werden so einfach nicht beantwortet.


Achtung bei den Zonentransfers

Obwohl ich anfangs sehr erstaunt war dass dnsmasq sogar anständig mit Zonentransfers umgehen kann habe ich bald gemerkt dass das nicht so optimal läuft: Die Anfragen kommen für bind ja jetzt von der lokalen IP “192.168.200.113″, also von dnsmasq. allow-transfer kann ich jetzt also nicht mehr verwenden. Oder ich trage 192.168.200.113 ein, was heissen würde dass jeder Rechner im Internet einen Zonentransfer initiieren könnte. Ein Sicherheitsrisiko das nicht annehmbar ist.

Ich habe versucht mit DNSSEC zu arbeiten, d.h. einen Key zu erstellen und nur DNS Server die den passenden Schlüssel dazu haben dürfen Transfers initieeren. Doch hierbei ist wiederum dnsmasq gescheitert: Diese Pakete erkennt es als fehlerhaft und werden nicht weitergeleitet.

Dabei ist die Lösung doch recht einfach! Bind9 läuft ja sowieso schon an einem anderen Port (1053). Der NAT Router braucht also nur zusätzlich diesen weiterleiten. In den slave-Servern steht dann einfach: 

zone "nobaq.net." {
	type slave;
	file "slave/nobaq.net";
	masters { 193.154.229.55 port 1053; };
};

Also ist einfach ein anderer Port (1053 statt default: 55) angegeben. Jetzt funktionieren die Transfers wieder gehabt incl. allow-transfer!


Startscript für ozymandns/nomde.pl

Sowohl bind9 als auch dnsmasq haben von Debian die passenden Startscripte. Für ozymandns hab ich die /etc/init.d/ozymandns erstellt. Das Vorgehen ist analog wie auf dnstunnel.de beschrieben. 

#!/bin/sh
set -e
case "$1" in
start)
	echo -n "Starting ozymandns listener..."
	screen -d -m /usr/local/sbin/ozymandns-listener
	echo "."
	;;
stop)
	echo "Stopping ozymandns listener..."
	test -f /var/run/ozymandns.pid && kill `cat /var/run/ozymandns.pid` 2>/dev/null
	rm -f /var/run/ozymandns.pid
	;;
restart|force-reload)
	$0 stop
	sleep 1
	$0 start
	;;
*)
	echo "Usage: $0 {start|stop|restart|force-reload}" >&2
	exit 3
	;;
esac
:

ozymandns-listener sieht so aus: 


#!/bin/sh
REPLYIP=193.154.229.55
DNSHOST=password.tunnel.nobaq.net
echo $$ > /var/run/ozymandns.pid
while [[ -e /var/run/ozymandns.pid ]]
do
	cd /usr/local/sbin
	./nomde.pl -i $REPLYIP $DNSHOST >/dev/null 2>&1
done

Ich wollte es zuerst auch nicht wahrhaben, aber das “cd” ist wichtig! Denn nomde.pl will als Anfrage auf TXT Records den eigenen Sourcecode ausgeben und startet daher nicht wenn man sich nicht im gleichen Verzeichnis befindet wie nomde.pl selbst. Es produziert höchstens eine hohe CPU Last ;-)


Fazit

Nun ist es geschafft: Ich konnte erfolgreich einen Teil meiner Domain nobaq.net für einen Datentunnel einrichten: tunnel.nobaq.net. Gibt man zusätzlich ein “Passwort” davor ein (schützt vor unberechtigtem Zugriff) und “sshdns” wird man sofort per ssh an einen vorgegebenen Rechner verbunden. Bei mir steht dazu in der nomde.pl: 

$opts{forward} = "sshdns:192.168.200.121:1984";

Auf jedem Linuxrechner weltweit, der über eine nicht ins Internet kommt aber wo ein firmeninterner DNS Server Anfragen aus dem Internet beantwortet kann nun eine Internetverbindung auf einer Linuxmaschine über ssh hergestellt werden: 

ssh -o ProxyCommand="./droute.pl -r DNS-Server-IP sshdns.passwort.tunnel.nobaq.net" domain.invalid.

Es empflielt sich dabei, mit “-C” die Kompression einzuschalten. Zusätzlich können nun per SSH Tunnels aufgebaut werden, z.B. zu einem Proxyserver zum Internetsurfen oder zum Mailserver. Oder noch besser: ssh einen SOCKS-Proxy aufmachen lassen!

Wenn ich jedoch wieder einmal in die Lage kommen sollte, Internet über DNS Tunnel zu benötigen ist die Wahrscheinlichkeit hoch, dass ich kein Linux haben werde sondern Windows. Aber auch das habe ich nach langer Arbeit geschafft. Und werde ich im dritten Teil des Artikels beschreiben :-)

Kommentare

<comments />

Abgerufen von „http://niki.hammler.net/w/index.php?title=Gratis_Internet_(2):_DNS_Tunnel_und_auth._NS_mit_einer_statischen_IP&oldid=726“