FreeBSD+pptp->VPN
Christian Lackas
ich möchte über mein FreeBSD (4.7-STABLE) gerne auf das RWTH-VPN
zugreifen. Den VPN-Client von Cisco kann ich ja nicht verwenden und
AFAIK gibt es auch keine andere Alternative, die das gleiche macht wie
das Cisco-Tool (bin aber für Vorschläge offen :-).
Aber in der FAQ steht ja:
5. Gibt es eine Fallback-Lösung?
Ja, PPTP + PAP sind als Fallback aktiviert.
Das pptp sollte in diesem Fall so eingerichtet werden, dass
keinerlei Verschlüsselung benötigt wird. An die Benutzerkennung muss
noch @MoPS angehängt werden.
Das ließ mich ja wieder hoffen und ich habe es mit pptp probiert. Ich
verwende pptpclient 1.1.0 aus den FreeBSD-Ports.
/etc/ppp/ppp.conf:
pptp:
set authname user@MoPS
set authkey ****
set timeout 0
set log Phase Chat LCP IPCP CCP tun command
set ifaddr 10.0.0.3/0 10.0.0.4/0 0.0.0.0 0.0.0.0
add default HISADDR
Und dann starte ich das Programm per
pptp vpnhost pptp
Aber leider beendet er sich einfach nur nach etwa einer Minute und
verbunden hat sich da nichts. Hat einer von euch das schonmal
hinbekommen oder hat sonstwie eine Idee?
Hier meine ppp.log:
Phase: Using interface: tun1
Phase: deflink: Created in closed state
tun1: Command: pptp: set ifaddr 10.0.0.3/0 10.0.0.4/0 0.0.0.0 0.0.0.0
tun1: Command: pptp: add default HISADDR
tun1: Phase: PPP Started (direct mode).
tun1: Phase: bundle: Establish
tun1: Phase: deflink: closed -> opening
tun1: Phase: deflink: Connected!
tun1: Phase: deflink: opening -> carrier
tun1: Phase: deflink: carrier -> lcp
tun1: LCP: FSM: Using "deflink" as a transport
tun1: LCP: deflink: State change Initial --> Closed
tun1: LCP: deflink: State change Closed --> Stopped
tun1: LCP: deflink: LayerStart
tun1: LCP: deflink: SendConfigReq(1) state = Stopped
tun1: LCP: MRU[4] 1492
tun1: LCP: MAGICNUM[6] 0xdbdf805c
tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05)
tun1: LCP: deflink: State change Stopped --> Req-Sent
3x folgender Abschnitt:
| tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent
| tun1: LCP: MRU[4] 1492
| tun1: LCP: MAGICNUM[6] 0xdbdf805c
| tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05)
tun1: LCP: deflink: LayerFinish
tun1: LCP: deflink: State change Req-Sent --> Stopped
tun1: LCP: deflink: State change Stopped --> Closed
tun1: LCP: deflink: State change Closed --> Initial
tun1: Phase: deflink: Disconnected!
tun1: Phase: deflink: Connect time: 16 secs: 127 octets in, 115 octets out
tun1: Phase: deflink: 5 packets in, 5 packets out
tun1: Phase: total 15 bytes/sec, peak 19 bytes/sec on Fri Jan 24 01:31:15 2003
tun1: Phase: deflink: lcp -> closed
tun1: Phase: bundle: Dead
tun1: Phase: PPP Terminated (normal).
Ich habe mir auch mal per tcpdump den Verkehr angesehen und es werden
wohl auch Daten ausgetauscht, aber irgendwie scheint das auf meiner
Seite wohl mit der Authentifizierung per CHAP nicht zu funktionieren.
Wenn ich das richtig verstehe, dann fordert der Server CHAP, aber mein
Client liefert das nicht. Oder will er mir so mitteilen, dass meine
Auth-Daten nicht gültig sind?
Auszug aus dem tcpdump-File:
vpnhost.pptp > myhost.4889: P 157:189(32) ack 325 win 8192
<nop,nop,timestamp 8720436 1562531432>: pptp CTRL_MSGTYPE=OCRP
CALL_ID(45244) PEER_CALL_ID(0) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0)
CONN_SPEED(10000000) RECV_WIN(16) PROC_DELAY(1) PHY_CHAN_ID(0)
vpnhost > myhost: gre [KSv1] ID:0000 S:1 ppp: Conf-Req(0), Auth-Prot CHAP/MD5
myhost.4889 > vpnhost.pptp: . ack 189 win 57600 <nop,nop,timestamp
1562531611 8720436> (DF)
vpnhost > myhost: gre [KSv1] ID:0000 S:2 ppp: Conf-Req(1), Auth-Prot CHAP/MD5
myhost > vpnhost: gre [KAv1] ID:b0bc A:2 [|gre]
vpnhost > myhost: gre [KSv1] ID:0000 S:3 ppp: Conf-Req(2), Auth-Prot CHAP/MD5
myhost > vpnhost: gre [KAv1] ID:b0bc A:3 [|gre]
vpnhost > myhost: gre [KSv1] ID:0000 S:4 ppp: Conf-Req(3), Auth-Prot CHAP/MD5
myhost > vpnhost: gre [KAv1] ID:b0bc A:4 [|gre]
vpnhost > myhost: gre [KSv1] ID:0000 S:5 ppp: Conf-Req(4), Auth-Prot CHAP/MD5
myhost > vpnhost: gre [KAv1] ID:b0bc A:5 [|gre]
vpnhost > myhost: gre [KSv1] ID:0000 S:6 ppp: Conf-Req(5), Auth-Prot CHAP/MD5
myhost > vpnhost: gre [KAv1] ID:b0bc A:6 [|gre]
myhost.4889 > vpnhost.pptp: P 325:341(16) ack 189 win 57600
<nop,nop,timestamp 1562547664 8720436>: pptp CTRL_MSGTYPE=CCRQ
CALL_ID(0) (DF)
vpnhost.pptp > myhost.4889: P 189:337(148) ack 341 win 8192
<nop,nop,timestamp 8720469 1562547664>: pptp CTRL_MSGTYPE=CDN
CALL_ID(45244) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) [|pptp]
myhost.4889 > vpnhost.pptp: P 341:373(32) ack 337 win 57452
<nop,nop,timestamp 1562547743 8720469>: pptp CTRL_MSGTYPE=CCRQ
CALL_ID(0) (DF)
vpnhost.pptp > myhost.4889: . ack 373 win 8192 <nop,nop,timestamp
8720469 1562547743>
myhost.4889 > vpnhost.pptp: F 373:373(0) ack 337 win 57600
<nop,nop,timestamp 1562549666 8720469> (DF)
vpnhost.pptp > myhost.4889: . ack 374 win 8192 <nop,nop,timestamp
8720473 1562549666>
vpnhost.pptp > myhost.4889: F 337:337(0) ack 374 win 8192
<nop,nop,timestamp 8720473 1562549666>
myhost.4889 > vpnhost.pptp: . ack 338 win 57600 <nop,nop,timestamp
1562549742 8720473> (DF)
Kann mir einer von euch einen Tipp geben? "enable/accept chap" sind
alles was sich zu dem Thema ppp/chap gefunden habe. Aber das
funktioniert auch nicht.
Gruss
Christian
--
Fühlen Sie sich wie zu Hause - aber benehmen Sie sich nicht so.
http://www.lackas.net/ Perl Delphi Linux MP3 Searchengines Domainchecker
Thomas Boettcher
Christian Lackas wrote:
> Hallo Leute,
>
> ich möchte über mein FreeBSD (4.7-STABLE) gerne auf das RWTH-VPN
> zugreifen. Den VPN-Client von Cisco kann ich ja nicht verwenden und
> AFAIK gibt es auch keine andere Alternative, die das gleiche macht wie
> das Cisco-Tool (bin aber für Vorschläge offen :-).
>
> Aber in der FAQ steht ja:
>
> 5. Gibt es eine Fallback-Lösung?
> Ja, PPTP + PAP sind als Fallback aktiviert.
> Das pptp sollte in diesem Fall so eingerichtet werden, dass
> keinerlei Verschlüsselung benötigt wird. An die Benutzerkennung muss
> noch @MoPS angehängt werden.
>
> [...]
>
> Kann mir einer von euch einen Tipp geben? "enable/accept chap" sind
> alles was sich zu dem Thema ppp/chap gefunden habe. Aber das
> funktioniert auch nicht.
der cisco tunnelserver hat bislang faelschlicherweise CHAP verbindungen
akzeptiert, wird dabei allerdings keine verbindung erzeugen, da die
authentifizierungsinstanz dies nicht unterstuetzt. das ist nun behoben.
wie schon oben steht muss deine verbindung auf PAP aufgebaut sein. evtl
liegt dort dein fehler.
tomtom
--
++ Thomas Boettcher Computing and Communication Center ++
++ office: 2.35 University of Technology Aachen ++
++ phone: +49 (241) 80-29205 Seffenter Weg 23 ++
++ mailto:boet...@rz.rwth-aachen.de 52074 Aachen, Germany ++
Christian Lackas
Hallo Thomas, Volker,
> der cisco tunnelserver hat bislang faelschlicherweise CHAP
> verbindungen akzeptiert, wird dabei allerdings keine verbindung
> erzeugen, da die authentifizierungsinstanz dies nicht unterstuetzt.
> das ist nun behoben.
das war doch schonmal ein Hinweis. Ich bin einfach mal davon
ausgegangen, dass das mit dem PAP in der FAQ nicht so ernst gemeint war
(wenn der Server auch CHAP akzeptiert). Aber ich hatte es auch mal mit
PAP ausprobiert: gleiches Ergebnis.
Mir war pptp(1) dann aber auch zu sehr eine Blackbox und ich habe es
inzwischen mit mpd (auch in den FreeBSD Ports) zum laufen gebracht.
Für die Leute die daran Interesse haben hier eine (bei mir)
funktionierende Konfiguration:
mpd.conf
default:
load vpn
vpn:
new -i ng0 vpn vpn
set iface disable on-demand
set iface addrs 192.168.1.1 192.168.2.2
set iface idle 0
set iface route 134.130.0.0/16
set iface route 137.226.0.0/16
set bundle disable multilink
set bundle authname cl314159@MoPS
set bundle password noJZs3Xc
set link no acfcomp protocomp
set link accept pap
set ipcp no vjcomp
open
mpd.links
vpn:
set link type pptp
set pptp self 10.0.0.1
set pptp peer 137.226.144.220
set pptp enable originate incoming outcall
Und mein rc-Skript:
#! /bin/sh
case $1 in
start)
[ -x /usr/local/sbin/mpd ] && \
/usr/local/sbin/mpd -b vpn && \
echo -n ' vpn'
;;
stop)
killall -HUP mpd && \
echo -n ' vpn'
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
exit 64
;;
esac
exit 0
Nach »/usr/local/etc/rc.d/vpn.sh start« habe ich dann auch (endlich)
transparenten Zugriff auf die Dienste der TH.
Gruss
Christian
--
Man umgebe uns mit Luxus, auf das Notwendigste können wir verzichten.
Tassilo v. Parseval
> Für die Leute die daran Interesse haben hier eine (bei mir)
> funktionierende Konfiguration:
>
> mpd.conf
> default:
> load vpn
>
> vpn:
> new -i ng0 vpn vpn
> set iface disable on-demand
> set iface addrs 192.168.1.1 192.168.2.2
> set iface idle 0
> set iface route 134.130.0.0/16
> set iface route 137.226.0.0/16
> set bundle disable multilink
> set bundle authname cl314159@MoPS
> set bundle password noJZs3Xc
Sag mal, hast Du hier gerade Deine tatsächlichen Zugangsdaten in die
Welt herausposaunt?
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
Christian Lackas
Hallo Tassilo,
>> set bundle authname cl314159@MoPS
>> set bundle password noJZs3Xc
> Sag mal, hast Du hier gerade Deine tatsächlichen Zugangsdaten in die
> Welt herausposaunt?
nein, nur realistische Daten.
Gruss
Christian
--
Wir sind jetzt die, mit denen wir früher nicht spielen durften.
Hauke Heidtmann
> Also sprach Christian Lackas:
[config]
> Sag mal, hast Du hier gerade Deine tatsächlichen Zugangsdaten in die
> Welt herausposaunt?
Ja, das sieht gut aus :)
Hauke
--
"Die Nummer, die Sie gewählt haben, ist imaginär.
Bitte drehen Sie Ihr Telefon um 90 Grad und probieren Sie es erneut!"
Markus Brueffer
> Mir war pptp(1) dann aber auch zu sehr eine Blackbox und ich habe es
> inzwischen mit mpd (auch in den FreeBSD Ports) zum laufen gebracht.
>
> Für die Leute die daran Interesse haben hier eine (bei mir)
> funktionierende Konfiguration:
pptp konnte ich bei mir auch nicht zum laufen bewegen. Mit mpd und deiner
Config dann aber auf Anhieb funktioniert.
Thx a lot!
Gruß
Markus
Tassilo v. Parseval
> Tassilo v. Parseval schrieb:
>
>> Sag mal, hast Du hier gerade Deine tatsächlichen Zugangsdaten in die
>> Welt herausposaunt?
>
> cl314159 ... 3,14159 sagt dir aber schon noch etwas, oder? ]:->
Einigermaßen, ja. :-) Ich sah eben hauptsächlich das cl am Anfang, daß
gut auf seinen Namen zu passen schien.
Christoph Kukulies
> Tassilo v. Parseval schrieb:
>> Sag mal, hast Du hier gerade Deine tatsächlichen Zugangsdaten in die
>> Welt herausposaunt?
> cl314159 ... 3,14159 sagt dir aber schon noch etwas, oder? ]:->
Und das Passwort ist doch auch ganz nett (hint: 3 gehoert zum Hackeralphabeth)
Kann uebrigens auch gerade Erfolg melden von meinem FreeBSD 4.x System
zuhause durch vpn tunnel. Hatte noch das @MoPS vergessen, aber dann gings
sofort.
Meine Frage jetzt nur:
Ich erscheine als 0-007.vpn.rwth-aachen.de. Welche Dienste kann ich jetzt
nutzen?
--
Chris Christoph P. U. Kukulies kuku...@rwth-aachen.de
Jens Hektor
> Ich erscheine als 0-007.vpn.rwth-aachen.de. Welche Dienste kann ich jetzt
> nutzen?
Alles ausser:
http://www.rz.rwth-aachen.de/kommunikation/info/blocked.html
<off>immer diese newbies;-)</off>
Christoph Kukulies
> Alles ausser:
> http://www.rz.rwth-aachen.de/kommunikation/info/blocked.html
Was bedeutet in jener Liste die Bemerkung "Nur zu Servern der RWTH"?
--
Chris Christoph P. U. Kukulies new...@rwth-aachen.de
Jens Hektor
> Was bedeutet in jener Liste die Bemerkung "Nur zu Servern der RWTH"?
s/zu/zu angemeldeten/
--
Jens Hektor, RWTH Aachen, Rechenzentrum, Seffenter Weg 23, 52074 Aachen
Computing Center, Aachen University, network operation & security
mailto:hek...@RZ.RWTH-Aachen.DE, Tel.: +49 241 80 29206, Raum: 2.35
Dominik Schlütter
Jens Hektor <hek...@rz.rwth-aachen.de> schrieb:
> Christoph Kukulies wrote:
> > Was bedeutet in jener Liste die Bemerkung "Nur zu Servern der RWTH"?
>
> s/zu/zu angemeldeten/
Das ist aber etwas verwirrend. Wenn man per VPN im RWTH-Netz ist, kann
man die Dienste mit der Bemerkung "Nur zu Servern der RWTH" auch
benutzen, ohne dass der Server angemeldet wurde.
Wenn also auf einem Institutsrechner ein Webserver/Webinterface läuft,
dann ist der Rechner normalerweise ohne Anmeldung von ausserhalb der
RWTH nicht erreichbar. Ist man dagegen per VPN "eingewählt", kann man
auch darauf zugreifen.
Allerdings lassen sich die die von der Landesregierung zensierten Seiten
anscheinend weiterhin aufrufen - zumindest wenn man nicht den
"kompletten Tunnel" benutzt. Ich erreiche auch weiterhin die Geräte im
LAN (bei anderen Teilnehmern gab es da ja wohl Probleme ...). Ach ja,
hier läuft der VPNClient v3.7 (Rel) mit GUI unter MacOS X 10.2.3 ... .
Gruß,
Dominik.
Jens Liebchen
> Allerdings lassen sich die die von der Landesregierung zensierten Seiten
> anscheinend weiterhin aufrufen - zumindest wenn man nicht den
> "kompletten Tunnel" benutzt.
Das ist doch auch richtig so. Der Traffic zu den zensierten Seiten wird
beim split-tunneling nicht über die RWTH geleitet und da zum Glück
nicht alle Provider die ländliche Zensur unterstützen, kommst Du eben an
die Seiten heran, wenn Du bei einem solchen Provider bist.
Viele Grüsse,
Jens
Jens Hektor
> Das ist aber etwas verwirrend. Wenn man per VPN im RWTH-Netz ist, kann
Eben: man ist per VPN *im RWTH-Netz*. Mit allen Vor- und Nachteilen.
Jens Hektor
> Das ist doch auch richtig so. Der Traffic zu den zensierten Seiten wird
> beim split-tunneling nicht über die RWTH geleitet und da zum Glück
> nicht alle Provider die ländliche Zensur unterstützen, kommst Du eben an
> die Seiten heran, wenn Du bei einem solchen Provider bist.
man proxy
Dominik Schlütter
Jens Liebchen <jens...@liebchen-online.de> schrieb:
> Das ist doch auch richtig so.
Ja, die Bezeichnung "split-tunneling" lässt so etwas erahnen %-).
> Der Traffic zu den zensierten Seiten wird beim split-tunneling nicht über
> die RWTH geleitet und da zum Glück nicht alle Provider die ländliche
> Zensur unterstützen, kommst Du eben an die Seiten heran, wenn Du bei einem
> solchen Provider bist.
Ja. Aber so wie ich das sehe, ist der RWTH-DNS beim Zugang via VPN mein
primärer Nameserver (der beantwortet auch die 'nslookup'-Anfragen). Und
dann ist es ja eine Frage der DNS-Konfiguration, die entsprechenden
Domainnamen liessen sich ja auch RWTH-intern auf beliebige Rechner
umbiegen - der Nameserver müsste sich nur dafür zuständig fühlen. Oder
verstehe ich da etwas grundlegend miss?
Gruß,
Dominik.
Dominik Schlütter
Jens Hektor <hek...@rz.rwth-aachen.de> schrieb:
> Eben: man ist per VPN *im RWTH-Netz*. Mit allen Vor- und Nachteilen.
Das ist mir schon klar. Nur heisst die Seite ja u.a. "Blocked Ports and
Networks" und die Tabelle "Gesperrte Dienste". Die Dienste sind aber
eben im RWTH-Netz *nicht* gesperrt sondern nur von ausserhalb. Ganz im
Gegensatz zu den gesperrten Netzwerken, denn die sind nur innerhalb des
RWTH-Netzes gesperrt (naja, einige Provider beugen sich wohl auch dem
Büssow).
Ist also etwas verwirrend bezeichnet - aber man kann sich vermutlich
denken, was gemeint ist.
Gruß,
Dominik.
Patrick Loijens
nö, nicht verwirrend, man muss nur lesen können :-)
Du solltest nicht mit "wo" denken sondern mit "rein" und "raus": bei der
Anfrage ging es darum 'Was bedeutet in jener Liste die Bemerkung "Nur
zu Servern der RWTH"?' Die Bedeutung davon ist wenn man die Dienste von
deinem Rechner (Client, der ausserhalb der RWTH steht; der Verkehr geht
RWTH-rein) _direkt_ zu einem RWTH-Rechner (Server, der innerhalb vom
RWTH-Netz steht) benutzen will geht dies nur wenn der "Server"
angemeldet ist. Wie du richtig erkennst sind die Dienste (ausser die 5
spezielle) nicht innerhalb der RWTH gesperrt, dies ist aber auch
nirgendwo angedeutet.
Bei den gesperrten Netzwerken ist es aber eine ganz andere Sache: hier
kann man schlecht reden von rein oder raus, es duerfte klar sein das die
genannte Netzwerke nicht innerhalb des RWTH-IPs-Bereich liegen.
'Innerhalb' der RWTH sind die nicht gesperrt, nur "aus dem RWTH-Netz
-über die RWTH-Firewall- rausgehend", und dann auch nur fuer die
angegebene Dienste.
Um dein Posting vom 6.2 23H23 zu beantworten:
Es gab von der Regierung mehrere Möglichkeiten die Netzwerke zu
"sperren". Die von dir genannte DNS-Lösung war eine, wird hier jedoch
nicht angewand. Hier wird -wie auf der genannte Seite erwähnt- lediglich
die Port/IP-Kombination gesperrt und das wiederum beantwortet deine
Verwirrung vom 6.2. 16H53: der RWTH-DNS liefert sehr wohl eine IP zurück
und wenn du dann per VPN keinen vollständigen Tunnel hast erkennt dein
Rechner das er diese IP nicht ueber den Tunnel ansprechen soll, sondern
direkt und somit bekommst du von dieser Sperrung ueberhaupt nix mit (es
fliesst ja kein weiterer Verkehr ueber die RWTH).
Und um hier nochmal zurück zu kommen auf dem WO und REIN/RAUS: das nette
an einem VPN-Tunnel ist die (ueblicherweise) Verschluesselung:
dazwischen kann keine Filter gebastelt werden das irgendwelche Ports
oder Netzwerke sperrt: Sobald du dich per VPN einwaehlst bist du also im
RWTH-Netz (es wuerde auch wenig Sinn machen zwischen VPN-Server und
RWTH-Rest-Netz noch ein Paketfilter/Firewall aufzusetzen) und egal wo
dein Rechner gerade steht, ab hier ist nur noch wichtig ob es dann ueber
die RWTH-Firewall rausgeht oder nicht.
patrick
Jens Liebchen
> man proxy
Wenn ich den Proxy der RWTH nutze, dann läuft natürlich wieder alles über
die RWTH (sofern ich nur Dienste via Proxy nutze) und damit ist dann
effektiv ein Full-Tunneling erreicht. Ich denke aber nicht, dass das im
Sinne der RWTH ist, oder? Schießlich trägt dann die RWTH wieder den
gesamten Traffic.
Viele Grüsse,
Jens
Jens Liebchen
Hallo Dominik,
> Ja. Aber so wie ich das sehe, ist der RWTH-DNS beim Zugang via VPN mein
> primärer Nameserver (der beantwortet auch die 'nslookup'-Anfragen). Und
> dann ist es ja eine Frage der DNS-Konfiguration, die entsprechenden
> Domainnamen liessen sich ja auch RWTH-intern auf beliebige Rechner
> umbiegen - der Nameserver müsste sich nur dafür zuständig fühlen.
> Oder verstehe ich da etwas grundlegend miss?
Nein, dass hört sich korrekt und logisch an.
Wenn Du den DNS der Uni genutzt hast, dann kann es nur an der Sperrtechnik
liegen. "Normalerweise" sollte per DNS zensiert werden, wenn mich aber
richtig errinnere, sperrt die RWTH die Netze und somit stimmt zwar die
DNS-Auflösung, aber man kommt trotzdem nicht an die Seiten dran. Über
den Sinn dieser Aktion kann man streiten, da man so nicht die Hinweise des
RP Düsseldorf zu sehen bekommt und ausserdem evtl. unschuldige Seiten auf
dem gleichen Server mit gleicher IP (virtual name based hosting) betroffen
sein könnten.
Jedenfalls macht Deine Beobachtung so auch wieder Sinn :-)
Viele Grüsse,
Jens
Matthias Bläsing
> Nein, dass hört sich korrekt und logisch an.
>
> Wenn Du den DNS der Uni genutzt hast, dann kann es nur an der Sperrtechnik
> liegen. "Normalerweise" sollte per DNS zensiert werden, wenn mich aber
> richtig errinnere, sperrt die RWTH die Netze und somit stimmt zwar die
> DNS-Auflösung, aber man kommt trotzdem nicht an die Seiten dran. Über
> den Sinn dieser Aktion kann man streiten, da man so nicht die Hinweise des
> RP Düsseldorf zu sehen bekommt und ausserdem evtl. unschuldige Seiten auf
> dem gleichen Server mit gleicher IP (virtual name based hosting) betroffen
> sein könnten.
Sperren ist aus Datenschutzsicht wesentlich besser als das Umbiegen der
DNS-Auflösung (welche Records willste denn umbiegen? A/MX/C-Name?).
Was geht den RP in Düsseldorf an, welche Seiten ich ansurfe. Mal
abgesehen davon dass ich die Zensur für Wiedersinnig, dämlich,
kurzsichtig und dumm halte.
Also lieber sperren als umbiegen.
Mfg
Matthias
--
| Matthias Bläsing |
| ICQ: 84617206 AIM: linuxfun81 MSN: linu...@hotmail.com |
| Jabber: linu...@amessage.de Email: mbla...@gmx.de |
| Ceterum censeo Mirosoftam esse delendam |
Dominik Schlütter
Patrick Loijens <loi...@b19.rwth-aachen.de> schrieb:
> Die Bedeutung davon ist wenn man die Dienste von deinem Rechner (Client,
> der ausserhalb der RWTH steht; der Verkehr geht RWTH-rein) _direkt_ zu
> einem RWTH-Rechner (Server, der innerhalb vom RWTH-Netz steht) benutzen
> will geht dies nur wenn der "Server" angemeldet ist.
Ich habe das Prinzip schon verstanden. Es ging mir nur darum, dass das
auf der Seite irgendwie seltsam rüberkommt - denn wenn man
<http://www.rz.rwth-aachen.de/kommunikation/info/blocked.html> sehen
kann, ist man ja zwingend im RWTH-Netz. Zu diesem Zeitpunkt kann ich
aber beispielsweise HTTP- oder SSH-Verbindungen zu *beliebigen* Rechnern
aufbauen (naja, sofern dort ein entsprechender Dienst läuft), egal ob
sie zur RWTH gehören oder nicht.
Die gefilterten Ports mit "Nur zu Servern der RWTH" zu beschriften wäre
daher nur dann sinnvoll, wenn diese Seite von ausserhalb der RWTH
aufgerufen werden könnten - dann passen aber die blockierten Netzwerke
nicht so recht ins Konzept, denn die haben ja erst mal nichts mit der
RWTH zu tun. Soviel zur "sprachlichen Verwirrung".
> [...] der RWTH-DNS liefert sehr wohl eine IP zurück und wenn du dann per
> VPN keinen vollständigen Tunnel hast erkennt dein Rechner das er diese IP
> nicht ueber den Tunnel ansprechen soll, sondern direkt und somit bekommst
> du von dieser Sperrung ueberhaupt nix mit (es fliesst ja kein weiterer
> Verkehr ueber die RWTH).
Ah so, das war mir nicht ganz klar geworden. Ich hatte bisher immer nur
von der (ziemlich sinnfreien) DNS-Lösung gehört, weil die meisten
Provider sich gegen eine echte Sperrung immer gewehrt hatten.
> Sobald du dich per VPN einwaehlst bist du also im RWTH-Netz (es wuerde
> auch wenig Sinn machen zwischen VPN-Server und RWTH-Rest-Netz noch ein
> Paketfilter/Firewall aufzusetzen) und egal wo dein Rechner gerade steht,
> ab hier ist nur noch wichtig ob es dann ueber die RWTH-Firewall rausgeht
> oder nicht.
Auch wenn das in meinen Postings anscheinend nicht so rüberkam, ich
weiss was ein VPN ist. Das "wo" in meinen Postings bezog sich immer auf
den "logischen Standpunkt", also ab der Rechner IP-mässig inner- oder
ausserhalb des RWTH-Netzes befand.
Gruß,
Dominik.
Jens Liebchen
Hallo Matthias,
auch wenn ich hier keine Grundsatzdiskussion darüber starten möchte, da
Zensur immer falsch ist, möchte ich dennoch kurz auf Deine Argumente
eingehen.
> Sperren ist aus Datenschutzsicht wesentlich besser als das Umbiegen der
> DNS-Auflösung (welche Records willste denn umbiegen? A/MX/C-Name?).
Es geht hier nicht um Datenschutz sondern um Zensur. Durch die Sperrung
der Seiten durch die RWTH findet diese Zensur für die meisten Nutzer
verdeckt statt, während die DNS-Methode die Zensur jedem Nutzer direkt
aufzeigt.
Des weiteren können durch eine Sperrung der IP-Adresse in Verbindung mit
Port 80 und 443 auch viele unschuldige Seiten betroffen werden, da virtual
name based hosting (also die gleiche IP für viel Domains) zumindest für
Port 80 Standard ist und auch so empfohlen wird.
Ich finde diese beiden Hauptgründe als Grund genug, die DNS-Methode für
geigneter zu halten (ohne hiermit den Sinn der gesamten Aktion zu
verstehen btw. auch nur zu akzeptieren).
> Was geht den RP in Düsseldorf an, welche Seiten ich ansurfe. Mal
> abgesehen davon dass ich die Zensur für Wiedersinnig, dämlich,
> kurzsichtig und dumm halte.
Nichts. 100% agree. Eine Alternative wäre z.B. ein umbiegen auf
reservierte Adressen aus RFC1918 (z.B. 127.0.0.1), oder auf eine
Informationsseite der RWTH (die ja eh sieht, wohin Du surfst) um hier
wieder eine Transparenz der Sperrung für den User zu erreichen.
Viele Grüsse,
Jens