OpenBSD ignoriert scheinbar den Proxy

Hallo,

ich habe hier ein OpenBSD 5.5 (amd64) in einer virtuellen Maschine (temporär zum Testen, falls relevant KVM auf Linux) und habe das Problem, dass OpenBSD scheinbar den Proxy bzw. die Proxy-Einstellungen ignoriert. Als Linux-Admin habe ich das System logischerweise ohne GUI installiert. ;)

Mit all meinen Linux-Servern und meiner Workstation (ebenfalls Linux) funktioniert alles einwandfrei, es ist also kein generelles Problem. Muss gestehen, nach den ganzen How-To-, Foren- und Trial-and-Error-Versuchen raucht mir etwas der Kopf. Habe es nicht hinbekommen. :confused:

Zu Hause (ohne DMZ) funktioniert alles tadellos, es ist also eindeutig kein OpenBSD- sondern ein Konfig-Problem.

Im Detail:

Ich habe die virtuelle Maschine mit statischer IP in dem VLAN in dem ich mich befinde. Ich kann auf das Netzwerk zugreifen und mich auch von meiner Workstation via SSH darauf verbinden. So weit so gut.

Das System soll über einen in der DMZ befindlichen Proxy-Server nach draußen gehen und da fangen meine Probleme an. Gehen wir davon aus, der Proxy hat die IP-Adresse 192.168.1.1 und Port 8001.

In meinem internen Netz habe ich zwei Router (Beispieladressen, nicht wundern):
10.0.0.100 ist der interne VLAN-Router (default)
10.0.0.200 der Router für den Weg in die DMZ
Die Default-Route geht über die 10.0.0.100, also den VLAN-Router (wie auch auf meinen anderen Linux-Kisten im Netz, Internet wird lediglich für Updates benötigt). Für die DMZ lege ich die Route wie folgt an:

# route add -net 192.168.1.0/24 10.0.0.200
Dann kann ich den Proxy pingen. Der erste Erfolg. Danach setze ich die Paketquellen wie in den BSD FAQs beschrieben (ja man könnte mit `machine ...` den Link dynamisch zusammensetzen, ich hab das hier jetzt mal statisch gemacht)

Ein echo $PKG_PATH gibt mir auch den o. g. Wert zurück.

Öffne ich diese URL im Browser bekomme ich alle dort befindlichen Pakete angezeigt. Habe dann in diversen Foren gelesen, wie man auf der Shell die Proxy-Einstellungen setzt (eigentlich wie auf Linux auch, nur bei BSD in Großbuchstaben ... habe es aber auch mit Kleinbuchstaben probiert):

# export HTTP_PROXY="http://192.168.1.1:8001"
# export HTTPS_PROXY="http://192.168.1.1:8001"
# export FTP_PROXY="http://192.168.1.1:8001"

Habe im Netz noch gelesen, man solle das mit setenv machen ... aber wie, wenn es das nicht gibt?

ksh: setenv: not found :ugly:

Aber zurück zum Thema. Ich würde gerne z. B. wget (als Binärpaket) installieren. Also mache ich

# pkg_add wget
Error from ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/amd64/
ftp: connect: Connection timed out
ftp: Can't connect or login to host `ftp.openbsd.org'
ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/amd64/ is empty
Can't find wget
# pkg_add wget
und in den Logs kann ich sehen, dass das System
  1. über die VLAN-Router IP-Adresse und Port 21 geht (hab das den Deny-Meldungen in den Logs des Routers entnommen)
  2. scheinbar die FTP-Proxy-Einstellungen ignoriert (Anhand der Proxy-IP und der entsprechenden Route sollte das System ja den richtigen Weg finden)
Danach habe ich es mit einem HTTP-Server versucht, mit diesem Ergebnis:

# pkg_add wget
Error from http://openbsd.cs.fau.de/pub/OpenBSD/5.5/packages/amd64/
ftp: connect: No route to host
http://openbsd.cs.fau.de/pub/OpenBSD/5.5/packages/amd64/ is empty
Can't find wget
#
Warum FTP? :confused: Habe dann mittels pfctl -d auch mal den Paketfilter deaktiviert. Allerdings mit dem gleichen Ergebnis. Auch den FTP-Modus habe ich via export FTPMODE=active einfach mal auf aktiv gestellt (passiv ist ja Standard). Auch kein Erfolg.

Versuche ich es direkt mit ftp <Adresse> funktioniert dies auch nicht, das System möchte wieder über den VLAN-Router gehen, was wieder zu Deny-Meldungen im Log führt.

Entferne ich die Default-Route (10.0.0.100) und versuche es erneut, geht das System über den richtigen Router (10.0.0.200), aber verwendet den Proxy nicht (erhalte eine Deny-Meldung im Log, da die Zieladresse nicht der Proxy, sondern die IP-Adresse des Servers im Internet ist).

Vielen Dank im Voraus! :)
 
