El libre pensamiento para un internet libre

No estas registrado.  

Anuncio

Wifi-libre.com: El libre pensamiento para un internet libre / Regístrese ahora

#1 20-01-2023 00:04:06

kcdtv
Administrator

Registrado: 14-11-2014
Mensajes: 5,677

Probando kea de isc ¿El futuro del servidor DHCP?

Probando kea de isc sobre una interfaz wifi para hacer de servidor DHCP en un Rogue AP

kea_8.jpg

  Hace poco hemos hablado de la "muerte" (End Of Life) de isc-dhcp (ver ISC DHCP alcanza su "fin de vida" (y nos importa))
  Hablamos de una herramienta que tiene más de 30 años de existencia y que todavía está empleada en muchas distribuciones.
  Tarde o temprano las distribuciones van a pasar a otro programa por defecto para gestionar la asignación automática de IP. 
 
  kea es un candidato muy serio.
En primer lugar, kea es obra del Internet Software Consortium, es decir los mismísimos creadores de ISC-DHCP.
Impone en un CV big_smile
  En este PDF de presentación explican por qué han abandonado isc-dhcp y empezado un proyecto nuevo.
Consideran isc-dhcp demasiado lento para las exigencias en redes modernas, desfasado en su gestión de las *db y demasiado pendiente de un reinicio para aplicar cambios.
Reconocen también que las "man pages" son infumables (no es la primera vez que oigo algo respecto...)
Nos invitan entonces a pasarnos a kea por los siguientes motivos:

  • Escrito en C++

  • Código abierto (GPL)

  • DHCPv4 y v6, conforme con todos los estándares y especificaciones

  • Se puede extender "hasta el infinito" o reconfigurar cada linea del código gracias a sus hooks (Los "ganchos" son scripts que permiten "re-compilar" la herramienta antes de ejecutarla,  por decirlo de un modo)

  • Es más rápido

  • Los leases se pueden almacenar en *db

  • Se ha mejorado el problema de dependencia de reinicio para aplicar cambios

  • Mejor Documentación

  Suena muy bien. Ahora a ver qué tal nos va la experiencia.

Instalación y documentación

  Lo primero para llegar a estar empelado por defecto en alguna distribución y es también fundamental para llegar al publico. es estar en los repositorios de las distribuciones. 
Es el caso en debian, La matriz de los sistemas Ubuntu, Linux Mint, Kali linux....
Estar en los repositorios debian es clave.
Podemos así instalarlo ejecutando en consola

sudo apt install kea

kea es un meta-paquete compuesto por

  • kea-admin

  • kea-ctrl-agent

  • kea-dhcp-ddns-server

  • kea-dhcp4-server

  • kea-dhcp6-server

Parece más que suficiente para hacer nuestros Rogue AP.
Existe también un paquete "kea dev" que podremos probar si no logramos nuestros objetivos.

  Sobre la documentación, se ve de inmediato un gran esfuerzo para explicar las cosas en su manual.
Se necesita un documento referente así, un verdadero "libro" para administradores de redes.
Manos a la obra, vamos a arrancar un hotspot con hostapd y usar kea para que los clientes obtengan automáticamente su IP (v4)

Configuración kea

En debian encontramos los ficheros de configuración ya hechos en /etc/kea

kea_1.jpg

Los dos primeros ficheros son para keactrl , el demonio que sirve a  arrancar-parrar-reiniciar el servicio.
El demonio ejecutará por defecto el fichero llamado keactrcl.conf en este mismo directorio
Si echamos un ojo vemos que arranca por defecto dhcp4 y 6

# Start DHCPv4 server?
dhcp4=yes

# Start DHCPv6 server?
dhcp6=yes

# Start DHCP DDNS server?
dhcp_ddns=no

# Start Control Agent?
ctrl_agent=yes

# Start Netconf?
netconf=no

# Be verbose?
kea_verbose=no

Podemos o no modificarlo, de mi lado he decidido desactivar el dhcp6 y activar la verbose.

