Beiträge von typoworx

Ich habe mich nun einmal selbst dran probiert nach dieser Anleitung wie man eigene rc-scripte in Endian einbaut. Das ganze ist nicht wirklich ideal, da man damit in das Endian-System eingreift und "hinten herum" firewall-regeln anlegt.

https://forums.he.net/index.php?topic=2199.0

Über ein selbst erstelltes Skript mit dem Namen /var/efw/inithooks/rc.firewall.local habe ich nun probiert nach der Anleitung (mit start/stop befehl) die Firewall-Regeln anzulegen bzw. zu löschen. Die Variablen $WanIp bzw. $vmIP werden natürlich in meinem Skript entsprechend vorbelegt.

# Allow IPv6 Tunnel Protocol

iptables -A INPUT -p 41 -d $WanIp -j ACCEPT

iptables -t nat -A PREROUTING -p 41 -d $WanIp -j DNAT --to $vmIP

iptables -A FORWARD -p 41 -j ACCEPT
(optional zu testen iptables -A FORWARD -p 41 -d 91.210.226.196 -j ACCEPT)

Die entsprechenden Löschen-Befehle sind die selben, wobei "-A" durch "-D" ersetzt werden muss!

Zwischenzeitlich hat das ganze nach ein wenig gefriemel funktioniert. Nach einem Neustart von Endian wollte ich die Probe auf's Exampel machen, ob es auch nach einem Neustart mit Start des Skript auf Anhieb klappt. Hier hakt es leider - obwohl die Firewall-Regeln erneut angelegt werden (was ich überprüft habe).

Wieso das ganze nach ein wenig geteste mit Neu-Anlegen/Löschen der Regeln irgendwann plötzlich klappt ist mir ein Rätsel. VM-Seitig habe ich das Netzwerk ebenfalls ein paar mal neu gestartet bzw. probiert nur das Tunnel-Interface mit folgenden Befehlen manuell neu zu starten:

ifdown he-ipv6ip tun del he-ipv6
ifup he-ipv6

Falls jemand eine bessere Idee hat gerne her damit. So richtig funktionieren will das ganze ja noch nicht. Leider lässt sich das IPv6 Tunnel-Protokoll ("Protokoll 41") nicht direkt über Endian auswählen für Forwarding/Nat o.ä.

Moin,

da meine Frage zu nativer IPv6 Unterstützung (siehe hier: IPv6 Uplink?) sich leider vorerst erledigt hat habe ich es nun mit einem IPv6 Tunnel probiert. Betrieben wird das ganze Setup auf einem ESXi (VM Ware) Host mit Endian als NAT/Router.

Ich habe mir vor einiger Zeit bei Tunnelbroker.net einen (bislang kostenfreien) IPv6 Tunnel organisiert und als Eth-Interface auf dem VM-Gast (Linux) eingerichtet. Dies hat auch einwandfrei funktioniert - solange ich eine der Public-IPs direkt auf dem VM-Gast konfiguriert hatte. Aus praktikablen gründen und da es kompliziert wurde mit mehreren Gateway/Routes (Public IP vs. Endian GW mit 2 Subnetzen) habe ich nun die Public-IP ebenfalls auf Endian umkonfiguriert mit Port-Forwarding für die notwendigen Dienste.

Leider habe ich nunmehr festgestellt, dass der bislang einwandfrei funktionierende IPv6 Tunnel hierbei leider auf der Strecke liegen bleibt, da dieser keine Verbindung mehr bekommt.

/etc/network/interfaces.d/he-ipv6-tunnel

# IPv6 over IPv4 Tunnel
# https://tunnelbroker.net/
#
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:470:xxx:xxx::2   <--- meine IPv6 Adresse über Tunnelbroker
netmask 64
endpoint 216.66.86.xxx           <-- Tunnelbroker IPv6 GW (hier ist ebenfalls meine "local IP" hinterlegt als Endpunkt)
local xxx.xxx.xxx.xxx                <--- hier steht meine (bis dato direkt im System eingebundene) public-ip
ttl 255
gateway 2001:470:xxxx:xxx::1

Ich habe nun gedacht es würde reichen ein Protokoll oder einen Port in Endian per Forwarding auf die Gast-VM zu aktivieren, damit der Tunnel wieder funktioniert. Leider scheint das ganze aber nun doch nicht so trivial zu sein.

