DIG - guía básica

Hace un tiempo expliqué algunos usos básicos de dig como herramienta de visualización y comprobación de entradas DNS.

Hoy voy a dejar aquí una pequeña guía o chuleta básica de dig, opciones y salidas que vamos a poder obtener para comprobar si un servidor DNS está correctamente configurado o incluso para averiguar información interesante sobre dominios.

Por defecto, y siempre que sea posible voy a emplear la opción "+short" ya que así la salida es mucho más simple y legible.

También, dig incluye la posibilidad de preguntar directamente a un servidor DNS concreto. Para ello empleamos el "@DNS-Server".

1. Información básica

   shell> dig google.com +short
   74.125.24.101
   74.125.24.102
   74.125.24.113
   74.125.24.138
   74.125.24.139
   74.125.24.100
   

2. Registros DNS

   shell> dig @8.8.8.8 google.com A +short
   173.194.116.101
   173.194.116.105
   173.194.116.99
   173.194.116.97
   173.194.116.100
   173.194.116.103
   173.194.116.102
   173.194.116.98
   173.194.116.96
   173.194.116.110
   173.194.116.104
   

1. Registros NS
   
   Hace referencia a los servidores DNS que emplear el dominio consultado.

   shell> dig @8.8.8.8 google.com NS +short
   ns1.google.com.
   ns2.google.com.
   ns3.google.com.
   ns4.google.com.
   

2. Registros MX
   
   Hace referencia a los nombre de los servidores de correo que existen en el dominio consultado.

   shell> dig @8.8.8.8 google.com MX +short
   40 alt3.aspmx.l.google.com.
   30 alt2.aspmx.l.google.com.
   10 aspmx.l.google.com.
   50 alt4.aspmx.l.google.com.
   20 alt1.aspmx.l.google.com.
   

3. Registros TXT

   shell> dig @8.8.8.8 google.com TXT +short
   "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ..."



3. Consulta inversa
   
   Sirve para saber el nombre que al que resuelve una IP concreta y por lo tanto poder buscar un dominio únicamente teniendo como información una IP.

   shell> dig -x 173.194.116.96
   ...
   ;; AUTHORITY SECTION:
   116.194.173.in-addr.arpa. 60  IN  SOA  ns1.google.com. ...
   ...

Leer más

Peticiones DNS cifradas

Cada vez más se empieza a escuchar que los proveedores de Internet o ISP's están controlando y restringiendo el tráfico que generamos. Una de las formas más sencillas y también más simples de saltar es el control del DNS. Un nombre DNS no es más que una forma fácil de acordarse de una IP, que es la que realmente sirve el contenido. Si bien todos nos tuviéramos que acordar de la IP 173.194.66.94 cada vez que accediésemos a Google fijo que éste tendría muchas menos visitas. Esto es lo que hace el DNS, simplificar.

Pues bien, de la misma forma que simplifica, también es fácil obtener las cadenas a las que deseas acceder y evitar que las visites. Por ejemplo, cada vez que vayas a Google, mandarte a Yahoo! o a una web que indique que el contenido está prohibido. Esto con un ataque MITM (Ataque Man-in-the-middle) es fácil de realizar y los ISP's realmente están a ese nivel con nosotros.
Por suerte existe un proyecto que ofrece una versión libre de DNS's, OpenDNS. Éste nos ofrece las mismas garantías que el resto de servidores DNS que están disponibles por la red, pero tiene a mayores la peculiaridad de que acepta tráfico DNS encriptado y por supuesto lo devuelve encriptado. Por lo tanto, la idea sería tener una implementación https bajo el protocolo DNS.

Visitando la web de OpenDNS se nos linka a un proyecto, DNSCrypt, que hace exactamente lo que hemos comentado anteriormente. Cifra nuestro tráfico entre origen y destino evitando las molestas escuchas, convirtiendo nuestro equipo local en nuestro proveedor de DNS, que lanza posteriormente las consultas fuera. Vamos a ver cómo instalarlo y usarlo.

1. Descargamos el código desde github
2. Extraemos y compilamos el código

   shell> tar xxvf dnscrypt-proxy-1.2.0.tar.gz
   shell> cd dnscrypt-proxy-1.2.0
   shell> ./configure
   shell> make
   shell> make install
   

