# Iptables: wie einstellen für VLANs?

## valshare

Hallo,

folgendes Problem. Ich muss für unsere Klinik ein Internetzugang für die Patienten schaffen. Die Patientenzimmer sollen via VLAN voneinander abgeschottet werden. Sobald der Patient sein Notebook an die Internetdose anschliesst, soll eine autom. Vergabe der notwendigen DAten erfolgen. Ich habe dafür einen DHCP Server aufgesetzt der die VLANs 1 und 745 bis 749 mit IPs aus dem zugehörigen Subnetz versorgt. Die Addressvergabe an die zugehörigen VLANs läuft auch ordnungsgemäß. Der Internetzugang läuft ordnungsgemäß über die Gateways. Die Netze sind über einen VLAN-Swicht voneinander abgeschottet . Jetzt ist es allerdings so, dass der DHPC Server wohl die Netze wieder miteinander verbinden. Wie muss ich Iptables einstellen, damit die Kommunikations aus den VLANs 745 bis 749 verhindert wird und übers Internet 192.168.1.1 geroutet werden? Es soll dabei keine Einschränkungen irgendwelcher Dienste durch IPTables geben. 

Leider habe ich überhaupt keine Ahnung von IPtables. Wäre nett wenn mir einer dabei unter die Arme greifen könnte.

Der Befehl Route gibt folgendes aus

```
Ser001 / # route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.100.0   *               255.255.255.0   U     0      0        0 vlan745

192.168.101.0   *               255.255.255.0   U     0      0        0 vlan746

192.168.102.0   *               255.255.255.0   U     0      0        0 vlan747

192.168.103.0   *               255.255.255.0   U     0      0        0 vlan748

192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

192.168.1.0     *               255.255.255.0   U     0      0        0 eth1

192.168.104.0   *               255.255.255.0   U     0      0        0 vlan749

192.168.0.0     *               255.255.254.0   U     0      0        0 vlan1

loopback        *               255.0.0.0       U     0      0        0 lo

default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

```

[/code]

Die Netze haben folgende IPs´s

Internetgateway / DNS: 192.168.1.1

DHCP Server 192.168.1.11 und 192.168.100.1, 192.168.101.1, 192.168.102.1, 192.168.102.1, 192.168.103.1, 192.168.104.1

Netze:

VLAN 1: 192.168.1.0 / 255.255.255.0

VLAN745 192.168.100.0 /255.255.255.0

VLAN746 192.168.101.0 /255.255.255.0

VLAN747 192.168.102.0 /255.255.255.0

VLAN748 192.168.103.0 /255.255.255.0

VLAN749 192.168.104.0 /255.255.255.0

Gruß, Valle

----------

## think4urs11

1) Den DHCP in jedes Vlan mit reinzuhängen ist eigentlich überflüssig; i.d.R. beherrschen VLan-fähige Switches auch entsprechendes Forwarding (bei Cisco ip-helper).

Es genügt dann auf dem Server die entsprechenden Ranges zu halten.; der Server entscheidet dann anhand der GIADDR im DHCP-Request aus welchem Range er eine Lease vergeben muß.

Hätte auch den Vorteil das dein Server nicht Member in allen VLans sein muß - vorausgesetzt dein Switch kann Layer3.

2) im einfachsten Fall stellst du iptables so ein das jegliche Kommunikation von src 192.168.x.y/16 zu dst 192.168.x.y gedropt wird. Natürlich mit Ausnahme des jeweiligen default-GW.

Leider liegen deine Subnetze etwas 'schräg' (binär betrachtet) sonst könnte man die schön(er) mit einer Subnetzmaske zusammenfassen, so brauchst du auf jeden Fall min. zwei (oder eine unnötig große).

Wenn du dann (Ciscos können das z.B.) sog. private-vlans benutzt kannst du sogar noch verhindern das PC die im gleichen VLan liegen direkt miteinander reden können; in dem Fall wird jeglicher Traffic immer über das default Gateway geleitet - und dort dann verboten.

