port öffnen

H

hudo

Active Member
Hallo,

ich moechte von einem internen Rechner auf http://10.10.10.1:4080 zugreifen koennen,
aber nicht vom Router selbst.

Router mit openbsd3.3 und mldonkey.

--------------------------------------------------------------------------
Ext = "tun0" # Device an dem das Internet angeschlossen ist
Int = "rl0" # Device an dem das interne Netz haengt
IntNet = "10.10.10.0/24" # Adressraum des internen Netzes
RouterIP = "10.10.10.1" # IP Adresse des Routers
Loop = "lo0" # Loopback Device
dport = "4662" #donkey port usually 4662
mldonkey_ext = "4666" #donkey udp receiving

...
...
...

### am Ende von pf.conf hinzugefuegt:

pass in on $Int proto tcp from { 10.10.10.3, !10.10.10.1 } to $RouterIP port 4080 keep state
--------------------------------------------------------------


Was ist hier falsch ??
 
wo ist denn das prob?
btw. du müsstest auf dem loopbackdevice filtern um nicht auf localhost zugreifen zu können.
 
Ich denke, daß das Problem ist, daß hudo nicht auf den mldonkey, der auf seinem router läuft, per webinterface zugreifen kann... right?
 
Gruesse,

nmap hab ich nicht gemacht.
Es geht aber lynx 10.10.10.1:4080 von 10.10.10.1 aus

pf ist natuerlich gestartet.

connecten und downloaden mit mldonkey funktioniert auch,

eben nur der webzugriff von einem anderen/internen Rechner nicht :(
 
und was steht in
/etc/hostname.rl0
/etc/hosts


ich mein , der rechner der auf den router zugreifen soll steht ja in der hosts . - sonst ginge ja netzwerk nicht ..?
 
Du hast im Esel aber schon eingetragen, dass diese IP auf ihn zugreifen darf? Muss man meines Wissens nach auch noch. Per Default darf glaub nur localhost zugreifen.
 
in downloads.ini steht:

allowed_ips = [
"127.0.0.1";
"10.10.10.3";
"10.10.10.1";]

...also daran liegts nicht

Was das mit /etc/hosts zutun hat weiss ich nicht....

Router ist auch dhcp -server

Wenns mal mit dem Zugriff klappt, dann werde ich downloads.ini auf

allowed_ips = [
"10.10.10.255";]

ändern

Wie gesagt mldonkey laeuft, laeuft,laeuft ...nur interface geht nicht.

Ich mache das grad alles ueber telnet 10.10.10.1 4000

Ist das eigentlich eine Sicherheitslücke ?? (bin nicht so von telnet begeistert, verwende immer ssh)

Kann man mldonkey - telnet abschalten ???
 
/etc/pf.conf: (is von juergen graf)

### VARIABLEN ###

Ext = "tun0" # Device an dem das Internet angeschlossen ist
Int = "rl0" # Device an dem das interne Netz haengt
IntNet = "10.10.10.0/24" # Adressraum des internen Netzes
RouterIP = "10.10.10.1" # IP Adresse des Routers
Loop = "lo0" # Loopback Device
dport = "4662" #donkey port usually 4662
mldonkey_ext = "4666" #donkey udp receiving




# Adressen die auf dem externen Device nicht geroutet werden
# (Adressbereich des internen Netzes muss man wegen der Weiterleitungen zulassen)
NoRoute = "{ 127.0.0.1/8, 172.16.0.0/12, 10.0.0.0/8, 255.255.255.255/32 }"

# Ports die geoeffnet werden sollen
InServicesTCP = "{ ssh, ftp, auth }"


### OPTIONS ###

# Macht Statistiken fuer die DSL-Verbindung (pfctl -s info)
set loginterface $Ext

# Beendet inaktive Verbindungen schneller - geringerer Speicherverbrauch.
set optimization aggressive

# Fragmentierte Pakete saeubern
scrub on $Ext all fragment reassemble random-id


### NAT & FORWARD ###

# NAT aktivieren (unter Linux als Masquerading bekannt)
nat on $Ext from $IntNet to any -> $Ext static-port

# Active FTP - Umleitung zu unserem ftp-proxy
rdr on $Int proto tcp from !$RouterIP to !$IntNet port 21 -> 127.0.0.1 port 8081

rdr-anchor redirect


### FILTER ###

# Zum Debuggen....
#pass quick all # Alles durchlassen

# Generelle Block Regel
block on $Ext

# Freiwillig machen wir keinen mucks ;)
block return log on $Ext

# Wir wollen kein IPv6.0
block quick inet6

# Loopback Device darf alles
pass quick on $Loop

# Erschwert scannen mit nmap und co.
block in log quick on $Ext inet proto tcp from any to any flags FUP/FUP
block in log quick on $Ext inet proto tcp from any to any flags SF/SFRA
block in log quick on $Ext inet proto tcp from any to any flags /SFRA

# IP Spoofing verhindern
block in log quick on $Ext inet from $NoRoute to any
block in log quick on $Ext inet from any to $NoRoute

# Active FTP erlauben
pass in quick on $Ext inet proto tcp from any to any port > 49151 user proxy flags S/SAFR keep state

# Ping akzeptieren (ablehnen ist uebrigends wenig sinnvoll)
pass in quick on $Ext inet proto icmp all icmp-type 8 code 0 keep state

# Ports nach aussen oeffnen
pass in quick on $Ext inet proto tcp from any to any port $InServicesTCP flags S/SAFR keep state label ServicesTCP

anchor passin

# Raus darf (fast) alles
pass out quick on $Ext keep state


##edonkey ######
# edonkey data
pass in on $Ext proto tcp from any to $Ext port 4662 flags S/SAFR keep state
# mldonkey source propagation
pass in on $Ext proto udp from any to $Ext port 4666 keep state
# overnet data


# overnet search


pass in on $Int proto tcp from $IntNet to $RouterIP port 4080 keep state
 
Die pf.conf ist zwar "strange", aber daran liegt's nicht.

Ich kenn den donkey kram nicht, aber evtl regelt die allowed_ips garnicht
diesen speziellen Zugriff auf 4080?

Evtl braucht er einfach auch nur "relativ lange", weil das Teil DNS
resolving machen will.. mal die interne clientIP mit nach /etc/hosts packen?
 
Hallo,


Aktueller Stand:

Mit Browser der unter Linux laeuft kann ich darauf zugreifen..


Mit Browser der unter Windows laeuft kann ich nicht darauf zugreifen (weder IE noch Mozilla) , aber mit lynx fuer Windows geht es. Es ist also ein Browser/Betriebssystem Problem.


Ich glaube auch nicht dass die pf.conf dafuer verantwortlich ist dass es nicht funktioniert.

Habe die Zeile

pass in on $Int proto tcp from $IntNet to $RouterIP port 4080 keep state

aus pf.conf geloescht --> Verhalten wie oben.

Wenn jemand eine Idee hat an was das Problem liegt/ wie man Abhilfe schafft ... bitte schreiben.


PS: was ist so strange an meiner pf.conf ??
 
Hi,

ist in dem IE evtl noch ein Proxy eingetragen?

pf.conf: Nun, schreib Dir mal selber eine, bzw lies nach, was jede
einzelne Zeile in dem "Ding" da tut.
Lesen, Nachdenken, Verstehen, Handeln - in der Reihenfolge ;-)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben