sporadischer Auth Timeout beim Zugriff auf Datenbanken

Heyho,

ich habe seit dem Update auf Postgres 9.3.10 das Problem, dass ich über VPN sporadisch Authentication-Timeouts vom Server bekomme. Ich hatte auch bereits das Authentication Timeout hochgestellt, hat das Problem aber leider nicht behoben.
Im Firewalllog sehe ich auch den Verbindungsaufbau, sieht alles sauber aus. Im Postgres-Log sieht man auch, dass sich jemand anmelden möchte, z.B.

...
2015-12-16 15:17:14 CET [unbekannt] [unbekannt] LOG:  00000: Verbindung empfangen: Host=<Host-IP> Port=48034
2015-12-16 15:17:14 CET [unbekannt] [unbekannt] ORT:  BackendInitialize, postmaster.c:3984
...

Es kommt dann (leider) sporadisch zu Authentifizierungsfehlern aufgrund eines Timeouts.

...
2015-12-16 15:19:15 CET <DB-Name> <Benutzername> FATAL:  57014: storniere Authentifizierung wegen Zeitüberschreitung
2015-12-16 15:19:15 CET <DB-Name> <Benutzername> ORT:  ProcessInterrupts, postgres.c:2944
...

Ich kann mir das leider nicht erklären. Im lokalen Netzwerk besteht das Problem nicht, nur über VPN. Der Serverauslastung liegt ca. bei 10% und die Backend-Connections sind zu ca 30% belegt.

Über die Debug-Log-Ausgabe bekomme ich leider auch nicht mehr Informationen (debug1)

Hat jemand eine Idee, waron das liegen könnte?


Grüße
KarlderHeinz


PS: Bei der vorherigen Version 9.3.6 war das Problem nicht vorhanden. Ich nutze das Postgres-Paket aus der openSuSE Paketverwaltung und habe den Server auch darüber aktualisiert.

Hat das VPN irgend welche Paketfilter? Irgend was in Richtung (reverse)DNS oder so würde ich erst einmal vermuten. Finden sich in anderen Logs (syslog, /var/log/messages etc.) Hinweise?

Hi,

danke für die flotte Antwort :slight_smile:

In den Systemlogs steht leider rein garnichts zu den Timeout-Fehler :confused:
Auf dem VPN-Tunnel werden Paketfilter eingesetzt, aber wir solche administrativen Tätigkeiten haben wir einen etrxa Management-Tunnel. Standard-Ports wie DNS und Ports für Postgres sind natürlich freigegeben. Auf der Firewall sehe ich auch kein Blocking. Ich habe die Verbindung auch schon mit einem tcpdump an beiden Enden überprüft, sieht alles normal aus. Zu dem Zeitpunkt, wo der Auth Timeout auftritt, ist der tcpdump natürlich länger, da er es mehrmals probiert. Dabei bekommt er auch eine Antwort vom Zielserver, wo der Auth Timeout letztendlich auftritt.

Ich habe leider keine Idee mehr was das sein könnte. Habt ihr noch eine Idee?


Grüße
Karl der Heinz!

“Zu dem Zeitpunkt, wo der Auth Timeout auftritt, ist der tcpdump natürlich länger, da er es mehrmals probiert.”

Daran könntest Du ansetzen. Warum probiert er mehrfach? Ist das lokal auch so? Routing-Probleme?