3) immer daran denken das auch 'sone wie ich' mal in deinem KH liegen könnten, da tut dann gescheite Security schon Not. Ich denke nicht das der Oberarzt begeistert wäre wenn ich ihm bei der Visite seine Gehaltsabrechnung vorlese   :Rolling Eyes: 

----------

## valshare

Hallo,

also das Netzwerk für die Patienten ist komplett vom Kliniknetzwerk abgeschottet und haben keinerlei Verbindungen zueinander. Wird also nichts mit Patientendaten oder ähnliches  :Wink: 

Es soll eigentlich nur für die Patienten dienen das die sich nicht untereinander "ausspähen" können.

Zur Verfügung steht dieser Switch http://www.netgear.de/Produkte/Switches/Smart_Rack/FS728TS/index.html (sollte halt billig sein).

In der Addressvergabe bin ich eigentlich nicht gebunden. Für jeden Port würde auch eine IP reichen und nicht ein ganzes Subnetz. Also für Vorschläge bin ich offen.

Wie müsste jetzt genau so eine IPTABLE Regel aussehen? Könntest Du mir das freundlicherweise mal an ein Muster für ein Subnetz darstellen?

Gruß, Valle

----------

## think4urs11

 *valshare wrote:*   

> also das Netzwerk für die Patienten ist komplett vom Kliniknetzwerk abgeschottet und haben keinerlei Verbindungen zueinander. Wird also nichts mit Patientendaten oder ähnliches 

 

schade aber auch   :Rolling Eyes: 

 *valshare wrote:*   

> In der Addressvergabe bin ich eigentlich nicht gebunden. Für jeden Port würde auch eine IP reichen und nicht ein ganzes Subnetz. Also für Vorschläge bin ich offen.

 

Verstehe ich jetzt nicht ganz... willst du pro Patient ein /24-Subnetz vergeben? Man kann es auch übertreiben  :Wink: 

Aber nachdem die Patienten ja nicht untereinander 'dürfen' sollen wird dir nicht viel anderes übrig bleiben -bei der gegebenen Hardware- als pro Patient ein Mininetz aufzuziehen.

Vorschlag wäre ein /30 (255.255.255.252) d.h. insgesamt je 4 Adressen, reicht für deinen Zweck vollkommen und auf Patientenseite muß nicht groß konfiguriert werden mit VPN, PPP oder sonstwas.

Die Config auf dem DHCP ist dann zwar etwas lästig wegen der vielen Ranges die der kennen muß aber einen Tod mußt du sterben.

Das einzige Problem das ich auf dich zukommen sehe ist die Maximalzahl VLans deines Switches - oder habt ihr nicht mehr als 127 Patienten?

 *valshare wrote:*   

> Wie müsste jetzt genau so eine IPTABLE Regel aussehen? Könntest Du mir das freundlicherweise mal an ein Muster für ein Subnetz darstellen?

 

im groben ungefähr so (von 192.168.100.37 -> 192.168.x.y wird alles verworfen; vorher Ausnahme fürs default-GW)

```
iptables -A FORWARD -s 192.168.100.33/30 -d 192.168.100.34 -j ALLOW

iptables -A FORWARD -s 192.168.100.33/30 -d 192.168.0.0/16 -j DROP
```

In dem Beispiel ginge das Subnetz für den Patienten von .32(Netzwerkadresse) - .35(broadcast Adresse); .33 ist der Patienten-PC und .34 sein Gateway

Schau dir auch mal das Security Handbuch Kapitel 12 an.

Und sinnvollerweise solltest du auch gleich einen Proxy mit aufsetzen. Spart erstens Bandbreite und zweitens kann man dann ggf. ganz elegant via ACL für Nachtruhe sorgen, verhindern das Patient-X auf Schweinskramseiten herumsurft und dann die armen Schwestern nervt das es unter der Decke so eng wird usw.

----------

## valshare

Ok, vielen Dank. Ich werde das morgen mal austesten.

 *Quote:*   

> Das einzige Problem das ich auf dich zukommen sehe ist die Maximalzahl VLans deines Switches - oder habt ihr nicht mehr als 127 Patienten?

 