3. Arrancamos el servicio

   shell> dnscrypt-proxy --daemonize
   

4. Cambiamos el servidor DNS del equipo
   
   Por defecto en los equipos Linux tendremos que editar el fichero /etc/resolv.conf y dejarlo con el siguiente contenido.

   nameserver 127.0.0.1
   

5. Comprobamos

   shell> dig www.google.es
   

Aunque las preguntas las estemos a realizar a nuestro DNS local, realmente las está respondiendo OpenDNS y toda la comunicación irá cifrada, creando así una comunicación DNS segura.

La entrada Peticiones DNS cifradas la puedes leer en Puppet Linux.

Leer más

Detección de balanceadores de carga

Muchas veces a la hora de consultar una página web nos puede interesa saber si tiene o no un balanceador de carga detrás de ella, es decir, si lo que parece una única página web en realidad tiene detrás un número N de servidores. A continuación vamos a ver las formas que hay de averiguar si detrás de un servicio hay uno o varios equipos respondiendo.

• Consulta DNS
  
  Podemos averiguar si un servicio está balanceado mediante DNS si al realizar la pregunta al servidor, éste nos devuelve varias entradas.

  shell> dig www.google.com A
  ...
  ;; ANSWER SECTION:
  www.google.com.  511041 IN CNAME www.l.google.com.
  www.l.google.com. 205 IN A 173.194.66.106
  www.l.google.com. 205 IN A 173.194.66.147
  www.l.google.com. 205 IN A 173.194.66.99
  www.l.google.com. 205 IN A 173.194.66.103
  www.l.google.com. 205 IN A 173.194.66.104
  www.l.google.com. 205 IN A 173.194.66.105
  ...
  