Code:
# export HTTP_PROXY="http://192.168.1.1:8001"
# export HTTPS_PROXY="http://192.168.1.1:8001"
# export FTP_PROXY="http://192.168.1.1:8001"

Alle drei Variablen mußt du in Kleinbuchstaben schreiben. Siehe ftp(1), /^ENVIRONMENT.
 
Danke für die schnelle Antwort!

Wie in meinem Post erwähnt habe ich beides ausprobiert, Groß- und Kleinschreibung. In den meisten How-Tos schreiben die das groß, kenne es von Linux auch nur in klein.
 
Zum eigentlichen Problem kann ich nicht viel sagen. Das muss funktionieren. Am besten mal mit komplett frischem Environment starten und nur $ftp_proxy bzw. $http_proxy setzen.

Zwei Anmerkungen:

# pkg_add wget
Error from http://openbsd.cs.fau.de/pub/OpenBSD/5.5/packages/amd64/
ftp: connect: No route to host
http://openbsd.cs.fau.de/pub/OpenBSD/5.5/packages/amd64/ is empty
Can't find wget
#
Warum FTP?

Weil ftp(1) unter OpenBSD auch HTTP-URLs verarbeitet.

Versuche ich es direkt mit ftp <Adresse> funktioniert dies auch nicht, das System möchte wieder über den VLAN-Router gehen, was wieder zu Deny-Meldungen im Log führt.

Mit ftp(1) direkt einen FTP-Server interaktiv ansprechen geht nie über den Proxy, wie könnte es auch. Der Proxy wird nur genutzt, wenn direkt ein URL übergeben wird.
 
Mir ist nicht klar, warum das nicht funktionieren sollte. Wenn du den Proxy bereits pingen kannst, kann es ja auch kein Netzwerkproblem sein.

Wenn ich das testweise mit einem öffentlichen Proxy versuche, funktioniert es ohne Probleme:
Code:
$ http_proxy=http://62.113.208.89:7808 pkg_info gnome
Information for http://ftp.halifax.rwth-aachen.de/openbsd/snapshots/packages/amd64/gnome-3.12.2p1.tgz

Comment:
GNOME desktop meta-package (base installation)

Description:
The GNOME desktop, standard installation.

Maintainer: Jasper Lievisse Adriaanse <jasper@openbsd.org>,  Antoine Jacoutot <ajacoutot@openbsd.org>
 
Ich habe das mit

# http_proxy=http://192.168.1.1 pkg_info gnome

probiert, ich erhalte jedoch folgende Fehler:

# http_proxy=http://192.168.1.1 pkg_info gnome
Error from ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/amd64//
ftp: Error retrieving file: 400 Invalid request received from client
ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/amd64// is empty
Error from ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/amd64//gnome.tgz
ftp: Error retrieving file: 400 Invalid request received from client
Error from ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/amd64//gnome.tgz
ftp: Error retrieving file: 400 Invalid request received from client
Error from ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/amd64//gnome.tgz
ftp: Error retrieving file: 400 Invalid request received from client
Error from ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/amd64//gnome.tgz
ftp: Error retrieving file: 400 Invalid request received from client
Error from ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/amd64//gnome.tgz
ftp: Error retrieving file: 400 Invalid request received from client
#
Des weiteren sehe ich Deny-Meldungen in den Logs des Routers, dass das System nicht den Proxy verwendet, sondern direkt versucht, auf die externe IP-Adresse zuzugreifen, was natürlich nicht geht.
 
Da du FTP verwendest, müsstest du natürlich auch die Variable ftp_proxy setzen. Ich empfehle dir aber, auf HTTP umzusteigen, weil das auch seitens OpenBSD nun der Standard ist.

Probiere folgendes:
Code:
export PKG_PATH=http://ftp.halifax.rwth-aachen.de/openbsd/5.5/packages/amd64
export http_proxy=http://192.168.1.1:<Proxy-Port>
pkg_info gnome

Was sagt währenddessen:
Code:
tcpdump -i <Interface mit Route zur DMZ> port <Proxy-Port>

Da solltest du dann zumindest die Requests sehen.
 
fangen wir mal unten an:
Welche statische IP hast du der VM gegeben? Bridge oder Routed?
Was sagt ein traceroute 192.168.1.1 ? Geht es überhaupt über den 10.0.0.200?
 
So, da hat was funktioniert.

Ich habe lediglich die Proxy-Variablen sowie die Paketquellen in ~/.profile eingetragen, neu gestartet (ich weiß, neu anmelden hätte gereicht, aber wollte auf Nummer sicher gehen ;)) und danach manuell die Route in die DMZ gesetzt (diese soll auch nicht permanent sein), dann hat es funktioniert.

Vorher habe ich eigentlich das gleiche gemacht, nur eben direkt auf der Shell. Werde nochmal nachforschen, warum das so vorher nicht funktioniert hat.

Danke für eure Bemühungen!
 
Zurück
Oben