FreeRADIUS 3.0.11 ignoriert Access-Request von einer NIC-Schnittstelle

997
Eastman

Ich habe FreeRADIUS 3.0.11 auf Ubuntu Server 16.04 installiert. Der Ubuntu-Server läuft auf einer virtuellen ESXi-Maschine. Die virtuelle Maschine verfügt über zwei NICs. Eine ist für die Verbindung mit einem Admin-Netzwerk, die andere für das Kunden-LAN. Ich verwende auch eine virtuelle PfSense-Maschine als Firewall zwischen LAN und Ubuntu-Server.

Ein Bild von meinem Netzwerk

Das Problem ist, dass der FreeRADIUS-Server beim Testen über das Admin-Netzwerk radtest test 1234 192.168.1.144 1812 testing123 ordnungsgemäß benachrichtigt und die Antworten richtig ausführt. Wenn ich jedoch vom LAN aus teste, erhält der FreeRADIUS-Server keine Zugriffsanforderung. Ich verwende den Server im Debugging-Modus freeradius -X.

Die IPs sind:

Ubuntu server admin NIC, ens160: 192.168.1.144 Ubuntu server NIC to PfSense, ens192: 192.168.34.2 PfSense NIC to Ubuntu server: 192.168.34.1 PfSense LAN NIC: 192.168.33.1

Ich habe mit tcpdump überprüft, dass der Ubuntu-Server die Access-Request-Pakete empfängt. Die IP 192.168.33.50 ist die IP eines Laptops.

sudo tcpdump -i ens192 port 1812 10:24:18.578802 IP 192.168.33.50.63334 > 192.168.34.2.radius: RADIUS, Access-Request (1), id: 0x09 length: 44 10:24:19.578202 IP 192.168.33.50.63334 > 192.168.34.2.radius: RADIUS, Access-Request (1), id: 0x09 length: 44

Ich verwende iptables zum Weiterleiten von HTTP und HTTPS an die virtuelle PfSense-Maschine, sodass ich es vom Admin-Netzwerk aus konfigurieren kann.

# Generated by iptables-save v1.6.0 on Wed May 4 10:23:08 2016 *nat :PREROUTING ACCEPT [2:396] :INPUT ACCEPT [2:396] :OUTPUT ACCEPT [3:213] :POSTROUTING ACCEPT [3:213] -A PREROUTING -i ens160 -p tcp -m tcp --dport 4954 -j DNAT --to-destination 192.168.34.1:80 -A PREROUTING -i ens160 -p tcp -m tcp --dport 4955 -j DNAT --to-destination 192.168.34.1:443 -A POSTROUTING -d 192.168.34.1/32 -p tcp -m tcp --dport 80 -j SNAT --to-source 192.168.34.2 -A POSTROUTING -d 192.168.34.1/32 -p tcp -m tcp --dport 443 -j SNAT --to-source 192.168.34.2 COMMIT # Completed on Wed May 4 10:23:08 2016 # Generated by iptables-save v1.6.0 on Wed May 4 10:23:08 2016 *filter :INPUT ACCEPT [24:2294] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [16:3245] -A INPUT -p udp -m udp -m multiport --dports 1812 -m comment --comment "Accept RADIUS" -j ACCEPT COMMIT # Completed on Wed May 4 10:23:08 2016

Ich habe überprüft, dass FreeRADIUS Port 1812 abhört.

netstat -lun | grep 1812 udp 0 0 127.0.0.1:18120 0.0.0.0:* udp 0 0 0.0.0.0:1812 0.0.0.0:* udp6 0 0 :::1812 :::*

Ich habe versucht, den Port 1812 von einer Schnittstelle zur anderen weiterzuleiten, aber entweder habe ich ihn falsch konfiguriert oder es hat nicht geholfen. Ich bin mir ziemlich sicher, dass es einen einfachen Trick gibt, um das funktionieren zu lassen, aber ich habe es noch nicht gefunden. Danke für deine Hilfe!

AKTUALISIEREN

