22. 10

Wer kennt das nicht, Handy ist zu langsam (GPRS) oder zu teuer (UMTS) und der einzige empfangbare Accespoint will auch noch bezahlt werden. Zumindest für klassischen Traffic, denn DNS lassen die meisten Hotspots durch. Und genau hier greift dns2tcp. Die Dokumenatation ist etwas lückenhaft, aber nachdem ich schon für GRML-Tips die Installation beschrieben habe, will ich dies hier auch nocheinmal tun:

Auf Serverseite brauchen wir eine IP, auf der Port 53 UDP noch frei ist. tcp2dns erledigt nicht die Aufgaben eines normalen DNS-Servers! Im bereits vorhandenen Nameserver legen wir nun die passenden Records an, hier in Form eines Zonefileschnipsels:

dnstun.example.com. 3600 IN NS host.example.com.
dnstun.example.com. 3600 IN A 192.168.1.1
host.example.com. 3600 IN A 192.168.1.1
dnstun.example.com ist hierbei die Zone, welche wir (exklusiv!) für das Tunneln verwenden, und welche nun ihren NS-RR sowie der späteren besseren ansprechbarkeit halber auch einen A-Record. host.example.com dürfte im normalfall bereits existieren, wenn nicht muss er aufgrund der Erwähnung im NS-Record angelegt werden.
Für eine Erläuterung, weshalb dieser Nameserver einen A-Record für dnstun.example.com enthalten darf, obwohl er für diese Zone nicht autoritativ ist, siehe Glue Record in der Wikipedia.

Dazu einen passend konfigurierten dns2tcpd:

# cat /etc/dns2tcpd.conf
listen = 192.168.1.1            # the ip dnstun should listen on
port = 53 #" port " " " "
user = nobody
chroot = /tmp
domain = dnstun.example.com.    # the zone as specified inside dns
ressources = ssh:127.0.0.1:22   # available resources

Die Resourcen definieren hierbei einzelne Tunnelendpunkte, die beim aufbauen einer Verbindung ausgewählt werden können.

Starten wir den Daemon und der Server ist bereit (Achtung, evtl. Debian-spezifisch!)

# cat > /etc/default/dns2tcp << EOF
# Set ENABLED to 1 if you want the init script to start dns2tcpd.
ENABLED=1
USER=nobody
EOF
# /etc/init.d/dns2tcp start

Auf dem Client muss nun dns2tcp mit passenden Parametern gestartet werden, und es tut. Dabei gibt es zwei Möglichkeiten, jenachdem ob der DNS des Netzwerks verwendet werden soll, oder ob einfach DNS-Traffic über Port 53 nach draussen gehen soll.

Solange der DNS im internen Netz alles außen auflöst, tut's folgendermaßen:


# grep nameserver /etc/resolv.conf
nameserver 172.16.42.1
# dns2tcpc -z dnstun.example.com 172.16.42.1
# dns2tcpc -z dnstun.example.com $(awk '/^nameserver/ {print $2}' /etc/resolv.conf)
Available connection(s) :
 ssh
# dns2tcpc -r ssh -l 2222 -z dnstun.example.com 172.16.42.1 &
# dns2tcpc -r ssh -l 2222 -z dnstun.example.com $(awk '/^nameserver/ {print $2}' /etc/resolv.conf)
Listenning on port : 2222
# ssh localhost -p 2222
user@host.example.com:~#

Wenn allerdings nur Port 53 für Verkehr mit der Außenwelt offen ist, geben wir unseren dns2tcpd auch gleich als DNS-Server mit an:

# dns2tcpc -z dnstun.example.com dnstun.example.com
Available connection(s) :
 ssh
# dns2tcpc -r ssh -l 2222 -z dnstun.example.com dnstun.example.com &
Listenning on port : 2222
# ssh localhost -p 2222
user@host.example.com:~# 

An der Tatsache, dass wir immer einen Port auswählen müssen, auf den dns2tcp Clientseitig laufen soll, zeigt sich auch eine der besonderheiten gegenüber den ganzen anderen DNS-Tunnel-Lösungen. Hier wird wirklich nur TCP getunnelt, und damit der sonst durch ein mitgetunneltes IP entstehende Overhead eingespart, so dass insgesamt mehr Platz für die gewünschte Payload (oder doch Nonpay-Load *g*) bleibt.

Wenn über die Verbindung nun mehr als nur SSH gehen soll - das WLAN ist unverschlüsselt, da soll sowieso nur verschlüsselter Traffic drüber. Also nutzen wir gerade die nette Socks5-Proxy-Option von SSH:

-D [bind_address:]port
Specifies a local “dynamic” application-level port forwarding. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure chan‐ nel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server. Only root can forward privileged ports. Dynamic port forwardings can also be specified in the configuration file.
Nun tut ein ssh localhost -p 2222 -D 8080, und wir haben einerseits unsere SSH-Verbindung offen, andererseits auf Port 8080 einen Proxy lauschen, den wir nun allen Programmen, die sonst noch übers Netzwerk nach draussen sprechen wollen, nurnoch mitgeben müssen.

Tags für diesen Artikel: ,

Trackbacks


Keine Trackbacks

Kommentare

Ansicht der Kommentare: (Linear | Verschachtelt)

Wie stabil ist denn dns2tcp, und wird das noch aktiv entwickelt? Ich Verwend zur Zeit nstx, aber mir scheint dass dessen Server nicht so ganz stabil läuft.

Und wäre es eigentlich auch sinnvollsten, ein „dns2udp“ zu entwickeln und openvpn drüber laufen zu lassen? Dann hat man kein TCP im Spiel wo keines sein muss, und openvpn ist (soweit ich weiß) recht gut im Umgang mit schlechten Links. Also statt HTTP over SOCKS over SSH over TCP over DNS wäre das HTTP over TCP over OpenVPN over UDP over DNS.

Ich könnte mir halt denken das so ein dns2udp wesentlich simpler wäre, und man das erprobte Verbindungsmangement-Zeug von openvpn nehmen kann.
#1 Joachim Breitner (Homepage) am 22.10.2007 17:35
Ja, man müsste einfach mal schauen was da gefiltert wird....solange der Port einfach so offen ist (was wohl meistens der Fall ist), kann man sein openvpn ja auch einfach auf 53/udp lauschen lassen ;)
#1.1 mømø (Homepage) am 22.10.2007 18:09
Meist sind aber echte alle Ports nach draußen durch und man muss ich auf die DNS-Forwards verlassen... deswegen ja dns2tcp.
#1.1.1 Joachim Breitner (Homepage) am 22.10.2007 18:12

Kommentar schreiben


Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Pavatar, Gravatar, MyBlogLog, Monster ID, Pavatar Autoren-Bilder werden unterstützt.
HTML-Tags werden in ihre Entities umgewandelt.
BBCode-Formatierung erlaubt