hi, folks! einige kennen wahrscheinlich noch meine verzweifelten hilferufe (siehe: "PAP-Athentication failed! -> Immer noch keine ISDN-Verbindung" und "Probleme beim Verbindungsaufbau mit dem Provider"). die probleme des verbindungsaufbaus sind beseitigt!!! was war der grund? ... (eine kleine story aus dem leben) die TELEKOM!!! wer sonst?! ich habe mich dummerweise auf die aussage verlassen, dass fuer alle meine nummerns (5 MSNs) die rufnummernuebermittlung eingeschalten ist. die hochschule will dies aus sicherheitsgruenden. nachdem ich nun hin und her probiert habe und nichts lief, musste ich leider direkt zur hochschule fahren und nachfragen. die gaben mir noch einmal die bestaetigung meiner konfiguration und stellen fest, dass die rufnummer nicht uebertragen wird. ich kam nichts an, nicht einmal was falsches. das war mir dann ein anruf bei der telekom wert. in sage und schreibe 3 tagen war diese (minuten)arbeit erledigt (dafuer wurden aber 2 andere telefonnummern ungueltig geschalten, was wiederum eine beschwerde auslöste; erst gegen 20 uhr konnte der mann bei der stoerungsstelle feierabend machen). doch nun laeuft diese sache erst mal. jedenfalls habe ich alles noch einmal von vorn gemacht und alles lief ohne probleme. HURRA!!! einige vielleicht sogar irgendwann sehr viele fragen bleiben noch offen! ich habe ein netz mit 4 rechnern (3 win, 1 linux). alle rechner haben eigene IPs (192.168...) in der hosts-datei eingetragen. die ISDN-karte hat eine eigene IP für den ausgehenden verkehr. da das masquerading in suse6.3 wohl nicht hinhaut (ich habe es erst gar nicht probiert), laeuft alles ueber einen proxy (squid) auf der linux-kiste. FRAGE 1: immer, wenn der squid gestartet wird, wird auch eine linux-verbindung per isdn aufgebaut. in der messages ist ungefaehr folgender eintrag kurz nach dem start von squid xxx OPEN 192.168.10.1 -> 141.45.221.75, port: 1060 -> 53 der port 1060 muss dabei nicht immer dieser sein. es stand da auch schon ein anderen. aber dass der anruf vom proxy ausgeloest wird, ist sehr wahrscheinlich (denn ohne passiert das nicht). wie kann ich das anrufen beim hochfahren abschalten? FRAGE 2: kann man auch mail, ftp, telnet, chat usw. (jegliche IP-verkehr) ueber einen proxy abwickeln oder muss ich da dann das masquerading einschalten? danke im voraus!
René Oelke wrote:
[ ... eine schöne Geschichte über unsere T*L*K*M ... ]
einige vielleicht sogar irgendwann sehr viele fragen bleiben noch offen! ich habe ein netz mit 4 rechnern (3 win, 1 linux). alle rechner haben eigene IPs (192.168...) in der hosts-datei eingetragen. die ISDN-karte hat eine eigene IP für den ausgehenden verkehr. da das masquerading in suse6.3 wohl nicht hinhaut (ich habe es erst gar nicht probiert), laeuft alles ueber einen proxy (squid) auf der linux-kiste.
Es läuft! # ipchains -P forward DENY # ipchains -A forward -i ippp0 -j MASQ # echo 1 > /proc/sys/net/ipv4/ip_forward
FRAGE 1: immer, wenn der squid gestartet wird, wird auch eine linux-verbindung per isdn aufgebaut. in der messages ist ungefaehr folgender eintrag kurz nach dem start von squid xxx OPEN 192.168.10.1 -> 141.45.221.75, port: 1060 -> 53 der port 1060 muss dabei nicht immer dieser sein. es stand da auch schon ein anderen. aber dass der anruf vom proxy ausgeloest wird, ist sehr wahrscheinlich (denn ohne passiert das nicht). wie kann ich das anrufen beim hochfahren abschalten?
Nameserveranfrage (Port 53=DNS); siehe hierzu die SDB, Stichwort "ungewollter Verbindungsaufbau".
FRAGE 2: kann man auch mail, ftp, telnet, chat usw. (jegliche IP-verkehr) ueber einen proxy abwickeln oder muss ich da dann das masquerading einschalten?
Zwischen Proxy und Masquerade besteht ein Unterschied; bei erstem baut der Client eine Verbindung zu einem Proxy-Programm auf dem Server auf und dieses besorgt dann die Daten aus dem INET. Das Proxy-Programm kann dabei weitere Aufgaben übernehmen (z.B. Caching beim Squid oder aber Filtern; dann hat man (fast) eine Application-Level Firewall). Beim Masquerading "ersetzt" der Server/das Gateway den Socket (IP+Portnummer) des Clients durch eine eigene und leitet den Datenverkehr dann einfach durch. Die IP des Clients wird dadurch nach außen versteckt. Es gibt Proxys für fast alle Fälle (generische Proxys), Informationen hierzu sollte das Firewall-HowTo liefern oder aber das TIS-Firewall-Kit. Auch mit ipchains soll man eine generische Proxyfunktionalität aufbauen können (bitte hierzu mal das Listenarchiv durchforsten). Du solltest aber zuerst die Frage für Dich klären, ob Du eine Firewall (dann Proxys) oder ein einfaches Gateway (dann Masquerading) bauen willst. Gruß hebi -- Dirk Hebenstreit Büro-Informationstechnik Tel.: 0170 2461522 Eschenweg 3 033200 85997 14558 Bergholz-Rehbrücke FAX : 033200 85999 dhebenstreit@rios.de dhebi@gmx.net
René Oelke
xxx OPEN 192.168.10.1 -> 141.45.221.75, port: 1060 -> 53
Nameserver Anfrage. Kannst du bei squid AFAIK nicht verhindern.
kann man auch mail, ftp, telnet, chat usw. (jegliche IP-verkehr) ueber einen proxy abwickeln oder muss ich da dann das masquerading einschalten?
Über _einen_ Proxy schon, nicht über einen squid. Daher Masquerading erspart dir dabei viel Arbeit. Und wenn es mit den Scripten von SuSE nicht geht: Hey, das ist Linux, dann macht man das eben selber. S! -- Letzte Worte des Computer-Freaks: "Dieses Programm stuerzt nie ab."
----- Original Message -----
From: "Sven Hartge"
Nameserver Anfrage. Kannst du bei squid AFAIK nicht verhindern.
War da nicht etwas mit 'squid -D', was die NameServer-Anfragen verhindern soll? Gruss Frank ________________________________________ Frank Krueger (reg. Linux User #153981) Email: frank@netlogistics.de you may have a look at http://www.netlogistics.de ________________________________________
Frank Krüger
Nameserver Anfrage. Kannst du bei squid AFAIK nicht verhindern.
War da nicht etwas mit 'squid -D', was die NameServer-Anfragen verhindern soll?
Wenn ich mich richtig erinnere, macht squid trotzdem eine Anfrage, um den parent etc. aufzulösen. Daher sollte man dann dort die IPs direkt angeben. Zumindest einen Versuch ist es Wert. S! -- 40% of problems are solved by the next release 30% of problems are solved by reading the manual 20% of problems are solved by re-writing the manual
participants (4)
-
Dirk Hebenstreit -
Frank Krüger -
René Oelke -
Sven Hartge