Por lo que es de kea-ctrcl-agent.conf indica los caminos por defecto .
Cómo hemos pasado por nuestros repositorios no debemos tocarlo, todo está dónde el fichero apunta.

  Ahora lo que realmente importa, el fichero de muestra para servidor IPv4, y es algo largo, todo o casi está desactivado.
Sería cuestión de leer si queremos hacer algo fuera de lo normal y "descomentar" las lineas que nos interesan y editarlas si necesario.
Dejo aquí el fichero propuesto:

// This is a basic configuration for the Kea DHCPv4 server. Subnet declarations
// are mostly commented out and no interfaces are listed. Therefore, the servers
// will not listen or respond to any queries.
// The basic configuration must be extended to specify interfaces on which
// the servers should listen. There are a number of example options defined.
// These probably don't make any sense in your network. Make sure you at least
// update the following, before running this example in your network:
// - change the network interface names
// - change the subnets to match your actual network
// - change the option values to match your network
//
// This is just a very basic configuration. Kea comes with large suite (over 30)
// of configuration examples and extensive Kea User's Guide. Please refer to
// those materials to get better understanding of what this software is able to
// do. Comments in this configuration file sometimes refer to sections for more
// details. These are section numbers in Kea User's Guide. The version matching
// your software should come with your Kea package, but it is also available
// in ISC's Knowledgebase (https://kea.readthedocs.io; the direct link for
// the stable version is https://kea.readthedocs.io/).
//
// This configuration file contains only DHCPv4 server's configuration.
// If configurations for other Kea services are also included in this file they
// are ignored by the DHCPv4 server.
{

// DHCPv4 configuration starts here. This section will be read by DHCPv4 server
// and will be ignored by other components.
"Dhcp4": {
    // Add names of your network interfaces to listen on.
    "interfaces-config": {
        // See section 8.2.4 for more details. You probably want to add just
        // interface name (e.g. "eth0" or specific IPv4 address on that
        // interface name (e.g. "eth0/192.0.2.1").
        "interfaces": [ "" ]

        // Kea DHCPv4 server by default listens using raw sockets. This ensures
        // all packets, including those sent by directly connected clients
        // that don't have IPv4 address yet, are received. However, if your
        // traffic is always relayed, it is often better to use regular
        // UDP sockets. If you want to do that, uncomment this line:
        // "dhcp-socket-type": "udp"
    },

    // Kea supports control channel, which is a way to receive management
    // commands while the server is running. This is a Unix domain socket that
    // receives commands formatted in JSON, e.g. config-set (which sets new
    // configuration), config-reload (which tells Kea to reload its
    // configuration from file), statistic-get (to retrieve statistics) and many
    // more. For detailed description, see Sections 8.8, 16 and 15.
    "control-socket": {
        "socket-type": "unix",
        "socket-name": "/tmp/kea4-ctrl-socket"
    },

    // Use Memfile lease database backend to store leases in a CSV file.
    // Depending on how Kea was compiled, it may also support SQL databases
    // (MySQL and/or PostgreSQL). Those database backends require more
    // parameters, like name, host and possibly user and password.
    // There are dedicated examples for each backend. See Section 7.2.2 "Lease
    // Storage" for details.
    "lease-database": {
        // Memfile is the simplest and easiest backend to use. It's an in-memory
        // C++ database that stores its state in CSV file.
        "type": "memfile",
        "lfc-interval": 3600
    },

    // Kea allows storing host reservations in a database. If your network is
    // small or you have few reservations, it's probably easier to keep them
    // in the configuration file. If your network is large, it's usually better
    // to use database for it. To enable it, uncomment the following:
    // "hosts-database": {
    //     "type": "mysql",
    //     "name": "kea",
    //     "user": "kea",
    //     "password": "kea",
    //     "host": "localhost",
    //     "port": 3306
    // },
    // See Section 7.2.3 "Hosts storage" for details.

    // Setup reclamation of the expired leases and leases affinity.
    // Expired leases will be reclaimed every 10 seconds. Every 25
    // seconds reclaimed leases, which have expired more than 3600
    // seconds ago, will be removed. The limits for leases reclamation
    // are 100 leases or 250 ms for a single cycle. A warning message
    // will be logged if there are still expired leases in the
    // database after 5 consecutive reclamation cycles.
    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "unwarned-reclaim-cycles": 5
    },

    // Global timers specified here apply to all subnets, unless there are
    // subnet specific values defined in particular subnets.
    "renew-timer": 900,
    "rebind-timer": 1800,
    "valid-lifetime": 3600,

    // Many additional parameters can be specified here:
    // - option definitions (if you want to define vendor options, your own
    //                       custom options or perhaps handle standard options
    //                       that Kea does not support out of the box yet)
    // - client classes
    // - hooks
    // - ddns information (how the DHCPv4 component can reach a DDNS daemon)
    //
    // Some of them have examples below, but there are other parameters.
    // Consult Kea User's Guide to find out about them.

    // These are global options. They are going to be sent when a client
    // requests them, unless overwritten with values in more specific scopes.
    // The scope hierarchy is:
    // - global (most generic, can be overwritten by class, subnet or host)
    // - class (can be overwritten by subnet or host)
    // - subnet (can be overwritten by host)
    // - host (most specific, overwrites any other scopes)
    //
    // Not all of those options make sense. Please configure only those that
    // are actually useful in your network.
    //
    // For a complete list of options currently supported by Kea, see
    // Section 7.2.8 "Standard DHCPv4 Options". Kea also supports
    // vendor options (see Section 7.2.10) and allows users to define their
    // own custom options (see Section 7.2.9).
    "option-data": [
        // When specifying options, you typically need to specify
        // one of (name or code) and data. The full option specification
        // covers name, code, space, csv-format and data.
        // space defaults to "dhcp4" which is usually correct, unless you
        // use encapsulate options. csv-format defaults to "true", so
        // this is also correct, unless you want to specify the whole
        // option value as long hex string. For example, to specify
        // domain-name-servers you could do this:
        // {
        //     "name": "domain-name-servers",
        //     "code": 6,
        //     "csv-format": "true",
        //     "space": "dhcp4",
        //     "data": "192.0.2.1, 192.0.2.2"
        // }
        // but it's a lot of writing, so it's easier to do this instead:
        {
            "name": "domain-name-servers",
            "data": "192.0.2.1, 192.0.2.2"
        },

        // Typically people prefer to refer to options by their names, so they
        // don't need to remember the code names. However, some people like
        // to use numerical values. For example, option "domain-name" uses
        // option code 15, so you can reference to it either by
        // "name": "domain-name" or "code": 15.
        {
            "code": 15,
            "data": "example.org"
        },

        // Domain search is also a popular option. It tells the client to
        // attempt to resolve names within those specified domains. For
        // example, name "foo" would be attempted to be resolved as
        // foo.mydomain.example.com and if it fails, then as foo.example.com
        {
            "name": "domain-search",
            "data": "mydomain.example.com, example.com"
        },

        // String options that have a comma in their values need to have
        // it escaped (i.e. each comma is preceded by two backslashes).
        // That's because commas are reserved for separating fields in
        // compound options. At the same time, we need to be conformant
        // with JSON spec, that does not allow "\,". Therefore the
        // slightly uncommon double backslashes notation is needed.

        // Legal JSON escapes are \ followed by "\/bfnrt character
        // or \u followed by 4 hexadecimal numbers (currently Kea
        // supports only \u0000 to \u00ff code points).
        // CSV processing translates '\\' into '\' and '\,' into ','
        // only so for instance '\x' is translated into '\x'. But
        // as it works on a JSON string value each of these '\'
        // characters must be doubled on JSON input.
        {
            "name": "boot-file-name",
            "data": "EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00"
        },

        // Options that take integer values can either be specified in
        // dec or hex format. Hex format could be either plain (e.g. abcd)
        // or prefixed with 0x (e.g. 0xabcd).
        {
            "name": "default-ip-ttl",
            "data": "0xf0"
        }

        // Note that Kea provides some of the options on its own. In particular,
        // it sends IP Address lease type (code 51, based on valid-lifetime
        // parameter, Subnet mask (code 1, based on subnet definition), Renewal
        // time (code 58, based on renew-timer parameter), Rebind time (code 59,
        // based on rebind-timer parameter).
    ],

    // Other global parameters that can be defined here are option definitions
    // (this is useful if you want to use vendor options, your own custom
    // options or perhaps handle options that Kea does not handle out of the box
    // yet).

    // You can also define classes. If classes are defined, incoming packets
    // may be assigned to specific classes. A client class can represent any
    // group of devices that share some common characteristic, e.g. Windows
    // devices, iphones, broken printers that require special options, etc.
    // Based on the class information, you can then allow or reject clients
    // to use certain subnets, add special options for them or change values
    // of some fixed fields.
    "client-classes": [
        {
            // This specifies a name of this class. It's useful if you need to
            // reference this class.
            "name": "voip",

            // This is a test. It is an expression that is being evaluated on
            // each incoming packet. It is supposed to evaluate to either
            // true or false. If it's true, the packet is added to specified
            // class. See Section 12 for a list of available expressions. There
            // are several dozens. Section 8.2.14 for more details for DHCPv4
            // classification and Section 9.2.19 for DHCPv6.
            "test": "substring(option[60].hex,0,6) == 'Aastra'",

            // If a client belongs to this class, you can define extra behavior.
            // For example, certain fields in DHCPv4 packet will be set to
            // certain values.
            "next-server": "192.0.2.254",
            "server-hostname": "hal9000",
            "boot-file-name": "/dev/null"

            // You can also define option values here if you want devices from
            // this class to receive special options.
        }
    ],

    // Another thing possible here are hooks. Kea supports a powerful mechanism
    // that allows loading external libraries that can extract information and
    // even influence how the server processes packets. Those libraries include
    // additional forensic logging capabilities, ability to reserve hosts in
    // more flexible ways, and even add extra commands. For a list of available
    // hook libraries, see https://gitlab.isc.org/isc-projects/kea/wikis/Hooks-available.
    // "hooks-libraries": [
    //   {
    //       // Forensic Logging library generates forensic type of audit trail
    //       // of all devices serviced by Kea, including their identifiers
    //       // (like MAC address), their location in the network, times
    //       // when they were active etc.
    //       "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_legal_log.so",
    //       "parameters": {
    //           "path": "/var/lib/kea",
    //           "base-name": "kea-forensic4"
    //       }
    //   },
    //   {
    //       // Flexible identifier (flex-id). Kea software provides a way to
    //       // handle host reservations that include addresses, prefixes,
    //       // options, client classes and other features. The reservation can
    //       // be based on hardware address, DUID, circuit-id or client-id in
    //       // DHCPv4 and using hardware address or DUID in DHCPv6. However,
    //       // there are sometimes scenario where the reservation is more
    //       // complex, e.g. uses other options that mentioned above, uses part
    //       // of specific options or perhaps even a combination of several
    //       // options and fields to uniquely identify a client. Those scenarios
    //       // are addressed by the Flexible Identifiers hook application.
    //       "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_flex_id.so",
    //       "parameters": {
    //           "identifier-expression": "relay4[2].hex"
    //       }
    //   }
    // ],

    // Below an example of a simple IPv4 subnet declaration. Uncomment to enable
    // it. This is a list, denoted with [ ], of structures, each denoted with
    // { }. Each structure describes a single subnet and may have several
    // parameters. One of those parameters is "pools" that is also a list of
    // structures.
    "subnet4": [
        {
            // This defines the whole subnet. Kea will use this information to
            // determine where the clients are connected. This is the whole
            // subnet in your network. This is mandatory parameter for each
            // subnet.
            "subnet": "192.0.2.0/24",

            // Pools define the actual part of your subnet that is governed
            // by Kea. Technically this is optional parameter, but it's
            // almost always needed for DHCP to do its job. If you omit it,
            // clients won't be able to get addresses, unless there are
            // host reservations defined for them.
            "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],

            // These are options that are subnet specific. In most cases,
            // you need to define at least routers option, as without this
            // option your clients will not be able to reach their default
            // gateway and will not have Internet connectivity.
            "option-data": [
                {
                    // For each IPv4 subnet you most likely need to specify at
                    // least one router.
                    "name": "routers",
                    "data": "192.0.2.1"
                }
            ],

            // Kea offers host reservations mechanism. Kea supports reservations
            // by several different types of identifiers: hw-address
            // (hardware/MAC address of the client), duid (DUID inserted by the
            // client), client-id (client identifier inserted by the client) and
            // circuit-id (circuit identifier inserted by the relay agent).
            //
            // Kea also support flexible identifier (flex-id), which lets you
            // specify an expression that is evaluated for each incoming packet.
            // Resulting value is then used for as an identifier.
            //
            // Note that reservations are subnet-specific in Kea. This is
            // different than ISC DHCP. Keep that in mind when migrating
            // your configurations.
            "reservations": [

                // This is a reservation for a specific hardware/MAC address.
                // It's a rather simple reservation: just an address and nothing
                // else.
                {
                    "hw-address": "1a:1b:1c:1d:1e:1f",
                    "ip-address": "192.0.2.201"
                },

                // This is a reservation for a specific client-id. It also shows
                // the this client will get a reserved hostname. A hostname can
                // be defined for any identifier type, not just client-id.
                {
                    "client-id": "01:11:22:33:44:55:66",
                    "ip-address": "192.0.2.202",
                    "hostname": "special-snowflake"
                },

                // The third reservation is based on DUID. This reservation defines
                // a special option values for this particular client. If the
                // domain-name-servers option would have been defined on a global,
                // subnet or class level, the host specific values take preference.
                {
                    "duid": "01:02:03:04:05",
                    "ip-address": "192.0.2.203",
                    "option-data": [ {
                        "name": "domain-name-servers",
                        "data": "10.1.1.202, 10.1.1.203"
                    } ]
                },

                // The fourth reservation is based on circuit-id. This is an option
                // inserted by the relay agent that forwards the packet from client
                // to the server.  In this example the host is also assigned vendor
                // specific options.
                //
                // When using reservations, it is useful to configure
                // reservations-global, reservations-in-subnet,
                // reservations-out-of-pool (subnet specific parameters)
                // and host-reservation-identifiers (global parameter).
                {
                    "client-id": "01:12:23:34:45:56:67",
                    "ip-address": "192.0.2.204",
                    "option-data": [
                        {
                            "name": "vivso-suboptions",
                            "data": "4491"
                        },
                        {
                            "name": "tftp-servers",
                            "space": "vendor-4491",
                            "data": "10.1.1.202, 10.1.1.203"
                        }
                    ]
                },
                // This reservation is for a client that needs specific DHCPv4
                // fields to be set. Three supported fields are next-server,
                // server-hostname and boot-file-name
                {
                    "client-id": "01:0a:0b:0c:0d:0e:0f",
                    "ip-address": "192.0.2.205",
                    "next-server": "192.0.2.1",
                    "server-hostname": "hal9000",
                    "boot-file-name": "/dev/null"
                },
                // This reservation is using flexible identifier. Instead of
                // relying on specific field, sysadmin can define an expression
                // similar to what is used for client classification,
                // e.g. substring(relay[0].option[17],0,6). Then, based on the
                // value of that expression for incoming packet, the reservation
                // is matched. Expression can be specified either as hex or
                // plain text using single quotes.
                //
                // Note: flexible identifier requires flex_id hook library to be
                // loaded to work.
                {
                    "flex-id": "'s0mEVaLue'",
                    "ip-address": "192.0.2.206"
                }
                // You can add more reservations here.
            ]
            // You can add more subnets there.
        }
    ],

    // There are many, many more parameters that DHCPv4 server is able to use.
    // They were not added here to not overwhelm people with too much
    // information at once.

    // Logging configuration starts here. Kea uses different loggers to log various
    // activities. For details (e.g. names of loggers), see Chapter 18.
    "loggers": [
    {
        // This section affects kea-dhcp4, which is the base logger for DHCPv4
        // component. It tells DHCPv4 server to write all log messages (on
        // severity INFO or more) to a file.
        "name": "kea-dhcp4",
        "output_options": [
            {
                // Specifies the output file. There are several special values
                // supported:
                // - stdout (prints on standard output)
                // - stderr (prints on standard error)
                // - syslog (logs to syslog)
                // - syslog:name (logs to syslog using specified name)
                // Any other value is considered a name of the file
                "output": "/var/log/kea-dhcp4.log"

                // Shorter log pattern suitable for use with systemd,
                // avoids redundant information
                // "pattern": "%-5p %m\n",

                // This governs whether the log output is flushed to disk after
                // every write.
                // "flush": false,

                // This specifies the maximum size of the file before it is
                // rotated.
                // "maxsize": 1048576,

                // This specifies the maximum number of rotated files to keep.
                // "maxver": 8
            }
        ],
        // This specifies the severity of log messages to keep. Supported values
        // are: FATAL, ERROR, WARN, INFO, DEBUG
        "severity": "INFO",

        // If DEBUG level is specified, this value is used. 0 is least verbose,
        // 99 is most verbose. Be cautious, Kea can generate lots and lots
        // of logs if told to do so.
        "debuglevel": 0
    }
  ]
}
}

