FreeRADIUS 3.0.11 ignoriert Access-Request von einer NIC-Schnittstelle

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 Netzwerkkarten. 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 die Meldung und Antwort ordnungsgemäß erkennt. Beim Testen über das LAN erhält der FreeRADIUS-Server die Zugriffsanforderung überhaupt nicht. 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, ob 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, um HTTP und HTTPS an die virtuelle PfSense-Maschine weiterzuleiten, damit ich sie über das Admin-Netzwerk 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, ob FreeRADIUS Port 1812 überwacht.

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 der Schnittstelle auf eine andere 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 dies zum Laufen zu bringen, aber ich habe ihn noch nicht gefunden. Danke für deine Hilfe!

AKTUALISIEREN

Ich habe versucht, die Protokollierung von Anfragen zu aktivieren, indem ich die Zeile requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m%d.login der Datei auskommentiere /etc/freeradius/radiusd.conf. Dies löst jedoch einen Fehler aus und freeradius startet überhaupt nicht. Der Debugging-Modus wird gestartet, es wird jedoch nichts in die Datei radius.log geschrieben.

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

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

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

Hier ist meine erste /etc/network/interfacesDatei:

# 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

Konfiguriert die neue Routing-Tabelle:

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 :

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/en/wiki/Two_Default_Gateways_on_One_System

IPTABLES

Und um meine Portweiterleitung am Laufen zu halten, musste 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