[linux-l] Perl, Tomcat, IPSec, NFS, Linux, FreeBSD (war:Woody-nachbesserungs-Tool

[Steffen Dettmer]

* Peter Ross wrote on Mon, Dec 30, 2002 at 22:07 +1100:
> > Du meinst mit dem Tool Perl?
> 
> Ja. Wenn ich das immer dabei haben muss, ist eine Miniinstallation nicht 
> mehr so mini.

Yep, und wenn man das für bootscripte verwenden würde, könnte man
perl nichtmal nach /usr schmeißen und bräuchte das immer. Wäre
bißchen sehr oversized, ja.

> > Ahh, Du hast also insgesammt vier SAs zu zwei Netzen. Oft hat man
> > auch mehr als zwei SAs je Netzwerk (wenn man die GWs selbst auch
> > gesichert ansprechen möchte).
> > 
> > Wieso nicht glücklich? Hättest Du lieber 4 Devices? Die devices
> > sind analog zu phyiskalischen Devices. Sehe hier keinen Nachteil.
> > Hättest Du lieber vier devices?!
> 
> Ja, haette ich gern. Warum soll ich zwei vollstaendig
> verschiedene Verbindungen ueber das gleiche Interface jagen?

Du jagst ja auch Millionen von TCP Verbindungen über ein device.
Verstehe Deine Anforderung überhaupt nicht.

> Das ifconfig fuer ipsec0 erzaehlt eigentlich nur Unsinn.

Es sollte Dir die assozierte "physikalische" IP Addresse angeben,
über die man das Device zu dem physikalischen Device zu ordnen
kann. Das ist leider nicht immer glücklich; z.B. kann ich ja
ippp0 und ippp1 mit gleicher lokaler IP und verschiedener peer-IP
verwenden. In solchen Setups kann man FreeS/WAN leider nicht
konfigurieren (zumindestens nicht so einfach).

> Daher auch, das ich fuers Gateway selbst eine andere Verbindung
> brauche (oder Pakete mit iptables umschaufele)

Das ist ja logisch. Das SA paßt nicht für das Gateway selbst.
Aber man kann ja mehr als zwei SAs haben. Wenn man die Gateways
und alle Kombinationen mit IPSec sichern möchte, braucht man eben
8 SAs (Neta-netb; gwa-netb; gwa-gwb; gdb-neta und die
Rückrichtungen).

> Mir erscheint der Weg, je Verbindung ein neues virtuelles
> Device aufzumachen, ordentlich zu konfigurieren und drueber
> routen, sinnvoller. 

Warum? SAs werden ja automatisch erneuert (bei auto keying zu
mindestens), weil sich die kryptoparameter ja ändern (um attacken
zu erschweren, klar). Sollte da jedesmal ein neues device kommen?
Du möchtest dann mit ipsec10201 arbeiten? Was soll die Firewall
denn da machen, ständig neue Regeln erzeugen? Dann kannste ja
doch wieder nur ipsec* verwenden, und dann haste totales
Kuddelmuddel.

> IPSec und Verschluesselungen erlauben etc. mache ich natuerlich
> ueber das echte Device, das ist okay.

Ja, klar. Über ipsec kannste dann noch den Klartext-Datenstrom
filtern, so, wie er wäre, gäbe es kein ipsec. Das ist praktisch,
da muß man nur die entsprechenden eth0 Regeln auf ipsec0 ändern
:) Ich finde das komfortabel, logisch und recht konsistent (bis
auf die assoziation über IPs, siehe oben).

> > Ich find, daß macht sich jedenfalls prima, auch das filtern.
> 
> Wenn ja Verbindung ein Interface da ist, dann geht "Verbindung1
> darf alles" und "Verbindung2 darf nur auf Firmen-Webserver
> zugreifen" vile einfacher.

?! Das geht ohne IPSec ja auch schon nicht... Außerdem weißt Du
ja, welche Netzwerke über IPSec reinkommen können (wird ja
konfiguriert). Das kann 0/0 sein, oder auch was genaues. Und da
kannst Du filtern. Wie im allgemeinen kannst Du den Paketfilter
natürlich nicht dazu benutzen, Appilkationslevel Informationen
auszuwerten (z.B. nur remote User "steffen" darf auf port 22;
oder: "nur IPSec SA mit dem Zertifikat darf port 80" oder sowas,
klar, das Netzwork layer weiß ja nix davon).

> > Na ja, auch interoperabel? Vielleicht ist mein linux NFS Server
> > zu buggy ;) Hilft mir dann aber auch nix :)
> 
> Es gibt kein flock(2) bei Linux ueber NFS.

ja... Hab da mal was gelesen. Das hatte sogar irgendeinen Grund,
IIRC.

> So war Sun deutlich im Vorteil, Filelocking uebers Netz zu
> implementieren: 

Klar. Nicht sehr schnell, nicht sehr sicher, aber geht.
Vermutlich war selbst SUN über den Erfolg von NFS überrascht.
Eigentlich mag es niemand, aber man kommt kaum drum rum.

> Den Punkt solltest Du zumindest mal durchdenken und wenn noetig testen, 
> bevor Du da in die Falle rennst.

Yep, müßte man machen. Mit NFS gab es immer mal wieder
interessante interop Probleme; auch SGI-SUN und Linux-irgendwas
(irgendwas schließt linux selbst auch ein ;)), na ja, schon
merkwürdig, jahrealt der Kram, aber immer noch nicht wirklich
gelöst. Ein Mist ist das.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.