No se asusten. smile
Lo único que se debe hacer es poner su interfaz en la variable dedicada,
Se encuentra en linea 34 y se presenta así:

"interfaces": [  ] 

Ponemos la dirrección de nuestra interfaz wifi y la dirrección IP, dejándola así

"interfaces": [ "nombre_interfaz/192.0.2.1" ]

En mi caso

kea_5.jpg

  ¿Por qué esta IP?
Por qué es la que está configurada por defecto.

"subnet4": [
            {
                "subnet": "192.0.2.0/24",
                "pools": [
                    {
                        "pool": "192.0.2.1 - 192.0.2.200"
                    }
                ]
            }

En conclusión, la única cosas que debemos hacer para configurar el servidor dhcp4 de nuestro rogue AP es entrar la interfaz en el fichero kea-dhcp4.conf
Debemos abrir un editor de texto con superpoderes, ejemplo

sudo mousepad /etc/kea/kea-dhcp4-conf

Y rellenar la variable con nuestra interfaz dejándola por ejemplo así:

"interfaces": [ "wlan0/192.0.2.1" ]
Arancamos el soft PA hostapd

  Primero voy a fijar la mac de mi interfaz en la IP del "router" de mi red, pongo wlan0 cómo interfaz ya que es probablemente lo que te toca hacer

sudo ip addr add 192.0.2.1 dev wlan0

  De fichero de configuración puedes usar directamente esto si tu inetrfaz es wlan0

interface=wlan0
driver=nl80211
ssid=wifi-libre
hw_mode=g
ieee80211n=1
channel=7
wpa=2
wpa_passphrase=12345678
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

  Ahora arranco hostapd con la opción -i indicando my interfaz wifi y la ruta de mi fichero de configuración. Ejemplo:

sudo hostapd -i wlan0 '/home/kcdtv/Escritorio/hostapd.conf'

kea_3.jpg

Iniciar el servicio DHCP IPv4 de kea

¡Directo al grano!
Abrimos otra consola para ejecutar

sudo keactrl start -s dhcp4

¡Y ya está!
Podéis verificarlo con

sudo keactrl status -s dhcp4

kea_6.jpg

Mi celular se conecta enseguida:

kea_7.jpg

Conclusión

  * Sé que el tema puede parecer un poco denso porque voy descubriendo y explicando sobre la marcha.
Pero la realidad es que para hacer  nuestros rogue AP wifi es super simple y rapido.

  1. instalar kea con

    sudo apt install kea
  2. Editar la linea 34 del fichero /etc/kea/kea-dhcp4.conf poniendo su interfaz wifi (cómo wlan0) y la IP router de nuestra red casera (192.0.2.1)

    sudo mousepad /etc/kea/kea-dhcp4-conf
  3. Fijamos ahora la interfaz wifi que vamos a usar para que sea "el router" con

    sudo ip addr add 192.0.2.1 dev wlan0
  4. Lanzamos hostapd con nuestro fichero de conf en la interfaz wifi

    sudo hostapd -i wlan0 '/ruta/hostapd.conf`
  5. En otra consola arrancamos el servicio de asignación automática de IP de kea

     sudo keactrl start -s dhcp4

  * La asignación de IP automática es la más rápida que he visto. cool
Mi tel Android tarda ahora menos de un segundo para conectarse con su IP atribuida tirando del perfil hecho.
No creo que vaya más rápido con la IP puesta a mano...
  El servicio DHCP en está configuración mínima es una maravilla

  * La herramienta es tremendamente potente gracias al formato JSON, los hooks (es evolutiva sin limites), y la cantidad de parámetros y opciones disponibles

  Para responder a la pregunta del titulo: No sé si kea es el futuro del DHCP, lo que sé es que no estoy inquieto para el futuro del DHCP con herramientas del calibre de kea. biere

fuente

Desconectado

Anuncio

Wifi-libre.com: El libre pensamiento para un internet libre / Regístrese ahora

#2 20-01-2023 01:40:10

Koala
Very Important Usuario

Registrado: 11-09-2016
Mensajes: 975

Re: Probando kea de isc ¿El futuro del servidor DHCP?

Gracias por ese tema Kcdtv cool lo pongo en los favoritos


Hostbase rogue AP project con Kali-linux xfce.

Debian--Arch--Kali--

Desconectado

#3 20-01-2023 17:47:01

kcdtv
Administrator

Registrado: 14-11-2014
Mensajes: 5,677

Re: Probando kea de isc ¿El futuro del servidor DHCP?

De nada. smile

  Algo más, dejo aquí un fichero de configuración depurado para Rogue AP WiFi con kea-dhcp4

{
    # DHCPv4 configuration starts on the next line
    "Dhcp4": {
    
    # First we set up global values
        "valid-lifetime": 4000,
        "renew-timer": 1000,
        "rebind-timer": 2000,
    
    # Next we set up the interfaces to be used by the server.
        "interfaces-config": {
            "interfaces": [ "wlan0" ]
        },
    
    # And we specify the type of lease database
        "lease-database": {
            "type": "memfile",
            "persist": true,
            "name": "/var/lib/kea/dhcp4.leases"
        },
    
    # Finally, we list the subnets from which we will be leasing addresses.
        "subnet4": [
            {
                "subnet": "192.168.1.0/24",
                "pools": [
                    {
                        "pool": "192.168.1.1 - 192.168.1.200"
                    }
                ]
            }
        ],
        "option-data": [
                {
                    // For each IPv4 subnet you most likely need to specify at
                    // least one router.
                    "name": "routers",
                    "data": "192.168.1.1"
                }
        ],
    # DHCPv4 configuration ends with the next line
    }
}

Cómo es un rogue AP, he atribuido la IP  192.168.1.1 al router que es lo más habitual, y la interfaz es wlan0.
Es útil tirar de un fichero para no tener que modificar el sistema de fichero root
Es también más fácil cambiar los parámetros en una versión depurada y vemos que es sencillo tener lo más básico funcionando:

  1. Tres parámetros de tiempo

  2. La interfaz a usar

  3. La db a usar

  4. El rango IP

  5. La IP del "router" (nuestra interfaz WiFi)

  Para tirar de un fichero personal arrancaremos el servidor DHCP de kea así:

sudo kea-dhcp4 -c '/ruta/fichero/custom.conf'

  La opción -c hace lo mismo que en hostapd, simplifica la vida para memorizarlo.

Desconectado

Anuncio

Wifi-libre.com: El libre pensamiento para un internet libre / Regístrese ahora

Pie de página

Información del usuario

Ultimo usuario registrado: KELVIN1974
Usuarios registrados conectados: 0
Invitados conectados: 6

Estadisticas de los foros

Número total de usuarios registrados: 2,419
Número total de temas: 1,628
Número total de mensajes: 15,477

Máx. usuarios conectados: 373 el 30-09-2019 15:04:36