Google-Earth could not connect to the server

Hallo,

habe gerade einen neuen Ansatz gefunden, warum die Google-Earth-Suche nicht funktionieren könnte. Vielleicht liegt es am meinen Einstellungen des Internetzugangs?!

Nach einer Weile warten erscheint dann die Fehlermeldung:
„Sorry, your search could not be performed because Google Earth could not connect to the server. Suggestions: Make sure your PC is connected to the Internet. Try your search again in a few minutes“

Ich musste ja schon folgendes tun um überhaupt eine Anzeige zu bekommen:

Ich sende mal meine Webproxy-Einstellungen mit - vielleicht fällt Euch da was auf?


Für alle Tipps dankbar!
Stefan

… und wenn ich den transparenten Proxy deaktiviere, kommt nicht einmal die Weltkugel und das Grafikfenster bleibt schwarz.

Auch wenn ich den Proxy dann im System bekannt mache, kommt nix, auch nicht nach Löschen des Konfigurationsordners .googleearth im Home:
export http_proxy=http://10.16.1.254:800
export https_proxy=https://10.16.1.254:800

???
Stefan

Hallo Stefan,

… und wenn ich den transparenten Proxy deaktiviere, kommt nicht einmal
die Weltkugel und das Grafikfenster bleibt schwarz.

Auch wenn ich den Proxy dann im System bekannt mache, kommt nix, auch
nicht nach Löschen des Konfigurationsordners .googleearth im Home:
export http_proxy=http://10.16.1.254:800
export https_proxy=https://10.16.1.254:800

ich denke, du gehst da schon in die richtige Richtung: irgendwie
erreicht der die googleserver nicht.

Um zu sehen, ob es an deinem IPFire/Fritzbox/belWue oder irgendwas
liegt, würde ich mal einen Cleint (Laptop?) mit nach Hause nehmen udn da
versuchen.

LG

Holger

Hallo Stefan,

trag den Rechner doch versuchsweise mal bei „Uneingeschränkte IP-Adressen“ ein.
Funktioniert auf der Konsole ein „wget“?

Wenn Du de Proxy transparent hast, musst Du keinen im System eintragen, nur wenn er nicht transparent wäre. Dann reichen meist Deine beiden Zeilen nicht:

Ich füge immer noch alles in Großbuchstaben hinzu: HTTP_PROXY=…

LG
Max

Hallo Stefan,

Ich sende mal meine Webproxy-Einstellungen mit - vielleicht fällt Euch
da was auf?

https://ask.linuxmuster.net/uploads/default/original/1X/c51490618bbaf8090ce8793923d940192acf53f5.png

https://ask.linuxmuster.net/uploads/default/original/1X/ea78c9c2ab89656315d34a152679679b0deacba0.png

nimm doch mal testweise den BelWü Proxy raus …

Desweiteren sind diene Cacheeinstellungen eher sehr klein.

Ich habe folgende Werte:
Erste Spalte:
cahmanager aktivieren: ja
4096
1024
0
32
LRU
LRU
nein
nein

Zweite Spalte:
meineemail
nix
4096
10240
leeres großes Feld

VIele Grüße

Holger

Hallo Holger, hallo Max,

Danke für die Anregungen. Hier kommen die Antworten und die Ergebnisse der neusten Tests.
Ich habe so den Eindruck, dass mit der Verbindung über Port 443 beim transparenten Proxy was nicht stimmt!

Ich hoffe, jemand kann sich da einen Reim darauf machen.

Gruß
Stefan


Da man auf der Abbildung des Web-Proxy nicht alle Ports erkennt, hier die Liste:

Ziel-Ports
Zulässige Standard-Ports (einer pro Zeile):
80 # http
21 # ftp
443 # https
563 # snews
70 # gopher
210 # wais
1025-65535 # unregistered ports
280 # http-mgmt
488 # gss-http
591 # filemaker
777 # multiling http
800 # Squids port (for icons)


Daheim geht die Suche!



Meinem Testsystem hat den Belwue-Proxy nicht eingetragen (und läuft auch über einen zweiten Internetanschluss direkt über eine t@school-Leitung) und da geht die Suche auch nicht.

Ich habe zur Sicherheit auch auf dem Produktivsystem einmal den vorgelagerten belwue-Proxy entfernt => keine Änderung des Problems.


Das waren eben die Grundeinstellungen. Habe ich angepasst - Danke!


wget funktioniert und verwendet aber 10.16.1.254:800, da ich dies in /etc/wgetrc vorsorglich eingetragen habe, falls ich den transparenten Proxy einmal deaktivieren sollte.