• Load Balancing Detector
  
  lbd es un pequeño script escrito en bash por Stefan Behte (http://ge.mine.nu) que permite evaluar con una sola llamada varias técnicas para descubrir si un dominio está en load balancing o no. Tras descargarlo y dar permisos de ejecución, únicamente hay que pasarle como parámetro el dominio a evaluar.

  shell> ./lbd google.com
  
  lbd - load balancing detector 0.2 -
        Checks if a given domain uses load-balancing.
        Written by Stefan Behte (http://ge.mine.nu)
        Proof-of-concept! Might give false positives.
  
  Checking for DNS-Loadbalancing: FOUND
  google.com has address 74.125.230.230
  google.com has address 74.125.230.231
  google.com has address 74.125.230.232
  google.com has address 74.125.230.233
  google.com has address 74.125.230.238
  google.com has address 74.125.230.224
  google.com has address 74.125.230.225
  google.com has address 74.125.230.226
  google.com has address 74.125.230.227
  google.com has address 74.125.230.228
  google.com has address 74.125.230.229
  
  Checking for HTTP-Loadbalancing [Server]: 
   gws
   NOT FOUND
  
  Checking for HTTP-Loadbalancing [Date]: 10:56:58, 10:56:58, 10:56:58, 10:56:58, 10:56:58, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:57:00, 10:57:00, 10:57:00, 10:57:00, 10:57:00, 10:57:00, 10:57:00, 10:57:00, 10:57:01, 10:57:01, 10:57:01, 10:57:01, 10:57:01, 10:57:01, 10:57:01, 10:57:01, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:03, 10:57:03, 10:57:03, 10:57:03, 10:57:03, 10:57:03, 10:57:03, 10:57:03, 10:57:04, 10:57:04, 10:57:04, NOT FOUND
  
  Checking for HTTP-Loadbalancing [Diff]: NOT FOUND
  
  google.com does Load-balancing. Found via Methods: DNS
  

• hping3
  
  Con esta pequeña utilidad podemos crear paquetes ping "made a tu gusto" y que nos permite obtener valores al intentar establecer una conexión con un equipo. Si el equipo no está balanceado, generalmente los id's son incrementales o cero, pero al estar detrás de un balanceador vemos que no tienen un orden lógico.

  shell> hping3 -S -p 80 www.google.com
  HPING www.google.com (eth2 173.194.66.103): S set, 40 headers + 0...
  len=46 ip=173.194.66.103 ttl=46 id=26225 sport=80 flags=SA seq=0...
  len=46 ip=173.194.66.103 ttl=46 id=13025 sport=80 flags=SA seq=1...
  len=46 ip=173.194.66.103 ttl=46 id=55771 sport=80 flags=SA seq=2...
  len=46 ip=173.194.66.103 ttl=46 id=53021 sport=80 flags=SA seq=3...
  len=46 ip=173.194.66.103 ttl=46 id=46727 sport=80 flags=SA seq=4...
  len=46 ip=173.194.66.103 ttl=46 id=11782 sport=80 flags=SA seq=5...
  

  Mientras que a un dominio sin balanceo,

  shell> hping3 -S -p 80 www.domain.com
  HPING www.domain.es (eth2 213.60.X.Y): S set, 40 headers + 0...
  len=46 ip=213.60.X.Y ttl=63 DF id=0 sport=80 flags=SA seq=0...
  len=46 ip=213.60.X.Y ttl=63 DF id=0 sport=80 flags=SA seq=1...
  len=46 ip=213.60.X.Y ttl=63 DF id=0 sport=80 flags=SA seq=2...
  len=46 ip=213.60.X.Y ttl=63 DF id=0 sport=80 flags=SA seq=3...
  len=46 ip=213.60.X.Y ttl=63 DF id=0 sport=80 flags=SA seq=4...
  

Leer más

Obtener un listado de subdominios

En muchas ocasiones es necesario saber qué subdominios tiene una empresa públicos en Internet para garantizar que los que tiene son los que efectivamente debería de tener. Una buena forma de averiguarlo está en el programa dnsmap, que es un pequeño código escrito en C (795 líneas nada más) y que permiten escanear un dominio en busca de todos los subdominios que éste tiene, sacando un informe final. Saber las máquinas que hay disponibles en una red es muy importante, al igual que saber las personas o correos de esa organización. Para comenzar, vamos a ver cómo trabajar con dnsmap. Comenzamos bajándolo de la web oficial. Una vez lo tenemos, simplemente lo descomprimimos y compilamos para poder usarlo.

shell> tar zxvf dnsmap-0.30.tar.gz
shell> cd dnsmap-0.30
shell> gcc -Wall dnsmap.c -o dnsmap
shell> ./dnsmap
dnsmap 0.30 - DNS Network Mapper by pagvac (gnucitizen.org)

usage: dnsmap  [options]
options:
-w 
-r 
-c 
-d 
-i  (useful if you're obtaining false positives)

e.g.:
dnsmap target-domain.foo
dnsmap target-domain.foo -w yourwordlist.txt -r /tmp/domainbf_results.txt
dnsmap target-fomain.foo -r /tmp/ -d 3000
dnsmap target-fomain.foo -r ./domainbf_results.txt

dnsmap trae por defecto un listado de palabras que empleará como subdominios a buscar y que están listadas en el fichero dnsmap.h, sin embargo también permite pasarle como argumento un listado de palabras que serán usadas. Finalmente, nos puede sacar un listado en fichero de texto o por pantalla. La forma de usarlo,

shell> ./dnsmap company.com 
dnsmap 0.30 - DNS Network Mapper by pagvac (gnucitizen.org)

[+] searching (sub)domains for company.com using built-in wordlist
[+] using maximum random delay of 10 millisecond(s) between requests

beta.company.com
IP address #1: 91.X.X.X

downloads.company.com
IP address #1: 91.X.X.X

files.company.com
IP address #1: 92.X.X.X

jabber.company.com
IP address #1: 91.X.X.X

mail.company.com
IP address #1: 165.X.X.X

ns.company.com
IP address #1: 92.X.X.X

public.company.com
IP address #1: 51.X.X.X

rt.company.com
IP address #1: 91.X.X.X

www.company.com
IP address #1: 91.X.X.X

[+] 9 (sub)domains and 9 IP address(es) found
[+] completion time: 89 second(s)

En caso de que las palabras por defecto no den un buen resultado, se puede pasar un listado de palabras (el que trae o un propio) para descubrir todos aquellos subdominios que puedan interesar.

Leer más

pdnsd, proxy caché DNS

Hace tiempo ya hablamos de dnsmasq, un pequeño servicio de caché de DNS que resuelve y almacena localmente las peticiones para poder responder más rápidamente a páginas a las que se ha accedido con anterioridad.

La ventaja del mundo del software libre es justamente esa, poder crear proyectos y darse a conocer por que sí. Tal es el caso que hoy hablamos de una aplicación que hace prácticamente lo mismo, servir de proxy local para DNS, acelerando las consultas. Dicha aplicación es pdnsd, un pequeño proxy que se ejecuta como daemon del sistema y que crea un servicio de respuesta DNS, que mantiene en caché la relación nombre <-> IP para así poder ofrecer mayor rapidez. Vamos a ver cómo funciona, de forma simple. Comenzamos instalándolo,

shell> apt-get install pdnsd

Tras la instalación, hay que configurar el servicio. Para ello, editamos el fichero /etc/pdnsd.conf y en la sección server, lo dejamos tal que así,

server {
   label="DNS Google";
   ip=8.8.8.8;
   ip=8.8.4.4;
   timeout=30;
   uptest=ping;
   interval=30;
   ping_timeout=300;
   proxy_only=on;
   purge_cache=off;
   caching=on;
   preset=off;
}

Y también editamos el fichero /etc/default/pdnsd.

# do we start pdnsd ?
START_DAEMON=yes
# auto-mode, overrides /etc/pdsnd.conf if set [see /usr/share/pdnsd/]
AUTO_MODE=
# optional CLI options to pass to pdnsd(8)
START_OPTIONS=

Tras esto, ya es posible arrancar pdnsd como daemon.

shell> /etc/init.d/pdnsd restart

Una vez reiniciado el servicio, ya tenemos un servidor DNS local, con caché, por lo que tenemos que cambiar la IP de resolución de nombres de los servidores que empleemos a localhost. Para ello, editamos el fichero /etc/resolv.conf y lo dejamos,

nameserver 127.0.0.1

Y si realizamos la misma prueba que hicimos con dnsmasq vemos que los resultados son muy similares.

shell> dig www.marca.com
...
;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 14 13:33:07 2012
;; MSG SIZE  rcvd: 275
shell> dig www.marca.com
...
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 14 13:33:14 2012
;; MSG SIZE  rcvd: 47

Leer más

Acelerando las consultas DNS

El método de funcionamiento de la red en equipos Linux, al igual que en Windows, es que cada vez que tú pides un nombre, éste se consulta al DNS primario para obtener una IP y luego establecer la conexión. Si sueles navegar por las mismas páginas, cada vez que las vuelves a cargar, hay que realizar una nueva conexión al DNS para obtener un dato que ya lo teníamos hace nada. Para evitar esto, vamos a explicar cómo hacer uso de una caché DNS que acelere dichas consultas, dejándolas en local la mayor parte de las veces.

Para ello, primero instalaremos el software necesario, dnsmasq.

shell> apt-get install dnsmasq

A continuación configuramos de forma muy simple de demonio para que permita almacenar en caché los valores. Para ello editamos el fichero /etc/dnsmasq.conf y agregamos al final las siguientes líneas,

expand-hosts
domain=tudominio.com
cache-size=150
bogus-priv

A continuación, agregamos como DNS primario de nuestro equipo que la IP local, para que todas las consultas se resuelvan localmente. Para ello, editamos el fichero /etc/resolv.conf y agregamos al principio de todo,

nameserver 127.0.0.1

Ahora todas las consultas pasarán por el DNS primario de nuestro equipo y será dnsmasq el encargado de realizar las peticiones. La idea es que la primera vez ésta se lancen a donde corresponda, pero las siguiente ya no, por lo que se acelerarán dichas consultas. Lo vamos a comprobar.

shell> dig www.marca.com 
...
;; Query time: 9 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 14 13:33:07 2012
;; MSG SIZE  rcvd: 275

Como se puede observar el servidor de consulta es localhost y al realizar la petición, como era la primera vez, tardó 9 msec. Ahora lo volvemos a intentar y vemos lo que pasa.

shell> dig www.marca.com
...
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 14 13:33:14 2012
;; MSG SIZE  rcvd: 47

El servidor de consulta sigue siendo localhost, pero el tiempo de respuesta ahora es de 0 msec. Como el dominio está en caché, será únicamente la primera vez cuando tarde en realizar la consulta, a partir de ese momento el tiempo de respuesta será cero.

Leer más

Reverse lookup

En ocasiones igual de importante saber la IP a la que responde un nombre, también es importante saber a qué nombre corresponde una determinada IP. Para ello se usa el reverse lookup y dig nos lo permite hacer empleando la opción -x.

Partiendo de una IP, por ejemplo, 74.125.230.216, nos interesa saber a qué nombre de dominio resuelve. Para ello, usando dig, realizamos lo siguiente.

shell> dig -x 74.125.230.216 +short
par08s09-in-f24.1e100.net.

En este caso, la IP solicitada devuelve el dominio par08s09-in-f24.1e100.net, que corresponde a Google. Con la opción +short evitamos una salida larga y más compleja de comprender.

Leer más

Nuevo RFC aconseja sobre DNSBL

Recientemente se ha publicado y he leído en segu-info la existencia de un nuevo RFC, el RFC 6471 que aconseja sobre las mejores prácticas para el uso de las listas de DNS para el filtrado del correo electrónico. Dichas listas son las que se usan habitualmente en servidores DNS para saber si una dirección IP es proveedora de SPAM, por ejemplo.

Lo nota más destacable e importante de dicho RFC y por lo que merece este post es por que aconseja a los administradores no usar aquellas listas (DNSBL) que cobren por dar de baja una IP no proveedora de SPAM o que tarden mucho tiempo en realizar este proceso. La idea, sin duda, no es otra que dar credibilidad y rápida respuesta a dichas listas, algo especialmente importante y que facilite la detección de correo no deseado.

Leer más

dig, solicitar transferencia de zona

dig es un comando muy complejo, que como ya se vio permite realizar consultas al DNS para obtener diversa información de una IP o de un dominio, pero también permite realizar transferencias de zona. Para realizarlo, únicamente es necesario al final del comando "axfr".

Un ejemplo de ejecución, tras el salto.

shell> dig mydomain.com @192.168.1.3 axfr

; <<>> DiG 9.3.4-P1 <<>> mydomain.com @192.168.1.3 axfr
; (1 server found)
;; global options:  printcmd
mydomain.com.  86400  IN  SOA  ns1.mydomain.es. ...
mydomain.com.  86400  IN  A    192.168.1.160
mydomain.com.  86400  IN  NS   ns2.mydomain.com.
mydomain.com.  86400  IN  NS   ns1.mydomain.com.
mydomain.com.  86400  IN  MX   mail.mydomain.com.
(...)
;; Query time: 11 sec
;; SERVER: 192.168.1.3#53(192.168.1.3)
;; WHEN: Fri Nov 15 19:32:57 2011
;; XFR size: 29 records (messages 1)

Y en caso de que la transferencia falle,

shell> dig mydomain.com @192.168.1.3 axfr
; <<>> DiG 9.7.3 <<>> mydomain.com @192.168.1.3 axfr
;; global options: +cmd
; Transfer failed.

Leer más

Descubriendo virtualhosts bajo una IP

Recientemente descubrí las opciones avanzadas de búsqueda de bing y la verdad es que vi algo sorprendente y que, desde mi punto de vista, hace bien respecto a Google, que es almacenar la IP del site que indexa. bing permite lanzar búsquedas estilo "ip: 32.59.65.0" y también búsquedas filtrando los sitios, tipo "site: www.pepe.com" o "-site:www.pepe.com", que mostrará todos los resultados de la web pepe.com y todos los que no sean pepe.com, respectivamente.

Yo llevaba un tiempo buscando una forma de poder averiguar el número de virtualhost que hay detrás de una misma IP y la verdad es que no conseguía una herramienta simple y que lo hiciera de forma rápida, así que... aprovechando estas facilitys de bing, opté por investigar un poco más en ese sentido. Pues bien, resulta que hay una librería escrita en python que permite realizar búsquedas de forma rápida y simple usando bing, así que únicamente habría que probarla y escribir un pequeño script que realizase tal tarea. Mucho más fácil que usar curl o lynx! así que, manos a la obra.

• Descargamos la librería pybing para poder usarla, tal como se indica en la página oficial.

  shell> mkdir pybing
  shell> export PYTHONPATH=~/pybing/
  shell> cd pybing
  shell> svn checkout http://pybing.googlecode.com/svn/trunk/ ~/pybing
  

• Instalamos la librería httplib de python. Si usamos debian/ubuntu,

  shell> apt-get install python-httplib2

• Obtenemos un ID válido de microsoft para usar la API de bing.
  Para ello vamos a la web oficial y pedimos un nuevo ID de desarrollador. Es necesario tener una cuenta hotmail/msn con la que asociarlo.
• Finalmente, copiamos el script y sustituimos el ID de la API donde se indica.

Leer más

Comandos interesantes: dig

El comando dig sirve pare realizar consultas sencillas a un servidor DNS y obtener cualquier registro que interese de un dominio. Por defecto, el comando usa los servidores predeterminados de nuestro sistema, ubicados en /etc/resolv.conf y pide los registros de tipo A.

shell> dig google.es

; <<>> DiG 9.7.3 <<>> google.es
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode:QUERY, status:NOERROR, id:11789
;; flags:qr rd ra; QUERY:1, ANSWER:6, AUTHORITY:0, ADDITIONAL:0

;; QUESTION SECTION:
;google.es.   IN A

;; ANSWER SECTION:
google.es.    300   IN   A   209.85.148.104
google.es.    300   IN   A   209.85.148.106
google.es.    300   IN   A   209.85.148.103
google.es.    300   IN   A   209.85.148.105
google.es.    300   IN   A   209.85.148.99
google.es.    300   IN   A   209.85.148.147

;; Query time: 63 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 11 17:13:38 2011
;; MSG SIZE  rcvd: 123

Los princiaples registros que DNS maneja son:

• A, define la dirección IPv4.
• AAA, define la dirección IPv6.
• NS, define los servidores DNS.
• MX, define los servidores de correo.
• CNAME, permite definir alias de otros nombres.
• SOA, contiene información sobre el servidor DNS primario
• LOC, define la localización

Para pedir un registro específico al DNS, simplemente indicamos en el comando el tipo.

Leer más

DNS tuneling: iodine

Hoy vamos a ver cómo emplear el protocolo DNS para salir a Intenet y navegar en aquellos lugares que la conexión de pago no nos lo permite, por ejemplo aeropuertos.

Escenario

Cualquier lugar que permita establecer una conexión a la red, pero que luego no permita navegar sin, por ejemplo, usuario o previo pago, pero que sin embargo, sí permita una resolución DNS correcta.

Si hacemos ping a Google, sabremos qué IP resuelve, pero no seremos capaces de establecer la conexión con la página. En este tipo de escenarios, son sobre los que se puede aplicar un túnel DNS.

Herramientas

Existe diversas herramientas en la red que permiten crear este tipo de servicios. Las dos que vamos a ver son: iodine y nstx.

Configuración de iodine

iodine está disponible para Linux, MacOS, y Windows. Presenta un método de autenticación muy bueno, para que nadie que no esté autenticado lo pueda emplear y además, está disponible desde los repositorios de Debian. La instalación es muy sencilla,

shell> apt-get install iodine

tanto para el lado del cliente como para el lado del servidor.

Lo primero es configurar el servidor al que nos vamos a tener que conectar. Para ello, necesitamos instalar el software y tener un nombre DNS que resuelva en Internet. Para este ejemplo, vamos a optar por sacar el nombre domain.com que apunte a la IP 158.36.2.56. En el servidor, tendremos el servicio iodine a la escucha. Las entradas de DNS quedarían tal que así:

tunnel   IN   A    158.36.2.56
dns      IN   NS   tunnel.domain.com

Y para iniciar el servicio instalado,

server> iodined -f 10.0.0.1 tunnel.domain.com

Por parte del cliente, también hay que arrancar el servicio, pero éste como consumidor de datos,

client> iodine tunnel.domain.com

Con esto se crearían una red con dos direcciones IP (10.0.0.1 y 10.0.0.2) en las que todo el tráfico quedaría encapsulado mediante peticiones DNS y por lo tanto camuflado contra bloqueos de tráfico IP. El cliente, por supuesto tendría que tener como ruta por defecto la red del túnel DNS, que queda automáticamente configurada al arrancar el servicio iodine.

En la próxima entrega, hablaré más de nstx.

Leer más