Naja, wir werden nicht mehr als 250 Patienten haben. Wie kommst du jetzt auf 127 Patienten? Wegen dem Switch? VLAN kann doch bis zu 4096 Netze, oder? Sowviel mir bekannt ist, kann man noch Switche hinzufügen und mehr als 127 Vlans verwalten.

 *Quote:*   

> Vorschlag wäre ein /30 (255.255.255.252) d.h. insgesamt je 4 Adressen, reicht für deinen Zweck vollkommen und auf Patientenseite muß nicht groß konfiguriert werden mit VPN, PPP oder sonstwas. 

 

Sorry, also Netzwerk ist nicht mein Fachgebiet  :Wink:  Ich soll das nebenher machen und habe gute 2 Wochen Zeit gehabt sowas aufzuziehen, Server aufsetzen inbegriffen. Also die Netze wollte ich schon mit /30 eingrenzen. Irgenwie wollte das aber nicht so richtig laufen dann. Der Patient soll wie gesagt alle benötigten Daten über den DHCP bekommen. Nix mit PPP und VPN  :Wink: 

Also das mit der iptables Regel sieht ja eigentlich ganz "einfach" aus. Ich hatte mir heute mal Firewallbuilder angeschaut. Da habe ich nix mehr begriffen. Vielleicht war es auch zeitliche einfach auch schon zu spät dafür.

Achja, wenn ich die VLAN Interfaces von dem DHCP entferne, sollte das dann einfach laufen und die Request beantwortet werden? Dachte der Server muss mitglied im VLAN sein. Hatte schonmal den Server ausgeschaltet, nachdem die CLients ihre IP bekommen haben vom DHCP. Allerdings ging dann auch nicht mehr das Internet. Kann mir also nicht vorstellen das es dann noch geht.

Gruß, Valle

----------

## think4urs11

 *valshare wrote:*   

> Naja, wir werden nicht mehr als 250 Patienten haben. Wie kommst du jetzt auf 127 Patienten? Wegen dem Switch? VLAN kann doch bis zu 4096 Netze, oder? Sowviel mir bekannt ist, kann man noch Switche hinzufügen und mehr als 127 Vlans verwalten.

 

Die Aussage ist mal nur die halbe Wahrheit, da kocht jeder Hersteller ein bischen sein eigenes Süppchen. Außerdem kann der Switch den du benutzt nur 128 Vlans. Und wenn du mehrere davon koppelst (und mehr als 128 benutzen willst) verlierst du die Eindeutigkeit; das geht 100% in die Hose.

Könntest du nur verhindern indem du pro 128 VLans ein extra Beinchen am Server bereitstellst.

(Nur so nebenbei, auch die kleineren Ciscos können max. 1024 VLans)

 *valshare wrote:*   

> Sorry, also Netzwerk ist nicht mein Fachgebiet 
> 
> Ich soll das nebenher machen und habe gute 2 Wochen Zeit gehabt sowas aufzuziehen, Server aufsetzen inbegriffen.

 

Aber meines  :Wink: 

Was ich allerdings in der Beschreibung nicht gesehen habe ist ob der Switch einen Port in alle VLans gleichzeitig setzen kann. Oder hast du 802.1Q im Kernel aktiv oder wie machst du das?

 *valshare wrote:*   

> Achja, wenn ich die VLAN Interfaces von dem DHCP entferne, sollte das dann einfach laufen und die Request beantwortet werden? Dachte der Server muss mitglied im VLAN sein.

 

Da du keinen L3-fähigen Switch hast ist das auch richtig. Außer du würdest auf dem default-GW ein entsprechendes Forwarding der DHCP-Requests einrichten. Mindestens das GW muß aber so und so im jeweiligen VLan erreichbar sein, bringt also nichts.

 *valshare wrote:*   

> Hatte schonmal den Server ausgeschaltet, nachdem die CLients ihre IP bekommen haben vom DHCP. Allerdings ging dann auch nicht mehr das Internet.

 

Äh naja klar so wie ich das sehe ist der DHCP doch gleichzeitig auch das default-GW, oder? Und ohne GW geht numal nicht mehr viel.