sen@adm-p02iii ~ $ wget -O /dev/null http://speedtest.dal01.softlayer.com/downloads/test100.zip
--2017-04-19 12:42:24--  http://speedtest.dal01.softlayer.com/downloads/test100.zip
Verbindungsaufbau zu 10.16.1.254:800... verbunden.
Proxy-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 104874307 (100M) [application/zip]
In »»/dev/null«« speichern.

Ohne den Eintrag in /etc/wgetrc geht wget aber auch:

sen@adm-p02iii ~ $ wget -O /dev/null http://speedtest.dal01.softlayer.com/downloads/test100.zip
–2017-04-19 13:08:12-- http://speedtest.dal01.softlayer.com/downloads/test100.zip
Auflösen des Hostnamen »speedtest.dal01.softlayer.com (speedtest.dal01.softlayer.com)«… 74.86.116.210, 2607:f0d0:1003:31::2
Verbindungsaufbau zu speedtest.dal01.softlayer.com (speedtest.dal01.softlayer.com)|74.86.116.210|:80… verbunden.
HTTP-Anforderung gesendet, warte auf Antwort… 200 OK
Länge: 104874307 (100M) [application/zip]
In »»/dev/null«« speichern.


Und hier noch ein paar Ungereimtheiten zu apt:

Mit root Rechten (sudo -i) getestet:
apt-get update funktioniert.
add-apt-repository ppa… funktioniert nicht direkt:

adm-p02iii ~ # add-apt-repository ppa:rvm/smplayer
PPA kann nicht hinzugefügt werden: »„Error reading https://launchpad.net/api/1.0/~rvm/+archive/smplayer: (7, ‚Failed to connect to launchpad.net port 443: Die Wartezeit f\xc3\xbcr die Verbindung ist abgelaufen‘)“«.

Erst nach dem veröffentlichen des https-Proxys geht es:

adm-p02iii ~ # export https_proxy=https://10.16.1.254:800
adm-p02iii ~ # add-apt-repository ppa:rvm/smplayer
Sie sind dabei Ihrem System das folgende PPA hinzuzufügen:
Packages for SMPlayer.

To install SMPlayer from this PPA, run these commands on a terminal:

sudo add-apt-repository ppa:rvm/smplayer
sudo apt-get update
sudo apt-get install smplayer smtube smplayer-themes smplayer-skins

Mehr Informationen: SMPlayer : rvm
Zum Fortfahren bitte die Eingabetaste drücken oder Strg+C, um das Hinzufügen abzubrechen

Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.KzD0NfXQZj --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys E4A4F4F4
gpg: Schlüssel E4A4F4F4 von hkp-Server keyserver.ubuntu.com anfordern
gpg: Schlüssel E4A4F4F4: „Launchpad PPA named smplayer for rvm“ nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg: unverändert: 1


Firefox lädt nur http- und keine https-Seiten, wenn er keinen Proxy eingetragen hat.
Mit Proxy 10.16.1.254:800 eingetragen, werden alle Seiten geladen.


Sobald ich Google-Earth vom PC mit der IP 10.16.11.2 starte,

sen@adm-p02iii ~ $ ifconfig
eth0 Link encap:Ethernet Hardware Adresse f8:32:e4:87:35:09
inet Adresse:10.16.11.2 Bcast:10.31.255.255 Maske:255.240.0.0
inet6-Adresse: fe80::fa32:e4ff:fe87:3509/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:146052 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:105410 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:133318124 (133.3 MB) TX-Bytes:63534042 (63.5 MB)

finde ich dies im IPfire-Firewall-Log:

Und die IP gehört zu Google:


OK - habe ich gemacht und danach im IPfire ‚Seichern und Neustart‘:

Aber danach wird Google-Earth immer noch blockiert!


Was mir noch einfällt zu evtl. Änderungen am System, die relevant sein könnten:

  • Habe noch eine unnötige Firewallregel für DigitalesSchwarzesBrett, die ich einmal abschalten sollte.

=> keine Änderung bei Deaktivierung der DSB-Regel (und Änderungen übernommen).

  • identd hat nie funktioniert, ist im Web-Proxy auch nicht als Auth-Methode aktiviert, auf dem Client ist oidentd nicht installiert, aber es sind noch Skripte da, die ich mal beseitigen sollte:
    /etc/linuxmuster-client/pre-mount.d/002-oident
    /etc/linuxmuster-client/post-umount.d/000-oident-kill

=> keine Änderung nach Löschen der Dateien (und ungesynctem Neustart)


…und die Tests gehen weiter:

