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:41. ] – [Paketinhalt] django | linux:kea [02.03.2024 21:50. ] (aktuell) – [DHCPv4 Server] django | ||
|---|---|---|---|
| Zeile 994: | Zeile 994: | ||
| kea / | kea / | ||
| + | ++++ | ||
| + | |||
| + | ===== Dokumentation ===== | ||
| + | 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 "Lease | ||
| + | // 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 | ||
django