----------

## valshare

 *Quote:*   

> Könntest du nur verhindern indem du pro 128 VLans ein extra Beinchen am Server bereitstellst. 

 

Ähhm, wie meinst Du das genau? Falls Du eine extra Netzleitungs meinst, ist das kein weiteres Problem. Müsste halt nur verlegt werden.

 *Quote:*   

> Da du keinen L3-fähigen Switch hast ist das auch richtig. Außer du würdest auf dem default-GW ein entsprechendes Forwarding der DHCP-Requests einrichten. Mindestens das GW muß aber so und so im jeweiligen VLan erreichbar sein, bringt also nichts. 

 

Ich hätte noch einen Dell PowerConnect 5324 zur Verfügung. Würde der eventuell "eleganter" für sowas sein?

http://www1.euro.dell.com/content/products/productdetails.aspx/pwcnt_5324?c=de&cs=debsdt1&l=de&s=bsd&~tab=specstab#tabtop

In der Beschreibung seht

 *Quote:*   

> Unterstützung von BootP/DHCP IP-Adressenmanagement

 

Könnte das in der Art ip-helper von Cisco sein?

 *Quote:*   

> Äh naja klar so wie ich das sehe ist der DHCP doch gleichzeitig auch das default-GW, oder? Und ohne GW geht numal nicht mehr viel.

 

Logisch, da ja die Vlan745-749 Interfaces als Gateway eingetragen sind. Naja, war schon spät.

----------

## think4urs11

 *valshare wrote:*   

> Ähhm, wie meinst Du das genau? Falls Du eine extra Netzleitungs meinst, ist das kein weiteres Problem. Müsste halt nur verlegt werden.

 

Genau das. Pro Anschluß am Server kannst du nur 128 VLans 'dahinter' auf deine diversen Switches verteilen. Wenn es mehr werden mußt du die zweite Hälfte auf eine physikalisch andere NIC am Server führen; alles andere führt garantiert ins Chaos wenn es überhaupt funktioniert.

 *valshare wrote:*   

> Ich hätte noch einen Dell PowerConnect 5324 zur Verfügung. Würde der eventuell "eleganter" für sowas sein?
> 
> http://www1.euro.dell.com/content/products/productdetails.aspx/pwcnt_5324?c=de&cs=debsdt1&l=de&s=bsd&~tab=specstab#tabtop
> 
> In der Beschreibung seht
> ...

 

Yepp, das Ding wäre besser. Damit kannst du dir die 'x' zusätzlichen IP's auf dem Server sparen und vergibst die auf dem Switch.

Der macht dann mittels DHCP-Forwarding den Rest und du muß lediglich auf dem Server genügend dhcp-scopes definieren.

----------

## valshare

Super. Du hast mir echt weitergeholfen. Jetzt nur noch ne Frage ob ich das jetzt noch alles wieder hin bekomme.

Ich glaube ich fange jetzt mal an den Server auf die einzelnen Ip Bereiche zu konfigurieren. Mit einem Subnetz müsste ich ja dan auskommen für die Patienten,oder ? Für jeden Port ein VLAN generieren und auf dem Server düften die dann auch nicht mehr zusammen geführt werden, da ich hier die VLAN Gateway weglassen kann. Also alles ins 192.168.100.x oder?

 *Quote:*   

> Oder hast du 802.1Q im Kernel aktiv oder wie machst du das? 

 

Wenn Du den Server meinst, ja da habe ich 802.1Q aktiviert.

Gruß, Valle

----------

## think4urs11

 *valshare wrote:*   

> Super. Du hast mir echt weitergeholfen. Jetzt nur noch ne Frage ob ich das jetzt noch alles wieder hin bekomme.

 

Gerne geschehen. Im Zweifelsfall einfach weiter fragen (ggf. aber neuer Thread) - wenn du irgendwo auf Kompetenz triffst dann in diesem Forum. Hier hats Gurus für fast jeden Bereich.

 *valshare wrote:*   

> Ich glaube ich fange jetzt mal an den Server auf die einzelnen Ip Bereiche zu konfigurieren. Mit einem Subnetz müsste ich ja dan auskommen für die Patienten,oder ?

 