Wenn ich eine neue Test-Regel im IPfire erstelle für einen Test PC, klappt die Suche auf dem PC:

Quelle: IP des PC
Ziel ROT
Alle Protokolle erlaubt.

In ‘allowedhosts’ war und ist der PC drin, bei allowedports ist aber 443 nicht dabei:

Wenn ich die Test-Regel einschränke, geht die Suche immer noch

Quelle: IP des PC
Ziel ROT
Nur TCP mit Zielport 443 erlaubt.


So - das hilft hoffentlich, dass mir jemand weiter helfen kann. Ich kenne mich da nicht genügend aus und möchte ja nicht einfach Löcher in meiner Firewall bohren, ohne die Folgen abschätzen zu können.

Gruß
Stefan

Hallo Stefan,

der WebProxy filtert grundsätzlich keine https Verbindungen: das
wiederspricht der Natur dieser Verbindungen: Point to Point und man
vertraut dem Zertifikat das der Gegenserver ausstellt: ein Proxy
dazwischen wäre ein Man in the MIddel hack…

Also: der Proxy ist es nicht.

Irgendwo in dienem System, vermute ich, ist SafeSearch eingeschaltet:
das könnte auch auf der Speedbox von der Telekom sein.

Bitte finde mal heraus, welche DNS der IPFire eingetragen hat, der
Server und der Client.

Weswegen verwendest du die BelWue DNS nicht?
Ich meine, dass BelWue Port 53 outgoing blockt: da solltest du also in
jedem Fall die von BelWü nehmen.
Vielelicht leitet ja auch der BelWue Router auf Safe sSearch um, wenn
man nicht die BelWue Proxys nimmt …

LG

Holger

Hallo Holger,

ich schaue so bald wie möglich nach dem DNS.

Du hast aber schon gesehen, dass ich mittels einer Firewallregel Google-Earth Zugriff auf den Google-Server verschaffen konnte - oder?

Liegt da nicht das Problem eher bei den Firewallregeln?

Gruß
Stefan

Hallo Stefan,

Du hast aber schon gesehen, dass ich mittels einer Firewallregel
Google-Earth Zugriff auf den Google-Server verschaffen konnte - oder?

S.Senft:

Wenn ich die Test-Regel einschränke, geht die Suche immer noch

Quelle: IP des PC
Ziel ROT
Nur TCP mit Zielport 443 erlaubt.

und dann geht es?

Liegt da nicht das Problem eher bei den Firewallregeln?

ich denke nicht: die Anfragen sollten ja an den Proxy gehen.
Natürlich kommt es bei der Firewall an, aber das der Proxy transparent
ist, wird sowiso alles weitergeleitet an den Proxy (auf Port 800).

Beschreib mal mehr, was bei dir vor dem IPFire los ist:
BelWue Router?
FritzBox?

LG

Holger

Hallo Holger,

Ja, genau. Wie zuvor beschrieben, habe ich 1. verworfene Pakete in der Firewall gefunden und 2. mit einer Erlaubnisregel für Port 443 hat die Google-Earth-Suche funktioniert. Deshalb frage ich mich, ob die ‚allowedports‘ bei meiner Firewall vielleicht nicht vollständig sind.
( Liest Du die Beiträge per Mail und kann es sein, dass Du meine Beiträge nicht alle vollständig bekommen hast? Bitte schaue dann doch mal im Forum direkt. Ich habe dort viele Angaben mit Screenshots gemacht. )

Produktivsystem:
IPfire (virt. auf XEN)
Belwue-Router (also feste rote IP für IPfire 141.bla.blu.blä)
Belwue als Provider
sonst nix.

Testsystem:
IPfire (virt. auf VirtualBox)
Telekom-Router (feste rote IP oder per DHCP für IPfire 192.168.blu.blä - weiß ich jetzt nicht auswändig)
Telekom als Provider (t@school-Anschluss)
sonst nix.

Guß
Stefan

Hallo Holger,

Auf dem IPfire sind die DNS-Server von Belwue eingetragen.


Für die Einstellungen am Server, habe ich mich an dieser Anleitung orientiert:
https://www.linuxmuster.net/wiki/anwenderwiki:dns-probleme

Auf dem Server habe ich in /etc/network/interfaces nachgesehen. Ich hoffe, das ist die richtige Stelle!?

# standard network interfaces template for linuxmuster.net
# For more information, see interfaces(5).
#
# thomas@linuxmuster.net
# 18.12.2013
#
# The loopback network interface
auto lo
iface lo inet loopback
# These interfaces are brought up automatically
auto eth0
iface eth0 inet static
        address 10.16.1.1
        netmask 255.240.0.0
        network 10.16.0.0
        broadcast 10.31.255.255
        gateway 10.16.1.254
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 10.16.1.1
        dns-search linuxmuster-net.lokal

