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 Installationbeschrieben 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:]portNun tut ein
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.
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.