Nein, weiterhin ein Netz pro Patient (L3-Switch hin oder her), sonst hast du weiterhin das Problem das diese untereinander 'könnten' und das willst du ja gerade verhindern; soweit ich das sehe kann der Dell kein private-VLan oder vergleichbares.

Ergo könnte Patient-A mit Patient-B reden ohne das du das auf deinem Server überhaupt mitbekommst - das Routing passiert schon im Switch und blocken kann der (soweit ich sehe) bestenfalls auf MAC-Ebene und das willst du dir nicht antun, glaubs mir  :Wink: 

 *valshare wrote:*   

> Für jeden Port ein VLAN generieren und auf dem Server düften die dann auch nicht mehr zusammen geführt werden, da ich hier die VLAN Gateway weglassen kann. Also alles ins 192.168.100.x oder?

 

Nein. Den Server packst du z.B. in 192.168.1.0/24 mit IP 192.168.1.1, die Client-Vlans vergibst du am besten gleich vorab, je eines pro Port, IP-Bereich z.B. 192.168.4-7.y; jeweils ein Mininetz /30. ab .4 deswegen weil du dann besser supernet-ten kannst sollte das mal nötig werden. Und bis -7 deswegen weil du 4x/24 brauchst wenn du 250 Mininetze a /30 machen willst  :Smile: 

Der DHCP-Server bekommt je Client-Switchport einen Scope konfiguriert, jeweils /30 und mit allen Einstellungen die du sonst brauchst - er braucht aber keine eigene IP mehr pro Vlan, das macht ja jetzt der L3-Switch.

D.h. du hast im Endausbau einen DHCP-Server mit 246 Scopes und in jedem Scope ist ein Range definiert der genau eine Adresse umfasst.

Theoretisch/alternativ kannst du auch nur einen großen Scope definieren und dann für jede IP aus dem Range eigene Einstellungen (default-GW, Netzmaske, etc) vergeben aber erstens ist das unsauber und zweitens auch nicht weniger Arbeit.

In den L3-Einstellungen auf dem Switch pro Vlan vergibst du jeweils die IP die default-GW sein soll, richtest das dhcp-forwarding zum Server ein und das wars.

Aus Clientsicht heißt das 'einstöpseln, auf DHCP stellen und geht'.

 *valshare wrote:*   

>  *Quote:*   Oder hast du 802.1Q im Kernel aktiv oder wie machst du das?  
> 
> Wenn Du den Server meinst, ja da habe ich 802.1Q aktiviert.

 

Brauchst du dann nicht mehr, da der Server (aus Switch-Sicht) auch nur ein ganz normaler PC ist.

----------

## valshare

Ok, super. Das denke ich mal habe ich soweit begriffen.

Ich hoffe hier die letzte Frage:  Brauche ich dann auf den Server also auch keine IPTABLES mehr?

Gruß, Valle

----------

## think4urs11

 *valshare wrote:*   

>  Brauche ich dann auf den Server also auch keine IPTABLES mehr?

 

Das kommt darauf an ...

sofern der Server nicht gleichzeitig auch noch z.B. das Gateway Richtung Internet ist sondern nur DHCP spielt dann nicht.

Wenn er Inet-GW ist dann ja, alleine schon wegen des nötigen Masquerading/NATing deiner internen IP-Adressen auf eine offizielle.

Wenn er Inet-GW ist _und_ zusätzlich eine zweite NIC hat die eine offizielle IP hat _und_ du darauf einen (Zwangs)Proxy fährst dann nicht - weil dann ja die eigentliche Verbindung ins Inet nicht der Client sondern der Proxy selbst aufbaut und dazu nimmt er dann seine 'externe' IP.

Letzteres heißt dann allerdings das die Patienten zwingend diesen Proxy auch konfigurieren müssen, sonst geht nix.

verwirrt genug?   :Rolling Eyes: 

----------

## valshare

Nein,

