| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| linux:kea [19.10.2024 15:11. ] – django | linux:kea [14.03.2025 13:17. ] (aktuell) – [Ergebniskontrolle] django |
|---|
| |
| |< 100% 5% 8% 12% 12% 12% 12% 12% >| | |< 100% 5% 8% 12% 12% 12% 12% 12% >| |
| ^ Subnetz \\ (ID) ^ Subnetz \\ (Use) ^ Subnetz Prefix\\ (global Unicast) ^ Host\\ - ^ IPv4\\ - ^ Link-Local-Scope\\ - ^ Unique-Local-Scope\\ (ULA) ^ Global-Scope\\ (GUA) ^ | ^ Subnetz \\ (ID) ^ Subnetz \\ (Use) ^ Subnetz Prefix\\ (global Unicast) ^ Host\\ - ^ IPv4\\ - ^ Link-Local-Scope\\ (LLA) ^ Unique-Local-Scope\\ (ULA) ^ Global-Scope\\ (GUA) ^ |
| | **7** | Intra | 2003:a:e0d:760**7**::/64 | | | | | | | | **7** | Intra | 2003:a:bcd:123**4**::/64 | | | | | | |
| | | | | //pml010073// | ''10.0.10.73'' | ''fe80::e9a6::bb03:1544:b0000/64'' | ''fdb6:cb48:9d77:0:10:0:10:073/64'' | ''2003:a:e0d:7607:10:0:10:73'' | | | | | | //pml010073// | ''10.0.10.73'' | ''fe80::e9a6::bb03:1544:b0000/64'' | ''fd00:dead:beef:0:10:0:10:073/64'' | ''2003:a:bcd:1234:10:0:10:73'' | |
| | | | | //pml010102// | ''10.0.10.102'' | ''fe80::10:ff:fe10:102'' | ''fdb6:cb48:9d77:0:10:0:10:102/64'' | ''2003:a:e0d:7607:10:0:10:102'' | | | | | | //pml010102// | ''10.0.10.102'' | ''fe80::10:ff:fe10:102'' | ''fdb6:dead:beef:0:10:0:10:102/64'' | ''2003:a:bcd:1234:10:0:10:102'' | |
| | | | | //vml010110// | ''10.0.10.110'' | ''fe80::10:ff:fe10:110'' | ''fdb6:cb48:9d77:0:10:0:10:110/64'' | ''2003:a:e0d:7607:10:0:10:110'' | | | | | | //vml010110// | ''10.0.10.110'' | ''fe80::10:ff:fe10:110'' | ''fdb6:dead:beef:0:10:0:10:110/64'' | ''2003:a:bcd:1234:10:0:10:110'' | |
| |
| |
| ==== Grund-Konfiguration ==== | ==== Grund-Konfiguration ==== |
| === Firewall/Paketfilter - firewalld === | === Firewall/Paketfilter - firewalld === |
| Bevor wir nun unseren **Kea-DHCP-Daemon** Konfigurieren und starten müssen wir natürlich sicherstellen, dass auf dem betreffendem Host auch die Kommunikationsbeziehungen entsprechend erlaubt sind. | Bevor wir nun unseren **Kea-DHCP-Daemon** konfigurieren und starten müssen wir natürlich sicherstellen, dass auf dem betreffendem Host auch die Kommunikationsbeziehungen entsprechend erlaubt sind. |
| |
| Wie auch schon früher bei **CentOS** ab Release **7** bzw. den nachfolgenden Relaese-Kandidaten **Stream von RHEL** nutzen wir auch unter **Arch Linux** den dynamischen **[[https://firewalld.org/|firewalld]]** Service. Ein grosser Vorteil der dynamischen Paketfilterregeln ist unter anderem, dass zur Aktivierung der neuen Firewall-Regel(n) nicht der Daemon durchgestartet werden muss und somit alle aktiven Verbindungen kurz getrennt werden. Sondern unsere Änderungen können **//on-the-fly//** aktiviert oder auch wieder deaktiviert werden. | Wie auch schon früher bei **CentOS** ab Release **7** bzw. den nachfolgenden Relaese-Kandidaten **Stream von RHEL** nutzen wir auch unter **Arch Linux** den dynamischen **[[https://firewalld.org/|firewalld]]** Service. Ein grosser Vorteil der dynamischen Paketfilterregeln ist unter anderem, dass zur Aktivierung der neuen Firewall-Regel(n) nicht der Daemon durchgestartet werden muss und somit alle aktiven Verbindungen kurz getrennt werden. Sondern unsere Änderungen können **//on-the-fly//** aktiviert oder auch wieder deaktiviert werden. |
| Werfen wir noch kurz einen Blick in die Zone **''intra''**: | Werfen wir noch kurz einen Blick in die Zone **''intra''**: |
| | |
| # firewall-cmd --zone=intra --list-services | <code> # firewall-cmd --zone=intra --list-services</code> |
| |
| dhcp dhcpv6 | dhcp dhcpv6 |
| Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rolle überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen: | Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rolle überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen: |
| |
| <code> $ mkdir -p ~/devel/ansible ; wget https://gitlab.nausch.org/django/example_kea/-/archive/main/example_kea-main.tar.gz -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code> | <code> $ mkdir -p ~/devel/ansible ; wget https://gitlab.nausch.org/django/example_kea/-/archive/main/example_kea-main.tar.gz \ |
| | -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code> |
| |
| Nach Anpassung der Daten im Inventory kann man anschliessend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**. | Nach Anpassung der Daten im Inventory kann man anschliessend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**. |
| |
| Die beiden Beispiel-Hosts aus der Gruppe|Zone **''intra''** in diesem Inventory symbolisieren folgende unterschiedlichen Knoten. | Die beiden Beispiel-Hosts aus der Gruppe|Zone **''intra''** in diesem Inventory symbolisieren folgende unterschiedlichen Knoten. |
| * Der Host **''pnc010007''** steht exeplarisch für einen Client im Intranet. In dessen Inventory-File **''inventories/production/host_vars/pnc010007''** sind die ihn beschreibenden Datein enthalten. | * Der Host **''pnc010007''** steht exemplarisch für einen Client im Intranet. In dessen Inventory-File **''inventories/production/host_vars/pnc010007''** sind die ihn beschreibenden Dateien enthalten. |
| * Der Host **''vml010110''** ist in diesem Beispiel unser Server, der die Verbindung zwischen der Zone **''intra''** und der Aussenwelt herstellt. Auf diesem Konten läuft bereits ein **[[linux:ntp|Chrony Timeserver|]]** wie auch eine Firewall auf Basis von **[[https://firewalld.org/|firewalld]]** der eine Zonendefinition **''intra''** besitzt, die die Regeln für diese Zone beinhalten. Sowohl Timeserver wie auch Firewall werden in diesem Beispiel hier nur erwähnt, da in dem Playbook bzw.genauer gesagt im Inventory darauf referenziert wird. | * Der Host **''vml010110''** ist in diesem Beispiel unser Server, der die Verbindung zwischen der Zone **''intra''** und der Aussenwelt herstellt. Auf diesem Konten läuft bereits ein **[[linux:ntp|Chrony Timeserver|]]** wie auch eine Firewall auf Basis von **[[https://firewalld.org/|firewalld]]** der eine Zonendefinition **''intra''** besitzt, die die Regeln für diese Zone beinhalten. Sowohl Timeserver wie auch Firewall werden in diesem Beispiel hier nur erwähnt, da in dem Playbook bzw.genauer gesagt im Inventory darauf referenziert wird. |
| |
| |
| === Playbook === | === Playbook === |
| Unser Playbook zum Installieren und Konfigurieren der beiden Kea-Daemon **kea-dhcp4** und **kea-dhcp6**, ist wie imer schlank, unscheinbar und unspektakulär, beinhaltet aber Hinweise zur Aufgabe und wie es aufzurufen ist. | Unser Playbook zum Installieren und Konfigurieren der beiden Kea-Daemon **kea-dhcp4** und **kea-dhcp6**, ist wie immer schlank, unscheinbar und unspektakulär, beinhaltet aber Hinweise zur Aufgabe und wie es aufzurufen ist. |
| $ vim playbooks/kea_dhcp.yml | $ vim playbooks/kea_dhcp.yml |
| ++++ playbooks/kea_dhcp.yml | | ++++ playbooks/kea_dhcp.yml | |
| |
| === Rolle === | === Rolle === |
| Für die Konfiguration der **kea**-Daemon verwenden wir eine eigene Rolle **''kea_dhcp''**, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. hierzu kopieren wir uns zunächst die Mustervorlage **''common''**. | Für die Konfiguration der **kea**-Daemon verwenden wir eine eigene Rolle **''kea_dhcp''**, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. Hierzu kopieren wir uns zunächst die Mustervorlage **''common''**. |
| $ cp -avr roles/common/ roles/kea_dhcp | $ cp -avr roles/common/ roles/kea_dhcp |
| |
| ++++ | ++++ |
| |
| Sollte bei der Abarbeitung des Playbook eine oder beide Konfigurationsdateien **''kea-dhcp4.conf''** und **''kea-dhcp6.conf''** verändert werden, ist natürlich hierbei ein Restart der betreffenden Kea-Daemon notwenig. Hierzu verwenden wir die **[[https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html|Ansible Playbook Handlers]]**. Diese Handler werden in den beiden Tasks zur Erstellung der Kea-Konfigurationsdateien mit Hilfe eines **handler**-Calls aufgerufen, sofern sich die Datei verändert hat. | Sollte bei der Abarbeitung des Playbook eine oder beide Konfigurationsdateien **''kea-dhcp4.conf''** und **''kea-dhcp6.conf''** verändert werden, ist natürlich hierbei ein Restart der betreffenden Kea-Daemon notwendig. Hierzu verwenden wir die **[[https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html|Ansible Playbook Handlers]]**. Diese Handler werden in den beiden Tasks zur Erstellung der Kea-Konfigurationsdateien mit Hilfe eines **handler**-Calls aufgerufen, sofern sich die Datei verändert hat. |
| |
| Zu guter Letzt brauchen wir noch eine Konfiguration der Aufgaben die bei einem **''notify''** abgearbeitet werden sollen. | Zu guter Letzt brauchen wir noch eine Konfiguration der Aufgaben die bei einem **''notify''** abgearbeitet werden sollen. |
| </html> | </html> |
| |
| === Ergebniskontrolle === | ==== Ergebniskontrolle ==== |
| Nun prüfen wir, ob unser **radvd** auch die richtigen Router Advertisement ICMPv6 Nachrichten ins Netz schickt. Hier bieten sich zwei mögliche Varianten an: | Ob die Konfigurationsdateien valide erstellt und auch von den Kea-Daemons erfolgreich geladen worden sind, kontrollieren wir zum Beispiel auf dem Zielhost mit einem Blick in die betreffenden Konfigurationsdateien, mit Hilfe der Option **''-t''** beim jeweiligen kea-binarys, oder mit Hilfe der **''status''**-Abfrage des betreffenden Kea-Daemons. |
| - Mit dem Programm **''radvdump''** aus dem Paket **radvd**. Hierzu starten wir dias besagte Binary auf einem unserer Clients im lokalen Netzwerk-Segment dieses Binary. <code> # radvdump</code><code># | * **kea-dhcp4** <code> # bat /etc/kea/kea-dhcp4.conf</code><code> # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf</code><code> # systemctl status kea-dhcp4</code> |
| # radvd configuration generated by radvdump 2.18 | * **kea-dhcp6** <code> # bat /etc/kea/kea-dhcp6.conf</code><code> # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf</code><code> # systemctl status kea-dhcp6</code> |
| # based on Router Advertisement from fe80::10:ff:fe10:110 | |
| # received by interface enp0s25 | |
| # | |
| | |
| interface enp0s25 | |
| { | |
| AdvSendAdvert on; | |
| # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump | |
| AdvManagedFlag on; | |
| AdvOtherConfigFlag on; | |
| AdvReachableTime 0; | |
| AdvRetransTimer 0; | |
| AdvCurHopLimit 64; | |
| AdvDefaultLifetime 1800; | |
| AdvHomeAgentFlag off; | |
| AdvDefaultPreference medium; | |
| AdvSourceLLAddress on; | |
| | |
| prefix 2001:a:bcd:1234::/64 | |
| { | |
| AdvValidLifetime 5400; | |
| AdvPreferredLifetime 2700; | |
| AdvOnLink on; | |
| AdvAutonomous off; | |
| AdvRouterAddr off; | |
| }; # End of prefix definition | |
| | |
| | |
| prefix fdb6:cb48:9d77::/64 | |
| { | |
| AdvValidLifetime 5400; | |
| AdvPreferredLifetime 2700; | |
| AdvOnLink on; | |
| AdvAutonomous off; | |
| AdvRouterAddr off; | |
| }; # End of prefix definition | |
| | |
| | |
| route 2001:a:bcd:1234::/64 | |
| { | |
| AdvRoutePreference medium; | |
| AdvRouteLifetime 1800; | |
| }; # End of route definition | |
| | |
| | |
| route fdb6:cb48:9d77::/64 | |
| { | |
| AdvRoutePreference medium; | |
| AdvRouteLifetime 1800; | |
| }; # End of route definition | |
| | |
| }; # End of interface definition</code> In regelmäßigen Abständen tauchen also diese RA-Meldungen auf. | |
| - Mit Hilfe von **''tcpdump''** können wir auch die RA-Meldungen mitschneiden und darstellen, in nachfolgenden Beispiel ist der Name des Netzwerkinterfaces **''enp0s25''**.<code> # tcpdump -vi enp0s25 "icmp6[icmp6type] == icmp6-routeradvert"</code><code>cpdump: listening on enp0s25, link-type EN10MB (Ethernet), snapshot length 262144 bytes | |
| 22:23:42.141271 IP6 (flowlabel 0xc155a, hlim 255, next-header ICMPv6 (58) payload length: 136) _gateway > nitropad: [icmp6 sum ok] ICMP6, router advertisement, length 136 | |
| hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms | |
| prefix info option (3), length 32 (4): 2001:a:bcd:1234::/64, Flags [onlink], valid time 5400s, pref. time 2700s | |
| prefix info option (3), length 32 (4): fdb6:cb48:9d77::/64, Flags [onlink], valid time 5400s, pref. time 2700s | |
| route info option (24), length 24 (3): 2001:a:bcd:1234::/64, pref=medium, lifetime=1800s | |
| route info option (24), length 24 (3): fdb6:cb48:9d77::/64, pref=medium, lifetime=1800s | |
| source link-address option (1), length 8 (1): 52:54:00:41:11:02 | |
| |
| ^C | ====== Links ====== |
| 1 packet captured | * **[[linux:ansible:detail|zurück zum Kapitel "Ansible - Erweiterte Konfigurationsbeispiele"]] <= ** |
| 1 packet received by filter | * **=> [[linux:dhcpd|weiter zum Kapitel "DNS Server für IPv4|6 unter Arch Linux einrichten und nutzen"]] <= ** |
| 0 packets dropped by kernel</code> | * **[[linux:start#ansible|Zurück zur "Ansible"-Übersicht]]** |
| | * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]** |
| | * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]** |
| |
django