Ich hoffe, dass
dns-nameservers 10.16.1.1 richtig ist - oder ist das der Fehler?
Im Wiki findet man 10.16.1.254
https://www.linuxmuster.net/wiki/dokumentation:techsheets:servernetzwerk
und 10.16.1.1 nur unter
https://www.linuxmuster.net/wiki/anwenderwiki:virtualisierung:kvm:kvm_aufdemserver

Außerdem ist hier noch die /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.16.1.1
search linuxmuster-net.lokal

Und die /etc/host.conf

# The "order" line is only used by old versions of the C library.
order hosts,bind
multi on

Für die Einstellungen am Client:
/etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

/etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search linuxmuster-net.lokal

/etc/host.conf

# The "order" line is only used by old versions of the C library.
order hosts,bind
multi on

So - ich hoffe, die Angaben reichen.

Gruß und Dank
Stefan

Hallo Stefan,

Für die Einstellungen am Server, habe ich mich an dieser Anleitung
orientiert:
anwenderwiki:dns-probleme [CommunityWiki]

Auf dem Server habe ich in /etc/network/interfaces nachgesehen. Ich
hoffe, das ist die richtige Stelle!?

|# standard network interfaces template for linuxmuster.net # For
more information, see interfaces(5). # # thomas@linuxmuster.net #
18.12.2013 # # The loopback network interface auto lo iface lo inet
loopback # These interfaces are brought up automatically auto eth0
iface eth0 inet static address 10.16.1.1 netmask 255.240.0.0 network
10.16.0.0 broadcast 10.31.255.255 gateway 10.16.1.254 # dns-*
options are implemented by the resolvconf package, if installed
dns-nameservers 10.16.1.1 dns-search linuxmuster-net.lokal|

Ich hoffe, dass
dns-nameservers 10.16.1.1 richtig ist - oder ist das der Fehler?
Im Wiki findet man 10.16.1.254

sieht bei mir auch so aus: auf dem server ist der server als dns
eingetragen.
Der fragt, wenn ich das richtig habe, den lokalen bind und der fragt den
ipfire.

dokumentation:techsheets:servernetzwerk [CommunityWiki]
und 10.16.1.1 nur unter
anwenderwiki:virtualisierung:kvm:kvm_aufdemserver [CommunityWiki]

Außerdem ist hier noch die /etc/resolv.conf

|# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL
BE OVERWRITTEN nameserver 10.16.1.1 search linuxmuster-net.lokal|

Und die /etc/host.conf

|# The "order" line is only used by old versions of the C library.
order hosts,bind multi on|

auch die Dateien sehen bei mir so aus.


Für die Einstellungen am Client:
/etc/network/interfaces

|# interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo
inet loopback|

/etc/resolv.conf

|# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL
BE OVERWRITTEN nameserver 127.0.1.1 search linuxmuster-net.lokal|

/etc/host.conf

|# The "order" line is only used by old versions of the C library.
order hosts,bind multi on|

und die auf dem Client auch …

LG

Holger

Hallo,

habe gerade die Doku zum Auslieferungszustand des IPfire entdeckt:
https://www.linuxmuster.net/wiki/dokumentation:handbuch:installation:ipfire.defaultconfig

Dort ist der Port 443 in den allowedports - bei mir aber nicht!

Das könnte doch die Lösung des Problems sein - oder was meint ihr - gibt es einen Grund, dass Port 443 nicht in der Liste sein sollte???

Gruß
Stefan

Hallo Stefan,

habe gerade die Doku zum Auslieferungszustand des IPfire entdeckt:
dokumentation:handbuch:installation:ipfire.defaultconfig [CommunityWiki]

Dort ist der Port 443 in den allowedports - bei mir aber nicht!

Das könnte doch die Lösung des Problems sein - oder was meint ihr - gibt
es einen Grund, dass Port 443 nicht in der Liste sein sollte???

bei mir steht https auch in der Gruppe allowedports …

LG

HOlger

Hallo,

Problem gelöst - die Suche funktioniert bei Google-Earth. Es war der fehlende Port 443 in den allowedports vom IPfire.
Der Port fehlte, weil ich nach einem Test vor einiger Zeit um anonymes Surfen effektiver zu verhindern, vergessen hatte, ihn nach der Löschung wieder hinzu zufügen.

Danke für die Unterstützung!!!
Stefan