also das eigentlich Internet-Gateway ist ein Draytek Vigor3300V mit der IP 192.168.1.1. Der Server (192.168.1.11) spielt eigentlich nur DHCP. Da ich aber gerne ein Call-Log mitführen möchte, denke ich mal das ich die Patienten über den Server schleusen werde, oder?

----------

## think4urs11

 *valshare wrote:*   

> Nein,
> 
> also das eigentlich Internet-Gateway ist ein Draytek Vigor3300V mit der IP 192.168.1.1. Der Server (192.168.1.11) spielt eigentlich nur DHCP. Da ich aber gerne ein Call-Log mitführen möchte, denke ich mal das ich die Patienten über den Server schleusen werde, oder?

 

Jo.

Entweder bridging (mach ich praktisch nie) oder durch den Server durchrouten.

Wobei sich da jetzt die Frage stellt ob der Vigor auch mit Netzen auf LAN-Seiten klarkommt in denen er nicht selbst Teilnehmer ist. (192.168.4-7.x)

Wenn nein dann müßtest du auf dem Server das erste Mal natten (auf eine 192.168.1.x) und der Vigor natted dann nochmal auf seine offizielle IP.

Wie stellst du dir denn dieses Call-Log vor?

Logging über IPTables pro Paket oder 'nur' Logging auf besuchte URLs? In letzterem Fall würde sich ein Proxy zusätzlich doch empfehlen.

----------

## valshare

Ein einfach Call-Log, also nur besuchte URLS. Mehr benötige ich nicht. Ich denke ein transparency Proxy bietet sich hier an, oder? Da muss der Anwender nichts einstellen. Laufen den dann noch alle anderen Anwender die nicht extra im Router über NAT konfiguriert werden müssten?

Fragen über Fragen....

----------

## think4urs11

 *valshare wrote:*   

> Ein einfach Call-Log, also nur besuchte URLS. Mehr benötige ich nicht. Ich denke ein transparency Proxy bietet sich hier an, oder? Da muss der Anwender nichts einstellen. Laufen den dann noch alle anderen Anwender die nicht extra im Router über NAT konfiguriert werden müssten?
> 
> Fragen über Fragen....

 

Macht doch nichts, wird der Thread eben zum allgemeinen 'wie vernetze ich ein KH damit die Patienten Schweinkram kucken können und ich weiß wo'-Thread  :Wink: 

transparent proxy sollte gehen; im Prinzip ist der Unterschied zu einem 'normalen' ja nur das der Client nichts davon weiß.

Alle anderen die an deinem Server/Proxy 'vorbei' ins Internet wollen (also die Privatpatienten wie ich *fg*) brauchen dann lediglich eine IP aus 192.168.1.x, dann geht das direkt über den Vigor.

Und wenn wir schon dabei sind ich empfehle als Proxy squid und zum auswerten calamaris.

----------

## valshare

Jo, an Squid hatte ich auch soweit gedacht. Aber da gibts keine Probleme mit Anwendungen wie ICQ, E-MAIL ??

So, jetzt habe ich erst einmal genug gefragt. 

Super großen DANK nochmal! Jetzt bin ich total verwirrt    :Shocked: 

----------

## think4urs11

 *valshare wrote:*   

> Jo, an Squid hatte ich auch soweit gedacht. Aber da gibts keine Probleme mit Anwendungen wie ICQ, E-MAIL ??

 

Solange eine Anwendung voll http-proxy-tauglich ist ist das kein Problem. Messenger gehen eigentlich alle (wichtigen), Email sollte sich auch irgendwie tricksen lassen.

Es könnte nur sein das du ggf. den Proxy dann nicht transparent fahren kannst - Browser kommen damit klar aber andere Anwendungen...

Für etwas härtere Fälle kannst du ja zusätzlich noch dante als socks-proxy mit installieren.

----------

## valshare

 *Think4UrS11 wrote:*   

>  *valshare wrote:*   Jo, an Squid hatte ich auch soweit gedacht. Aber da gibts keine Probleme mit Anwendungen wie ICQ, E-MAIL ?? 
> 
> Solange eine Anwendung voll http-proxy-tauglich ist ist das kein Problem. Messenger gehen eigentlich alle (wichtigen), Email sollte sich auch irgendwie tricksen lassen.
> 
> Es könnte nur sein das du ggf. den Proxy dann nicht transparent fahren kannst - Browser kommen damit klar aber andere Anwendungen...
> ...

 

