iodine

Dies ist eine Software, mit der Sie IPv4-Daten durch einen DNS-Server tunneln können. Dies kann in verschiedenen Situationen nützlich sein, in denen der Internetzugang durch eine Firewall blockiert ist, DNS-Abfragen jedoch erlaubt sind.

KOMPILIEREN

Iodine hat kein configure-Skript. Es gibt zwei optionale Funktionen für Linux (SELinux- und systemd-Unterstützung), die automatisch aktiviert werden, wenn die relevanten Header-Dateien in /usr/include gefunden werden. (Siehe Skript unter ./src/osflags)

Führen Sie make aus, um die Server- und Client-Binaries zu kompilieren. Führen Sie make install aus, um Binaries und Manpage in das Zielverzeichnis zu kopieren. Führen Sie make test aus, um die Unit-Tests zu kompilieren und auszuführen. (Erfordert die Bibliothek check)

SCHNELLSTART

Probieren Sie es in Ihrem eigenen LAN aus! Befolgen Sie diese einfachen Schritte:

Führen Sie auf Ihrem Server aus: ./iodined -f 10.0.0.1 test.com. Wenn Sie das Netz 10.0.0.0 bereits verwenden, nutzen Sie ein anderes internes Netz wie 172.16.0.0.
Geben Sie ein Passwort ein.
Führen Sie auf dem Client aus: ./iodine -f -r 192.168.0.1 test.com. Ersetzen Sie 192.168.0.1 durch die IP-Adresse Ihres Servers.
Geben Sie dasselbe Passwort ein.
Nun hat der Client die Tunnel-IP 10.0.0.2 und der Server 10.0.0.1.
Versuchen Sie, sich gegenseitig durch den Tunnel anzupingen.
Fertig! :)

Um es tatsächlich über einen weiterleitenden Nameserver zu nutzen, siehe unten.

VERWENDUNG

Hinweis: Server und Client müssen exakt dasselbe Protokoll sprechen. In den meisten Fällen bedeutet dies, dieselbe iodine-Version auszuführen. Leider ist die Implementierung von Abwärts- und Vorwärtskompatibilität des Protokolls in der Regel nicht machbar.

Serverseite

Um diesen Tunnel zu nutzen, benötigen Sie die Kontrolle über eine echte Domain (wie mydomain.com) und einen Server mit einer öffentlichen IP-Adresse, auf dem iodined läuft. Wenn auf diesem Server bereits ein DNS-Programm läuft, ändern Sie dessen Lauschport und verwenden Sie dann die Option -b von iodined, damit iodined die DNS-Anfragen weiterleitet. (Beachten Sie, dass dieses Vorgehen in Produktionsumgebungen nicht empfohlen wird, da die DNS-Weiterleitung von iodined nicht vollständig transparent ist; Zonentransfers funktionieren beispielsweise nicht.) Alternativ können Sie die Subdomain von Ihrem DNS-Server an iodined weiterleiten, das dann auf einem anderen Port (-p) laufen muss.

Delegieren Sie dann eine Subdomain (z. B. t1.mydomain.com) an den iodined-Server. Wenn Sie BIND für Ihre Domain verwenden, fügen Sie der Zonendatei zwei Zeilen wie diese hinzu:

t1		IN	NS	t1ns.mydomain.com.		; note the dot!
t1ns		IN	A	10.15.213.99

Die NS-Zeile ist alles, was benötigt wird, um Abfragen für die Subdomain t1 an den t1ns-Server weiterzuleiten. Wir verwenden einen kurzen Namen für die Subdomain, um so viel Platz wie möglich für den Datenverkehr freizuhalten. Am Ende der NS-Zeile steht der Name Ihres iodined-Servers. Dies kann ein beliebiger Name sein, der überallhin zeigen kann, aber in diesem Fall wird er einfach in derselben Zonendatei gehalten. Es muss ein Name sein (keine IP-Adresse), und dieser Name selbst muss einen A-Eintrag haben (keinen CNAME).

Wenn Ihr iodined-Server eine dynamische IP hat, verwenden Sie einen dynamischen DNS-Anbieter. Richten Sie die NS-Zeile einfach darauf aus und lassen Sie die A-Zeile weg:

t1		IN	NS	myname.mydyndnsprovider.com.	; note the dot!

Laden Sie dann Ihr Nameserver-Programm neu oder starten Sie es neu. Nun werden alle DNS-Abfragen für Domains, die auf t1.mydomain.com enden, an Ihren iodined-Server gesendet.

Starten Sie schließlich iodined auf Ihrem Server. Das erste Argument ist die IP-Adresse innerhalb des Tunnels, die aus einem beliebigen Bereich stammen kann, den Sie noch nicht verwenden (z. B. 192.168.99.1), und das zweite Argument ist die zugewiesene Domain (in diesem Fall t1.mydomain.com). Mit der Option -f läuft iodined im Vordergrund, was beim Testen hilfreich ist. iodined öffnet eine virtuelle Schnittstelle („tun device") und beginnt außerdem, auf UDP-Port 53 auf DNS-Abfragen zu lauschen. Geben Sie ein Passwort entweder in der Befehlszeile ein (-P pass) oder nachdem der Server gestartet wurde. Nun ist alles für den Client bereit.

Wenn die Möglichkeit besteht, dass Sie einen iodine-Tunnel aus unerwarteten Umgebungen heraus verwenden, starten Sie iodined mit der Option -c. Die resultierende Befehlszeile in dieser Beispielsituation:

./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com

Clientseite

Die gesamte Einrichtung ist abgeschlossen; starten Sie einfach iodine. Es akzeptiert ein oder zwei Argumente: Das erste ist der lokale weiterleitende DNS-Server (optional) und das zweite ist die von Ihnen verwendete Domain (t1.mydomain.com). Wenn Sie das erste Argument nicht angeben, wird die aktuelle DNS-Einstellung des Systems herangezogen.

Wenn DNS-Abfragen an beliebige Computer erlaubt sind, können Sie die Adresse des iodined-Servers direkt als erstes Argument angeben (im Beispiel: t1ns.mydomain.com oder 10.15.213.99). In diesem Fall kann es auch vorkommen, dass jeglicher Datenverkehr zum DNS-Port (53 UDP) eines beliebigen Computers erlaubt ist. Iodine erkennt dies und wechselt, wenn möglich, zum Raw-UDP-Tunneling. Um DNS-Tunneling in jedem Fall zu erzwingen, verwenden Sie die Option -r (besonders nützlich beim Testen in Ihrem eigenen Netzwerk).

Die Tunnel-Schnittstelle des Clients erhält eine IP in der Nähe der des Servers (in diesem Fall 192.168.99.2 oder .3 usw.) und eine geeignete MTU. Geben Sie dasselbe Passwort wie auf dem Server ein, entweder als Befehlszeilenoption oder nachdem der Client gestartet wurde. Mit der Option -f läuft der iodine-Client im Vordergrund.

Die resultierende Befehlszeile in dieser Beispielsituation; das Hinzufügen von -r erzwingt DNS-Tunneling, selbst wenn Raw-UDP-Tunneling möglich wäre:

./iodine -f -P secretpassword t1.mydomain.com

Von beiden Seiten aus sollten Sie nun in der Lage sein, die IP-Adresse am anderen Ende des Tunnels anzupingen. In diesem Fall ping 192.168.99.1 vom iodine-Client und 192.168.99.2 vom iodine-Server.

SONSTIGE INFORMATIONEN

IPv6

Die Daten im Tunnel sind ausschließlich IPv4.

Der Server lauscht standardmäßig sowohl auf IPv4 als auch auf IPv6 für eingehende Anfragen. Verwenden Sie die Optionen -4 oder -6, um nur auf einem Protokoll zu lauschen. Der Raw-Modus wird auf demselben Protokoll versucht, das auch für den Login verwendet wurde.

Der Client kann IPv4- oder IPv6-Nameserver verwenden, um sich mit iodined zu verbinden. Die Relay-Nameserver übersetzen bei Bedarf automatisch zwischen den Protokollen. Verwenden Sie die Optionen -4 oder -6, um den Client zu zwingen, für seine DNS-Abfragen eine bestimmte IP-Version zu verwenden.

Wenn Ihr Server auf IPv6 lauscht und erreichbar ist, fügen Sie einen AAAA-Eintrag für ihn zu Ihrer DNS-Konfiguration hinzu. Die Erweiterung des obigen Beispiels würde so aussehen:

t1		IN	NS	t1ns.mydomain.com.		; note the dot!
t1ns		IN	A	10.15.213.99
t1ns		IN	AAAA	2001:db8::1001:99

Routing

Es ist möglich, den gesamten Datenverkehr durch den DNS-Tunnel zu leiten. Fügen Sie dazu zunächst eine Host-Route zu dem von iodine verwendeten Nameserver über die kabelgebundene/drahtlose Schnittstelle mit dem Standard-Gateway als Gateway hinzu. Ersetzen Sie dann das Standard-Gateway durch die IP-Adresse des iodined-Servers innerhalb des DNS-Tunnels und konfigurieren Sie den Server so, dass er NAT durchführt.

Beachten Sie jedoch, dass der getunnelte Datenverkehr überhaupt nicht verschlüsselt ist und von externen Parteien relativ einfach gelesen und verändert werden kann. Für maximale Sicherheit betreiben Sie ein VPN durch den DNS-Tunnel (= Doppeltunneling) oder nutzen Sie Secure-Shell-Zugriff (SSH), möglicherweise mit Portweiterleitung. Letzteres kann auch zum Surfen im Web verwendet werden, wenn Sie einen Web-Proxy (z. B. Privoxy) auf Ihrem Server betreiben.

Testen

Der iodined-Server antwortet auf NS-Anfragen, die für Subdomains der Tunnel-Domain gesendet werden. Wenn Ihre iodined-Subdomain t1.mydomain.com ist, senden Sie eine NS-Anfrage für foo123.t1.mydomain.com, um zu prüfen, ob die Delegierung funktioniert. dig ist ein gutes Werkzeug dafür:

% dig -t NS foo123.t1.mydomain.com
ns.io.citronna.de.

Außerdem beantwortet der iodined-Server Anfragen, die mit 'z' beginnen, für jeden der unterstützten Anfragetypen, zum Beispiel:

dig -t TXT z456.t1.mydomain.com
dig -t SRV z456.t1.mydomain.com
dig -t CNAME z456.t1.mydomain.com

Die Antwort sollte in all diesen Fällen wie verstümmelter Text aussehen.

Mac OS X

Unter Mac OS X 10.6 und neuer unterstützt iodine die nativen utun-Geräte des Betriebssystems - verwenden Sie -d utunX.

Betriebsinformationen

Die Fragmentgröße der DNS-Antwort wird normalerweise automatisch ermittelt, um die maximale Bandbreite zu erreichen. Um einen bestimmten Wert zu erzwingen (und die Dinge zu beschleunigen), verwenden Sie die Option -m.

Die DNS-Hostnamen werden normalerweise bis zu ihrer maximalen Länge von 255 Zeichen genutzt. Es wurde festgestellt, dass einige DNS-Relays Abfragen in voller Länge ziemlich unzuverlässig beantworten und bei wiederholten Versuchen stark schwankende (und meist sehr schlechte) Ergebnisse der automatischen Fragmentgrößenermittlung liefern. Verwenden Sie in diesen Fällen den Schalter -M, um die Länge des DNS-Hostnamens beispielsweise auf 200 Zeichen zu reduzieren, wodurch diese DNS-Relays wesentlich stabiler werden. Dies ist auch bei einigen „de-optimierenden" DNS-Relays nützlich, die die Antwort mit zwei vollständigen Kopien der Abfrage vollstopfen und so nur sehr wenig Platz für Downstream-Daten lassen (außerdem nicht EDNS0-fähig). Mit dem Schalter -M kann etwas Upstream-Bandbreite gegen Downstream-Bandbreite getauscht werden. Beachten Sie, dass der Mindestwert für -M etwa 100 beträgt, da das Protokoll Pakete (max. 1200 Bytes) nur in 16 Fragmente aufteilen kann, was mindestens 75 echte Datenbytes pro Fragment erfordert.

Die Upstream-Daten werden gzipped und mit Base32 kodiert gesendet; oder mit Base64, wenn der Relay-Server gemischte Groß-/Kleinschreibung und + in Domainnamen unterstützt; oder mit Base64u, wenn stattdessen _ unterstützt wird; oder mit Base128, wenn Zeichen mit hohem Bytewert unterstützt werden. Diese Upstream-Kodierung wird automatisch erkannt. Das DNS-Protokoll erlaubt eine Abfrage pro Paket, und eine Abfrage kann maximal 256 Zeichen lang sein. Jeder Domainnamen-Teil kann maximal 63 Zeichen lang sein. Ihr Domainname und Ihre Subdomain sollten daher so kurz wie möglich sein, um einen maximalen Upstream-Durchsatz zu ermöglichen.

Mehrere DNS-Anfragetypen werden unterstützt, wobei die Typen NULL und PRIVATE voraussichtlich die größte Downstream-Bandbreite bieten. Der Typ PRIVATE verwendet den Wert 65399 im Bereich für private Nutzung. Weitere verfügbare Typen sind TXT, SRV, MX, CNAME und A (mit CNAME als Antwort), in absteigender Bandbreitenreihenfolge. Normalerweise wird der „beste" Anfragetyp automatisch erkannt und verwendet. DNS-Relays können jedoch beispielsweise bei NULL und TXT Einschränkungen auferlegen, wodurch SRV oder MX tatsächlich die beste Wahl sind. Dies wird nicht automatisch erkannt, kann aber mit der Option -T erzwungen werden. Es ist ratsam, verschiedene Alternativen auszuprobieren, insbesondere wenn der automatisch erkannte Anfragetyp eine Downstream-Fragmentgröße von weniger als 200 Bytes liefert.

Beachten Sie, dass SRV-, MX- und A-Abfragen (mit CNAME als Antwort) durch „intelligente" Caching-Nameserver zusätzliche Lookups verursachen können/werden, um eine tatsächliche IP-Adresse zu erhalten, was entweder zu Verlangsamung oder zu vollständigem Scheitern führen kann.

DNS-Antworten für Nicht-NULL/PRIVATE-Abfragen können mit demselben Satz von Codecs wie die Upstream-Daten kodiert werden. Dies wird normalerweise ebenfalls automatisch erkannt, aber es werden keine vollständig erschöpfenden Tests durchgeführt, sodass bei der Auswahl fortgeschrittenerer Codecs einige Probleme möglicherweise unbemerkt bleiben. In diesem Fall sehen Sie Fehler/Beschädigungen bei der automatischen Fragmentgrößenermittlung. Insbesondere wurde festgestellt, dass einige DNS-Relays Antworten, die Hostnamen zurückgeben (SRV, MX, CNAME, A), nur dann in Kleinbuchstaben umwandeln, wenn dieser Hostname ca. 180 Zeichen überschreitet. Verwenden Sie in diesen und ähnlichen Fällen die Option -O, um andere Downstream-Codecs auszuprobieren; Base32 sollte immer funktionieren.

Der normale Betrieb besteht nun darin, dass der Server eine DNS-Anfrage nicht beantwortet, bis die nächste DNS-Anfrage eingetroffen ist, auch bekannt als „lazy". Auf diese Weise hat der Server immer eine DNS-Anfrage zur Hand, wenn neue Downstream-Daten gesendet werden müssen. Dies verbessert die (interaktive) Leistung und Latenz erheblich und ermöglicht es, die Ruhe-Ping-Anfragen standardmäßig auf 4-Sekunden-Intervalle zu verlangsamen, möglicherweise sogar erheblich langsamer. Tatsächlich besteht der Hauptzweck der Pings nun darin, eine Antwort auf den vorherigen Ping zu erzwingen und DNS-Server-Timeouts (normalerweise mindestens 5-10 Sekunden gemäß RFC1035) zu verhindern. Einige DNS-Server sind ungeduldiger und liefern in Zeiten ohne getunnelten Datenverkehr SERVFAIL-Fehler (Timeouts). In diesen Fällen sollten alle Daten trotzdem durchkommen, aber iodine reduziert das Ping-Intervall dennoch auf 1 Sekunde (-I1), um die Anzahl der Fehlermeldungen zu verringern. Dies mag bei sehr ungeduldigen DNS-Relays wie dnsadvantage.com (ultradns), die in 1 Sekunde oder sogar weniger aussteigen, nicht helfen. Die Daten kommen jedoch trotzdem durch, und Sie können die SERVFAIL-Fehler ignorieren.

Wenn Sie in einem lokalen Netzwerk ohne zwischengeschalteten DNS-Server arbeiten, versuchen Sie -I 50 (iodine und iodined schließen die Verbindung nach 60 Sekunden Stille). Die einzige Gelegenheit, bei der Sie eine Verlangsamung bemerken, ist, wenn DNS-Antwortpakete verloren gehen; der iodined-Server muss dann auf einen neuen Ping warten, um die Daten erneut zu senden. Sie können dies beschleunigen, indem Sie etwas Upstream-Datenverkehr erzeugen (Tastendruck, Ping). Wenn dies häufig vorkommt, prüfen Sie Ihr Netzwerk auf Engpässe und/oder führen Sie es mit -I1 aus.

Die verzögerte Beantwortung im Lazy-Modus führt dazu, dass einige kommerzielle DNS-Relays der „Carrier-Grade"-Klasse dieselbe DNS-Abfrage wiederholt an den iodined-Server senden. Wenn das DNS-Relay tatsächlich als Pool paralleler Server implementiert ist, können doppelte Anfragen sogar von mehreren Quellen eintreffen. Dieser Effekt ist nur im Netzwerkverkehr am iodined-Server sichtbar und beeinträchtigt die Verbindung des Clients nicht. Iodined erkennt diese Duplikate und sendet dieselbe Antwort (wenn ihre Zeit gekommen ist) sowohl an die ursprüngliche Abfrage als auch an das neueste Duplikat. Danach wird die vollständige Antwort für kurze Zeit zwischengespeichert. Verspätete Duplikate, die noch später am Server eintreffen, erhalten eine Antwort, die der iodine-Client ignoriert (falls sie dort jemals ankommt).

Wenn Sie Probleme haben, versuchen Sie, den Datenverkehr mit Netzwerküberwachungswerkzeugen wie tcpdump oder ethereal/wireshark zu untersuchen, und stellen Sie sicher, dass der weiterleitende DNS-Server die Antwort nicht zwischengespeichert hat. Eine zwischengespeicherte Fehlermeldung könnte bedeuten, dass Sie den Client vor dem Server gestartet haben. Die Option -D (und -DD) auf dem Server kann ebenfalls empfangene und gesendete Abfragen anzeigen.

TIPPS & TRICKS

Wenn Ihr Port 53 auf einer bestimmten Schnittstelle von einer Anwendung belegt ist, die ihn nicht nutzt, verwenden Sie bei iodined -p, um einen alternativen Port anzugeben (wie -p 5353), und verwenden Sie beispielsweise iptables (unter Linux), um den Datenverkehr weiterzuleiten:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353

(Eingesendet von Tom Schouten)

Iodined verwirft Daten von Clients, die länger als 60 Sekunden keine Aktivität gezeigt haben (Daten/Pings). Ebenso beendet sich iodine, wenn 60 Sekunden lang keine Downstream-Daten empfangen wurden. Bei einem längeren Netzwerkausfall oder Ähnlichem starten Sie iodine einfach neu (erneuter Login), möglicherweise mehrmals, bis Sie Ihre alte IP-Adresse zurückerhalten. Wenn das erledigt ist, warten Sie einfach eine Weile, und Sie werden schließlich sehen, dass der getunnelte TCP-Datenverkehr dort weiterfließt, wo er vor dem Ausfall aufgehört hat.

Mit der Einführung der Downstream-Paketwarteschlange im Server ist dessen Speicherverbrauch in der Standardkonfiguration um mehrere Megabyte gestiegen. Für den Einsatz in Umgebungen mit wenig Speicher (z. B. auf Ihrem DSL-Router) können Sie USERS verringern und OUTPACKETQ_LEN in user.h undefinieren, ohne negative Folgen, vorausgesetzt, dass zu jedem Zeitpunkt höchstens ein Client verbunden ist. Ein kleiner DNSCACHE_LEN wird weiterhin empfohlen, vorzugsweise 2 oder höher; Sie können ihn jedoch auch undefinieren, um ein paar weitere Kilobyte zu sparen.

Ein iodine-Server kann mehrere Domains verwalten. Richten Sie verschiedene NS-Einträge auf derselben Domain ein, die alle auf denselben Host zeigen, und verwenden Sie einen Platzhalter (Wildcard) am Anfang des Topdomain-Arguments (Beispiel *.mydomain.com). iodine akzeptiert Tunnel-Datenverkehr für alle Domains, die diesem Muster entsprechen. Der Platzhalter muss am Anfang des Topdomain-Arguments stehen und von einem Punkt gefolgt sein.

LEISTUNG

Dieser Abschnitt enthält einige Leistungsmessungen in Tabellenform. Verwenden Sie zur korrekten Darstellung eine Schrift mit fester Breite wie Courier.

Die Messungen wurden mit Protokoll 00000502 im Lazy-Modus durchgeführt; Upstream-Kodierung immer Base128; iodine -M255; iodined -m1130. Die Netzwerkbedingungen waren nicht extrem günstig; die Ergebnisse sind keine Benchmarks, sondern eine realistische Angabe der Praxisleistung, die in ähnlichen Situationen zu erwarten ist.

Der Upstream-/Downstream-Durchsatz wurde gemessen, indem eine zuvor aus /dev/urandom gelesene Datei (d. h. inkompressibel) per scp übertragen und die Größe mit ls -l ; sleep 30 ; ls -l über eine separate, nicht getunnelte Verbindung gemessen wurde. Angesichts der großen scp-Blockgröße von 16 kB ergibt dies eine Auflösung von 4,3 kbit/s, was erklärt, warum einige Werte exakt gleich sind.

Die Ping-Umlaufzeiten wurden mit ping -c100 gemessen; angegeben sind die durchschnittliche Umlaufzeit (rtt) und die mittlere Abweichung (die die Streuung um den Durchschnitt angibt), in Millisekunden.

Situation 1: `Laptop -> Wifi AP -> Home server -> DSL provider -> Datacenter`

 iodine    DNS "relay"        bind9           DNS cache        iodined

                        downstr.  upstream downstr.  ping-up       ping-down
                        fragsize   kbit/s   kbit/s  avg +/-mdev   avg +/-mdev
-----------------------------------------------------------------------------

iodine -> Wifi AP :53
  -Tnull (= -Oraw)           982    43.6    131.0   28.0    4.6   26.8    3.4

iodine -> Home server :53
  -Tnull (= -Oraw)          1174    48.0    305.8   26.6    5.0   26.9    8.4

iodine -> DSL provider :53
  -Tnull (= -Oraw)          1174    56.7    367.0   20.6    3.1   21.2    4.4
  -Ttxt -Obase32             730    56.7    174.7*
  -Ttxt -Obase64             874    56.7    174.7
  -Ttxt -Obase128           1018    56.7    174.7
  -Ttxt -Oraw               1162    56.7    358.2
  -Tsrv -Obase128            910    56.7    174.7
  -Tcname -Obase32           151    56.7     43.6
  -Tcname -Obase128          212    56.7     52.4

iodine -> DSL provider :53
  wired (no Wifi) -Tnull    1174    74.2    585.4   20.2    5.6   19.6    3.4

 [174.7* : these all have 2frag/packet]

Situation 2: `Laptop -> Wifi+vpn / wired -> Home server`

 iodine                            iodined

                        downstr.  upstream downstr.  ping-up       ping-down
                        fragsize   kbit/s   kbit/s  avg +/-mdev   avg +/-mdev
-----------------------------------------------------------------------------

wifi + openvpn  -Tnull      1186   166.0   1022.3    6.3    1.3    6.6    1.6

wired  -Tnull               1186   677.2   2464.1    1.3    0.2    1.3    0.1

Anmerkungen

Die Leistung hängt stark mit niedrigen Ping-Zeiten zusammen, da iodine für jedes Datenfragment eine Bestätigung benötigt, bevor es zum nächsten übergeht. Das Zulassen mehrerer gleichzeitig in Bearbeitung befindlicher Fragmente wie bei TCP könnte die Leistung möglicherweise erhöhen, würde aber wahrscheinlich eine ernsthafte Überlastung der zwischengeschalteten DNS-Server verursachen. Das aktuelle Protokoll skaliert die Leistung mit der DNS-Reaktionsfähigkeit, da die DNS-Server im Durchschnitt höchstens eine DNS-Anfrage pro Client bearbeiten.

PORTIERBARKEIT

iodine wurde auf Linux (arm, ia64, x86, AMD64 und SPARC64), FreeBSD (ia64, x86), OpenBSD (x86), NetBSD (x86), MacOS X (ppc und x86, mit http://tuntaposx.sourceforge.net/) und Windows (mit OpenVPN-TAP32-Treiber, siehe win32-Readme-Datei) getestet. Es sollte einfach auf andere unix-ähnliche Systeme mit TUN/TAP-Tunnelunterstützung zu portieren sein. Lassen Sie uns wissen, wenn Sie es auf anderen Plattformen zum Laufen bringen.

DER NAME

Der Name iodine wurde gewählt, weil er mit IOD beginnt (IP Over DNS) und weil das Element Iod die Ordnungszahl 53 hat, was zufälligerweise die DNS-Portnummer ist.

DANKSAGUNGEN

An kuxien für das Testen unter FreeBSD und OS X
An poplix für das Code-Audit

AUTOREN & LIZENZ

Die Erlaubnis, diese Software für jeden Zweck mit oder ohne Gebühr zu verwenden, zu kopieren, zu modifizieren und/oder zu verbreiten, wird hiermit erteilt, vorausgesetzt, dass der obige Urheberrechtshinweis und dieser Erlaubnishinweis in allen Kopien enthalten sind.

DIE SOFTWARE WIRD „WIE BESEHEN" BEREITGESTELLT, UND DER AUTOR LEHNT ALLE GEWÄHRLEISTUNGEN IN BEZUG AUF DIESE SOFTWARE AB, EINSCHLIESSLICH ALLER IMPLIZIERTEN GEWÄHRLEISTUNGEN DER MARKTGÄNGIGKEIT UND EIGNUNG. IN KEINEM FALL IST DER AUTOR HAFTBAR FÜR BESONDERE, DIREKTE, INDIREKTE ODER FOLGESCHÄDEN ODER FÜR IRGENDWELCHE SCHÄDEN, DIE AUS NUTZUNGSAUSFALL, DATENVERLUST ODER GEWINNVERLUST ENTSTEHEN, UNABHÄNGIG DAVON, OB SIE IN EINEM VERTRAG, DURCH FAHRLÄSSIGKEIT ODER EINE ANDERE UNERLAUBTE HANDLUNG BEGRÜNDET SIND, DIE AUS ODER IM ZUSAMMENHANG MIT DER NUTZUNG ODER LEISTUNG DIESER SOFTWARE ENTSTEHT.

iodine

Beliebteste