Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
linux:kea [02.03.2024 19:51. ] – [Paketinhalt] django | linux:kea [02.03.2024 21:50. ] (aktuell) – [DHCPv4 Server] django | ||
---|---|---|---|
Zeile 997: | Zeile 997: | ||
===== Dokumentation ===== | ===== Dokumentation ===== | ||
- | Eine ausführliche Onlinedokumentation des **[[https:// | + | Eine ausführliche Onlinedokumentation des **[[https:// |
+ | |||
+ | ===== Konfiguration ===== | ||
+ | Die Konfiguration unseres DHCPv4 und DHCPv6-Servers wie auch des Controll-Agenten und ggf. des Kea DHCP DDNS Daemaons erfolgt über JSON-Konfigurationsdateien im Verzeichnis **''/ | ||
+ | |||
+ | ==== DHCPv4 Server ==== | ||
+ | Zunächst wollen wir uns eingehend mit der Konfiguration unseres DHCPv4-Daemons befassen. Die zugehörige Original-Dokumentation findet sich im Abschnitt **[[https:// | ||
+ | |||
+ | In unserer Betriebsumgebung haben wir folgende Rahmenbedingungen für unseren DHCPv4-Server: | ||
+ | * **Netzwerkinterface** : \\ Unser DHCPv4-Daemon soll auf dem Netzwerkinterface **'' | ||
+ | * **Leases** : \\ In unserer Beispielumgebung sollen die Leases unserer Clients in der Datei **''/ | ||
+ | * **Name-Server** : \\ Der interne DNS-Daemon ist unter der IP-Adresse **'' | ||
+ | * **Domain-Name** : \\ Der Name unserer Domain lautet **'' | ||
+ | * **Domain-Search-Liste** : \\ Der DHCPv4-Server soll als Domain-Search-List ausgeben: **'' | ||
+ | * **Time-Server** : \\ Der interne Time-Server ist unter der IP-Adresse **'' | ||
+ | * **Router** : \\ Der Default-Router ist unter der IP-Adresse **'' | ||
+ | * **Subnetz** : \\ Der DHCPv4-Server ist zuständig für das Netz **'' | ||
+ | * **Pool (dynamischer Adress-Bereich)** : \\ Dynamische IP-Adressen sollen aus dem Bereich von **'' | ||
+ | |||
+ | Bei der Installation unseres Kea-Servers wurde uns eine entsprechende Musterkonfigurations-Datei bereits mitgeliefert. | ||
+ | # less / | ||
+ | |||
+ | ++++ / | ||
+ | < | ||
+ | // 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:// | ||
+ | // the stable version is https:// | ||
+ | // | ||
+ | // This configuration file contains only DHCPv4 server' | ||
+ | // 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. | ||
+ | " | ||
+ | // Add names of your network interfaces to listen on. | ||
+ | " | ||
+ | // See section 8.2.4 for more details. You probably want to add just | ||
+ | // interface name (e.g. " | ||
+ | // interface name (e.g. " | ||
+ | " | ||
+ | |||
+ | // 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: | ||
+ | // " | ||
+ | }, | ||
+ | |||
+ | // 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), | ||
+ | // configuration from file), statistic-get (to retrieve statistics) and many | ||
+ | // more. For detailed description, | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | |||
+ | // 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 " | ||
+ | // Storage" | ||
+ | " | ||
+ | // Memfile is the simplest and easiest backend to use. It's an in-memory | ||
+ | // C++ database that stores its state in CSV file. | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | |||
+ | // Kea allows storing host reservations in a database. If your network is | ||
+ | // small or you have few reservations, | ||
+ | // in the configuration file. If your network is large, it's usually better | ||
+ | // to use database for it. To enable it, uncomment the following: | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // }, | ||
+ | // See Section 7.2.3 "Hosts storage" | ||
+ | |||
+ | // 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. | ||
+ | // If both " | ||
+ | // not 0, when the client sends a release message the lease is expired | ||
+ | // instead of being deleted from the lease storage. | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | |||
+ | // Global timers specified here apply to all subnets, unless there are | ||
+ | // subnet specific values defined in particular subnets. | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | |||
+ | // Many additional parameters can be specified here: | ||
+ | // - option definitions (if you want to define vendor options, your own | ||
+ | // | ||
+ | // 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 " | ||
+ | // vendor options (see Section 7.2.10) and allows users to define their | ||
+ | // own custom options (see Section 7.2.9). | ||
+ | " | ||
+ | // 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 " | ||
+ | // use encapsulate options. csv-format defaults to " | ||
+ | // 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: | ||
+ | // { | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // } | ||
+ | // but it's a lot of writing, so it's easier to do this instead: | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | |||
+ | // 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 " | ||
+ | // option code 15, so you can reference to it either by | ||
+ | // " | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | |||
+ | // Domain search is also a popular option. It tells the client to | ||
+ | // attempt to resolve names within those specified domains. For | ||
+ | // example, name " | ||
+ | // foo.mydomain.example.com and if it fails, then as foo.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 " | ||
+ | // slightly uncommon double backslashes notation is needed. | ||
+ | |||
+ | // Legal JSON escapes are \ followed by " | ||
+ | // or \u followed by 4 hexadecimal numbers (currently Kea | ||
+ | // supports only \u0000 to \u00ff code points). | ||
+ | // CSV processing translates ' | ||
+ | // only so for instance ' | ||
+ | // as it works on a JSON string value each of these ' | ||
+ | // characters must be doubled on JSON input. | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | |||
+ | // 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). | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | |||
+ | // 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), | ||
+ | // 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, | ||
+ | // devices, iphones, broken printers that require special options, etc. | ||
+ | // Based on the class information, | ||
+ | // to use certain subnets, add special options for them or change values | ||
+ | // of some fixed fields. | ||
+ | " | ||
+ | { | ||
+ | // This specifies a name of this class. It's useful if you need to | ||
+ | // reference this class. | ||
+ | " | ||
+ | |||
+ | // 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. | ||
+ | " | ||
+ | |||
+ | // 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. | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | |||
+ | // 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, | ||
+ | // more flexible ways, and even add extra commands. For a list of available | ||
+ | // hook libraries, see https:// | ||
+ | // " | ||
+ | // { | ||
+ | // // 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. | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // } | ||
+ | // }, | ||
+ | // { | ||
+ | // // 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. | ||
+ | // " | ||
+ | // " | ||
+ | // " | ||
+ | // } | ||
+ | // } | ||
+ | // ], | ||
+ | |||
+ | // 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 " | ||
+ | // structures. | ||
+ | " | ||
+ | { | ||
+ | // 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. | ||
+ | |||
+ | // Subnet identifier should be unique for each subnet. | ||
+ | " | ||
+ | |||
+ | // This is mandatory parameter for each subnet. | ||
+ | " | ||
+ | |||
+ | // 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. | ||
+ | " | ||
+ | |||
+ | // 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. | ||
+ | " | ||
+ | { | ||
+ | // For each IPv4 subnet you most likely need to specify at | ||
+ | // least one router. | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | ], | ||
+ | |||
+ | // Kea offers host reservations mechanism. Kea supports reservations | ||
+ | // by several different types of identifiers: | ||
+ | // (hardware/ | ||
+ | // 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. | ||
+ | " | ||
+ | |||
+ | // This is a reservation for a specific hardware/ | ||
+ | // It's a rather simple reservation: | ||
+ | // else. | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | |||
+ | // 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. | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | |||
+ | // 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. | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } ] | ||
+ | }, | ||
+ | |||
+ | // 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. | ||
+ | // specific options. | ||
+ | // | ||
+ | // When using reservations, | ||
+ | // reservations-global, | ||
+ | // reservations-out-of-pool (subnet specific parameters) | ||
+ | // and host-reservation-identifiers (global parameter). | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | ] | ||
+ | }, | ||
+ | // 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 | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | }, | ||
+ | // 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], | ||
+ | // 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. | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | // 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. | ||
+ | " | ||
+ | { | ||
+ | // 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. | ||
+ | " | ||
+ | " | ||
+ | { | ||
+ | // 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 | ||
+ | " | ||
+ | |||
+ | // Shorter log pattern suitable for use with systemd, | ||
+ | // avoids redundant information | ||
+ | // " | ||
+ | |||
+ | // This governs whether the log output is flushed to disk after | ||
+ | // every write. | ||
+ | // " | ||
+ | |||
+ | // This specifies the maximum size of the file before it is | ||
+ | // rotated. | ||
+ | // " | ||
+ | |||
+ | // This specifies the maximum number of rotated files to keep. | ||
+ | // " | ||
+ | } | ||
+ | ], | ||
+ | // This specifies the severity of log messages to keep. Supported values | ||
+ | // are: FATAL, ERROR, WARN, INFO, DEBUG | ||
+ | " | ||
+ | |||
+ | // 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. | ||
+ | " | ||
+ | } | ||
+ | ] | ||
+ | } | ||
+ | }</ | ||
+ | |||
+ | ++++ | ||
+ | |||
+ | Bevor wir nun aber unseren Kea-DHCPv4-Daemon individuell nach unseren Bedürfnissen hin anpassen, werden wir zunächst die im Paket mitgelieferte Original-Konfigurationsdatei **''/ | ||
+ | # cp -a / | ||
+ | |||
+ | So können wir später bei etwaigen Bedarf Vergleiche zur originalen Konfigurationsdatei mit unserer individuellen Konfigurationsdatei anstreben, wie in diesem Beispiel hier: | ||
+ | # vimdiff / | ||
+ | FIXME | ||