Belesen habe ich mich u.a. hier dazu:
https://www.endpoint.com/blog/2012/03/0…anubuntu-behind

Zitat

If you’re router supports configuration of forwarding more than just TCP/UDP, you’ll want to forward protocol 41 (aka IPv6) (NOT PORT 41), which is responsible for IPv6 tunneling over IPv4, to your static address.

Soweit so gut. Leider finde ich aber keine Möglichkeit dieses Protokoll in Endian für Forwarding einzurichten?! Weiß da jemand Rat?

Ich habe leider auch in der Enterprise nichts dazu gesehen. Es soll wohl inoffiziell gehen, indem man dies SSH-seitig selbst einbaut mit dem RPM Paket "radvd" über CentOS sources (siehe: https://blog.dataforce.org.uk/2012/02/ipv6-w…wall-efw-2-4-0/) . Bin aber eigentlich nicht wirklich ein Freund von solchen Lösungen bei einer hardened Software wie Endian - zumal die Anleitung etwas älter ist und unklar ist auf welcher Fedora Version (wenn überhaupt noch?) Endian in der 3.3.0 Version aufbaut. Das Release-Tag von Endian verrät hier nichts.

Da IPv6 inzwischen leider immer häufiger (bzw. irgendwann komplett) interessanter wird überlege ich mich nun von Endian zu trennen und eine alternative zu suchen. Ist vielleicht eine blöde Frage in diesem Forum aber kennt jemand eine gute alternative zu Endian die nativ mit IPv6 klar kommt?

Lieber wäre es mir natürlich Endian würde das endlich unterstützen - aber es gibt hier wohl auch noch einige sicherheitsrelevante Dinge bei IPv6, welche wohl eine Rolle spielen. Nichts desto trotz finde ich man sollte den Admin welche die Software nutzen diese Entscheidung überlassen, ob Sie den IPv6 Stack (ggf. Hinweis zu Sicherheitsrisiken) nutzen wollen oder eben nicht (Wink an die Endian Entwickler).

Moin,

ich weiß das Endian "offiziell" wohl leider immer noch kein IPv6 unterstützt. Weiß jemand ob das irgendwie möglich ist? Ich habe inzwischen ein paar VM/Dienste für die IPv6 sinnvoll wäre und habe inzwischen um Probleme zu vermeiden alle Uplink-IP in meinem ESXi Server der Endian-VM zugewiesen, um dann per NAT meine ESXi-VM mit Internet / Port-Forwarding anzubinden.

Wäre es alternativ für nur ausgehenden Traffik möglich/sinnvoll einen IPv6 Tunnel zu verwenden direkt in der VM (siehe: https://www.techgrube.de/tutorials/ipv6-tunneling) oder ist das eher nur für Desktop-Einsatz gedacht/sinnvoll?

Ja da hast du wohl recht.. ich dachte irgendwie es reicht wenn das GW mit der Metrik für das Green-Network (172.16.0.0/16) als Route drin ist... so kann man sich irren

Ist im Endeffekt aber zum Glück egal über welches GW der Default-Traffic raus geht. Passt nun also so. Danke!

Ui... Sabine nicht zu fassen... die Antwort war wohl zu voreilig... nun klappt es plötzlich

Es lag tatsächlich daran, dass Endian nicht das Default-GW war. Ich hatte es zwar als GW drin aber nachrangig.

Vielen Dank für den Tipp!

Zitat von Sabine

Ist auf dem Rechner auf den du willst die Interne IP der Endian als Standard Gateway eingetragen ?

Hi,

da könntest du fast recht haben mit ... denn auf der VM sind noch zwei eigene Public-IP direkt ins System eingebunden. Das Standard GW war auf eine der direkt eingebundenen Public-IP gesetzt. Ich habe nun die Endian-IP als GW gesetzt.

Alles läuft wieder... nur das Port-Forwarding immer noch nicht ...

> Ich werde wirklich mal probieren Endian nachher neu zu starten.

Hat leider nichts gebracht ... nach wie vor das selbe.

Hi,

danke für deine Rückinfo. Gut zu wissen das du im Bilde bist. Dann muss ich da ja zum Glück nicht so weit ausholen

Das mit einem anderen Dienst habe ich tatsächlich schon gemacht mit einem simplen Bash-Skript 'test-tcp-serve.sh'

#/bin/bash
declare -i port=$1;

if [[ -z "$port" || "$port" -eq 0 ]];
then
  echo "Syntax: $(basename $0) [tcp-port] to serve";
  exit 1
fi

echo "Listening on TCP:${port}";
while true; do ( echo "HTTP/1.0 200 Ok"; echo; echo "TEST TASK" ) | nc -l ${port}; done

und aufruf auf der Ziel-VM mittels ./test-tcp-serve.sh 1234 und test, ob der TCP-Port aktiv ist:

$> lsof -i TCP:1234
COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
nc      17378 root    3u  IPv4 2887215      0t0  TCP *:1234 (LISTEN)

Aufruf von meinem Rechner via VPN auf die interne IP 172.16.0.23 port 1234 klappt einwandfrei!

Zitat

$ nc -vz 172.16.0.23 1234

Connection to 172.16.0.23 1234 port [tcp/*] succeeded!

Mit der Public-IP von Endian auf Port 1234 und aktiver Port-Weiterleitung hängt das ganze dann erst mal ne Weile bis zum Timeout ... egal ob mit oder ohne aktivierter UFW-Firewall auf der Ziel-VM.

Ich versteh's auch nicht. Das ganze soll natürlich eigentlich für einen anderen Dienst/Port sein...da ist es das selbe.

Ich werde wirklich mal probieren Endian nachher neu zu starten.

Hallo Sabine,

danke erst mal für deine Hilfe und Rückinfo. Mir ist klar, dass das ganze Setup sicherlich schwer zu überschauen ist. Ich hatte gehofft, dass sich hier andere VMware Nutzer finden, die evtl. Abhilfe wissen.

Zitat von Sabine

Ich weiß nicht genau was du damit meinst ?

Ich nutze Endian normalerweise vorwiegend innerhalb von VMware als Router für Virtual-Machines, die sonst keine eigene Public-IP zugewiesen haben und Internet Zugriff haben sollen über das interne Green-Network und Endian.

Ergänzend noch als Hinweis:
An die Endian Virtual-Machine habe ich zwei VM-Netzwerk-Adapter angeschlossen: Eines für die Public-IP (=Internet physikalische Netzwerkkarte "nach draußen") und der zweite Adapter ist nur ein VSwitch der unabhängig agiert (=keine phys. Netzwerkkarte angeschlossen). Bei letzterem habe ich in VMware ESXi den Promiscious-Mode aktiviert.

Ich kann sowohl von der Endian VM als auch den angeschlossenen VMs im "Endian Netzwerk" der virtualisierten Umgebungen jeweils Endian bzw. die einzelnen VM im Green-Network anpingen und darauf zugreifen.

Wie schon erwähnt nutze ich mit Endian auch das OpenVPN und kann von dort aus ebenfalls auf das Green-Network zugreifen und von dort auch auf den Dienst zugreifen, mit dem das Port-Forwarding über die Endian Public-IP nicht funktioniert.

Das meinte ich mit "ist intakt". Es sind sonst keine anderen Probleme mit dem Setup bekannt - bis auf das mit dem Port-Forwarding, dass irgendwo verschluckt wird.

Hallo Sabine,

danke für das Feedback. Der Meinung bin ich eigentlich auch ...

Das Ziel ist in meinem Fall von der Endian-VM (VMware ESXi) eine andere ESXi VM im selben VLAN/Netz. Das Netzwerk zwischen der Endian-VM und der Ziel-VM im Green-Net ist intakt. Via VPN kann ich auch direkt auf die Green-IP der VM auf den Port zugreifen.

Die UFW-Firewall in der Ziel-VM habe ich ebenfalls schon testweise deaktiviert (obwohl das Subnetz dort white-listed ist).

Anbei noch mein IP-Tables (nach deaktivierter UFW-Firewall)
$> iptable -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ufw-before-logging-input  all  --  anywhere             anywhere
ufw-before-input  all  --  anywhere             anywhere
ufw-after-input  all  --  anywhere             anywhere
ufw-after-logging-input  all  --  anywhere             anywhere
ufw-reject-input  all  --  anywhere             anywhere
ufw-track-input  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ufw-before-logging-forward  all  --  anywhere             anywhere
ufw-before-forward  all  --  anywhere             anywhere
ufw-after-forward  all  --  anywhere             anywhere
ufw-after-logging-forward  all  --  anywhere             anywhere
ufw-reject-forward  all  --  anywhere             anywhere
ufw-track-forward  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ufw-before-logging-output  all  --  anywhere             anywhere
ufw-before-output  all  --  anywhere             anywhere
ufw-after-output  all  --  anywhere             anywhere
ufw-after-logging-output  all  --  anywhere             anywhere
ufw-reject-output  all  --  anywhere             anywhere
ufw-track-output  all  --  anywhere             anywhere

Chain ufw-after-forward (1 references)
target     prot opt source               destination

Chain ufw-after-input (1 references)
target     prot opt source               destination

Chain ufw-after-logging-forward (1 references)
target     prot opt source               destination

Chain ufw-after-logging-input (1 references)
target     prot opt source               destination

Chain ufw-after-logging-output (1 references)
target     prot opt source               destination

Chain ufw-after-output (1 references)
target     prot opt source               destination

Chain ufw-before-forward (1 references)
target     prot opt source               destination

Chain ufw-before-input (1 references)
target     prot opt source               destination

Chain ufw-before-logging-forward (1 references)
target     prot opt source               destination

Chain ufw-before-logging-input (1 references)
target     prot opt source               destination

Chain ufw-before-logging-output (1 references)
target     prot opt source               destination

Chain ufw-before-output (1 references)
target     prot opt source               destination

Chain ufw-reject-forward (1 references)
target     prot opt source               destination

Chain ufw-reject-input (1 references)
target     prot opt source               destination

Chain ufw-reject-output (1 references)
target     prot opt source               destination

Chain ufw-track-forward (1 references)
target     prot opt source               destination

Chain ufw-track-input (1 references)
target     prot opt source               destination

Chain ufw-track-output (1 references)
target     prot opt source               destination

Ich weiß langsam nicht mehr wo es hier noch haken soll - oder übersehe ich da irgendwas?

Vg
Gabriel

Moin,

ich versuche seit Stunden ein eigentlich banales Port-Forwarding einzurichten. Bei mir läuft Endian in einer ESXi Umgebung mit derzeit einer public-ip/uplink (=RED Network). Zusätzlich habe ich ein VM-Netzwerk Interface als Green-Network eingebunden. Im VM-Net bzw. VSwitch ist der Promiscious-Mode aktiviert. Für das klassische Routing (Internet Zugriff innerhalb VMs im Green-Network) klappt das einwandfrei.

Da beim Endian ansonsten außer für Internet/NAT keine Dienste laufen würde ich gerne ein paar TCP-Ports auf VM im Green-Network weiterleiten. Hierzu habe ich unter DNat eine Regel erstellt:

Eingehende IP

Typ: Zone/VPN/Uplink
Uplink main - IP: 123.123.123.100 (exemplarisch Internet Public IP)

Dienst: Benutzerdefiniert, TCP, Port 1234

Übersetze zu IP/Port

172.16.0.23 / 1234 per NAT (kein NAT auch getestet)

Gestattet von ALLE IPs

und natürlich habe ich die Regel auch aktiviert.

Ich bekomme aber von außen keinen Zugriff über die Public-IP auf den Port! Per OpenVPN mit Zugriff auf das Green-Network kann ich über 172.16.0.23:1234 auf den Dienst zugreifen.

Über 123.123.123.100 (Internet IP) und Port 1234 erhalte ich keinen Zugriff:

$> nc -vz 123.123.123.100 1234

nc: connect to 123.123.123.100 port 1234 (tcp) failed: Connection timed out

In der Endian-Firewall taucht im Log dieser Eintrag auf, nachdem ich Logging aktiviert habe in der DNat-Regel:

PORTFWACCESS:ALLOW:2 TCP (eth1) 92.76.101.92:57390 -> 172.16.0.23:1234 (br0)

Ich verstehe nicht wieso das Port-Forwarding nicht richtig klappt?