Mhh, ich glaube ich lasse das dann lieber weg mit dem Proxy. Das soll "reibungslos" für den Anwender funktionieren.

Ok, ich versuche erst den die Ersten Schritte hinzubekommen. Ich hau mich jetzt hin. Danke für den Support  :Wink: 

Gruß, Valle

----------

## slick

Irgendwie fehlt mir der Bezug zu Gentoo  :Wink: , daher verschoben nach Diskussionsforum

 *valshare wrote:*   

> Mhh, ich glaube ich lasse das dann lieber weg mit dem Proxy. Das soll "reibungslos" für den Anwender funktionieren. 

 

Wenn man den Proxy nur transparent über 80 legt sollte das kein Problem sein, im Zweifelsfall den Proxy auf einen Standardport lassen und den Nutzer nur eine "Begrüßungsseite" in die Hand geben wo die Proxybenutzung als Empfehlung steht und wo er ihn finden kann.

----------

## valshare

 *Quote:*   

> den Nutzer nur eine "Begrüßungsseite" in die Hand geben wo die Proxybenutzung als Empfehlung steht und wo er ihn finden kann.

 

Eigentlich sollten die Zugriffe mitprotokolliert werden. Damit man im Falle eines Falles auch sehen kann wer sich wo aufgehalten hat.

Früher haben wir das mit einem Draytek Vigor2500 gemacht. Der hatte eine Call-Log Funktion die auch wunderbar funktionierte. Alles ohne Proxy. Leider bietet der der "Große" Router nicht.

Gruß, Valle

----------

## slick

 *valshare wrote:*   

> Eigentlich sollten die Zugriffe mitprotokolliert werden. Damit man im Falle eines Falles auch sehen kann wer sich wo aufgehalten hat.

 

Uii... ganz dünnes Eis behaupte ich mal...  da habt ihr ja bestimmt ein Schriftstück darüber mit den Patienten oder? Ansonsten denke ich wird da jetzt sicher der Oberverdachtsschöpfer Think4UrS11 was dazu sagen können  :Wink:  Zumindest ruft das bei mir (als nicht Rechtskundiger) Datenschutzbedenken hervor, da ihr in dem Fall als Teledienstanbieter auftretet wo die Regeln ziemlich streng sind.

----------

## valshare

Also dem Anwender wird mitgeteilt, dass die Daten mitprotokolliert werden. Also es soll nur die Ziel-IP protokolliert werden mehr nicht.

Gruß, Valle

----------

## valshare

 *Quote:*   

> iptables -A FORWARD -s 192.168.100.33/30 -d 192.168.100.34 -j ALLOW

 

Kann es sein das die Regel hier nicht "Allow" sonder ACCEPT heissen muss?

Ansonsten bekomme ich die Fehlermeldung