Ich habe versucht, Requests anzumelden, indem die Zeile requests = $/radiusd-%{%:-DEFAULT}-%Y%m%d.login der Datei auskommentiert wird /etc/freeradius/radiusd.conf. Dies führt jedoch zu einem Fehler und Freeradius startet überhaupt nicht. Der Debugging-Modus wird gestartet, schreibt jedoch nichts in die Datei radius.log.

sudo freeradius radiusd: Error: Failed to parse log{} section.

Es scheint, dass die Anforderungsprotokollierung seit Version 3.0.9 nicht funktioniert. Quelle: github.com/FreeRADIUS/freeradius-server/issues/1131

0
Haben Sie die Protokolle des Hauptservers überprüft, um sicherzustellen, dass der Server das Paket mit einer erkannten Quelladresse empfängt? Arran Cudbard-Bell vor 8 Jahren 0
Was meinen Sie mit "Hauptserverprotokollen"? Eastman vor 8 Jahren 0
Das Hauptprotokoll des RADIUS-Daemons. Wie in `` / etc / raddb / radiusd.conf`` konfiguriert Arran Cudbard-Bell vor 8 Jahren 0
FreeRADIUS kann N verschiedene Protokollziele haben, globale Serverereignisse werden jedoch immer im Hauptprotokoll gespeichert. Arran Cudbard-Bell vor 8 Jahren 0
@Eastman, Bitte posten Sie Ihre Lösung als Antwort. Sie können (und sollten) Ihre eigene Frage beantworten. VL-80 vor 8 Jahren 0
Okay, ich habe die Lösung als Antwort gepostet. Irgendwie fiel mir ein, dass man ihre eigenen Fragen nicht beantworten sollte. @ ArranCudbard-Bell, vielen Dank, dass Sie versuchen zu helfen. Eastman vor 8 Jahren 0

1 Antwort auf die Frage

0
Eastman

Ich habe das Problem gelöst. Ich musste der anderen NIC auch ein Gateway hinzufügen.

Hier ist meine Ausgangsdatei /etc/network/interfaces:

# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).  source /etc/network/interfaces.d/*  # The loopback network interface auto lo iface lo inet loopback  # The primary network interface # This is an autoconfigured IPv6 interface #auto ens160 #iface ens160 inet6 auto  # ESXi NIC admin network auto ens160 iface ens160 inet static address 192.168.1.144 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.3 192.168.1.2  # ESXi NIC DMZ auto ens192 iface ens192 inet static address 192.168.34.2 netmask 255.255.255.0

Ich habe eine zweite Routing-Tabelle hinzugefügt (die letzte Zeile wird hinzugefügt):

sudo vim /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 1 rt2

Die neue Routing-Tabelle wurde konfiguriert:

sudo ip route add 192.168.34.0/24 dev ens192 src 192.168.34.2 table rt2 sudo ip route add default via 192.168.34.1 dev ens192 table rt2

Routing-Regeln hinzugefügt:

sudo ip rule add from 192.168.34.2/32 table rt2 sudo ip rule add to 192.168.34.2/32 table rt2

Getestet, dass die Konfiguration funktioniert und durch Ändern der /etc/network/interfacesDatei dauerhaft gemacht wurde :

iface ens192 inet static address 192.168.34.2 netmask 255.255.255.0 post-up ip route add 192.168.34.0/24 dev ens192 src 192.168.34.2 table rt2 post-up ip route add default via 192.168.34.1 dev ens192 table rt2 post-up ip rule add from 192.168.34.2/32 table rt2 post-up ip rule add to 192.168.34.2/32 table rt2

Die Quelle für die Lösung: https://www.thomas-krenn.com/de/wiki/Two_Default_Gateways_on_One_System

IPTABLES

Und damit meine Portweiterleitung weiter läuft, muss ich den iptables-Regeln eine ausgehende Schnittstelle hinzufügen (-o ens192 hinzugefügt):

-A POSTROUTING -d 192.168.34.1/32 -o ens192 -p tcp -m tcp --dport 80 -j SNAT --to-source 192.168.34.2 -A POSTROUTING -d 192.168.34.1/32 -o ens192 -p tcp -m tcp --dport 443 -j SNAT --to-source 192.168.34.2

Verwandte Probleme