```
iptables v1.3.5: Couldn't load target `ALLOW':/lib/iptables/libipt_ALLOW.so: cannot open shared object file: No such file or directory
```

Gruß, Valle

----------

## think4urs11

 *slick wrote:*   

> Irgendwie fehlt mir der Bezug zu Gentoo , daher verschoben nach Diskussionsforum

 

*klonk* ok Zaunpfahlwink angekommen  :Wink: 

 *valshare wrote:*   

> Mhh, ich glaube ich lasse das dann lieber weg mit dem Proxy. Das soll "reibungslos" für den Anwender funktionieren. 

 

 *slick wrote:*   

> Wenn man den Proxy nur transparent über 80 legt sollte das kein Problem sein, im Zweifelsfall den Proxy auf einen Standardport lassen und den Nutzer nur eine "Begrüßungsseite" in die Hand geben wo die Proxybenutzung als Empfehlung steht und wo er ihn finden kann.

 

Gute Idee, könnte glatt von mir sein   :Twisted Evil: 

Alles was nicht Port 3128 ist bekommt nur eine Standard-KH-Seite zu sehen (Wir freuen uns das sie hier sind blabla und natürlich einer Erklärung wie der Proxy zu setzen ist)

Irgendwo hatte ich hier mal eine Empfehlung geschrieben für einen Minimalwebserver der auf egal welche URL reagiert... 

http://www.superscript.com/shttpd/constant-httpd.html

bzw.

https://forums.gentoo.org/viewtopic-p-3411419.html#3411419

 *slick wrote:*   

>  *valshare wrote:*   Eigentlich sollten die Zugriffe mitprotokolliert werden. Damit man im Falle eines Falles auch sehen kann wer sich wo aufgehalten hat. 
> 
> Uii... ganz dünnes Eis behaupte ich mal...  da habt ihr ja bestimmt ein Schriftstück darüber mit den Patienten oder? Ansonsten denke ich wird da jetzt sicher der Oberverdachtsschöpfer Think4UrS11 was dazu sagen können  Zumindest ruft das bei mir (als nicht Rechtskundiger) Datenschutzbedenken hervor, da ihr in dem Fall als Teledienstanbieter auftretet wo die Regeln ziemlich streng sind.

 

@slick: alter Lästerer... nur weil du weißt das sie hinter mir her sind...

Jo das Thema ist ziemlich heikel - was das angeht bin ich nun wirklich paranoid (ich häng nunmal an meinem Job), sollte aber dann kein Problem mehr sein wenn $Patient beim Einchecken eine Erklärung unterschreibt in der eindeutig drinsteht das ihm

a) kostenfrei(?) ein Internetzugang während der Zeit seines 'Besuches' zur Verfügung gestellt wird

b) dieser Zugang lediglich für Webbrowsing/Emailing gedacht ist - (wobei ich Email über Webinterface nehmen würde)

c) Logdateien mitgeführt werden (um ggf. rechtsmißbräuchliche Nutzung nachweisen zu können; emule und Co z.B.)

d) diese Logs stichprobenartig (aber täglich) kontrolliert werden

e) diese Logs nach Ende des Besuches in jedem Fall gecheckt werden wg. c) und sofern nichts auffällig war gelöscht werden

f) aus Gründen des Jugendschutzes etc. ein Filter eingebaut wurde um Schweinskram/illegales zu blocken

g) ein übermäßiges Verbraten von Bandbreite (aber ich brauch *jetzt* die neue SuSE-DVD) zur Abschaltung führen kann

h) $Patient obiges verstanden hat und damit einverstanden ist das diese Daten erhoben werden (zum beiderseitigen Schutz)

mehr fällt mir auf die Schnelle nicht ein, es empfiehlt sich aber auf jeden Fall auch noch den KH-Rechtsverdreher zu fragen. Am Ende ist es der Kopf des Admins der als erstes rollt.

Ahjo - und https-connect sollte tunlichst nur auf Port 443 zugelassen werden. Hält zumindest die Scriptkiddies ein bischen auf; gegen jemand mit richtig Ahnung hast du eh so gut wie keine Chance ohne massiv Material/Personalaufwand .. ich weiß wovon ich rede, meine eigenen Firewalls im Büro halten (mich) nicht auf  :Rolling Eyes: 

zu dem Thema siehe auch https://forums.gentoo.org/viewtopic-t-362983-highlight-proxy.html

 *valshare wrote:*   

> Also dem Anwender wird mitgeteilt, dass die Daten mitprotokolliert werden. Also es soll nur die Ziel-IP protokolliert werden mehr nicht.

 

Sorry aber Ziel-IP bringt exakt gar nichts. Wie willst du da wissen auf welchen Content wirklich zugegriffen wurde?

Es gibt Hosts im Internet die hunderte wenn nicht tausende von VHosts fahren - ohne URL sagt das gar nichts aus, dann kannst du dir das auch gleich sparen.

 *valshare wrote:*   

> Kann es sein das die Regel hier nicht "Allow" sonder ACCEPT heissen muss?

 

Jetzt wo du das so sagst ... ja  :Rolling Eyes: 

----------

