Hallo Leute,
ich scanne das internet schon ne ganze Weile nach einem ansich recht trivialen Problem (wie ich dachte).
Ich beabsichtige, für einen Kunden einen richtig dicken Postgres-Server mit entsprechender Bandbreite angebunden übers Internet bereitzustellen. Der Zugriff erfolgt von Windows-PC's aus über postgres win32 odbc Treiber.
Damit die Mitarbeiter auch auf den Server zugreifen können, bin ich nun gehalten, den Firewall-Administratoren eine Spezifikation zur erforderlichen Konfiguration an die Hand zu geben.
Nachdem deren Firewalling an Fort Knox erinnert (kein einziger offener Port vom Mitarbeiter-Arbeitsplatz), und sie neben circuit-firewalling auch firewalling auf application-level betrieben, bin ich etwas unsicher...
Und nun meine Frage:
Ist euch bekannt, ob der port 5432 (in and out) für die Kommunikation mit einem Postgresql-server absolut ausreicht oder verwendet Postgres weitere Ports die z.B. Daten zum client zurückführen, zb. für Query-Results, slave-connections, etc etc oder so... die gesondert freigegeben werden müssen.
Vielen Dank im Voraus
Jochen
Geändert von dasblauehandtuch (05.12.2007 um 08:52 Uhr)
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Hallo Andreas,
erstmal danke für Deine schnelle Antwort!
Tausend Dank, das wars, was ich gehofft hatte5432/TCP reicht aus.
Ja, absolut deiner Meinung, ist allerdings bei deren Infrastruktur nicht ohne weiteres umsetzbar, alleine in Deutschland haben die was um die 50 Standorte mit jeweils einem Internet-Gateway (und entsprechender Firewall). 50 Abteilungen davon zu überzeugen, ein VPN einzurichten würde zu lange dauern, der Server soll im Januar in produktion gehenIch würde dies aber nicht ohne Grund im Internet prostituieren, VPN-Lösungen existieren.![]()
Datenbank-Serverseitig wird nur Traffic von von deren Gateways akzeptiert werden, das geppart mit SSL-Verschlüsselung sollte fürs erste mal reichen.
VPN's kommen vielleicht später ins Spiel.
Yo, damit besteht aber das gleiche Problem wie bei nem klassischen VPN, nicht darstellbar derzeit.Und ein SSH-Tunnel ist die einfachste VPN-Lösung in diesem Falle.
Klar wird da NAT im Spiel sein, siehst du darin ein Problem?Das bei den Clients offensichtlich NAT im Spiel ist, ist Dir aber klar, oder?
Vielen Dank
Jochen
5432 sollte vollkommen ausreichen, PostgreSQL selber lauscht auch an keinem anderen Port ... so du dann auch wirklich 5432 konfiguriert hast ;-)
Das NAT sollte kein Problem darstellen, solange die Mitarbeiter nicht mal länger eine Datenbank Shell offen lassen als NAT seinen Timeout hat.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Nun ja.
Die Clients hier in der Firma z.B. haben kein NAT nach außen. Zum Pornoseitenbrausen *g* gibt es einen Proxy, für Mail einen internen Mailserver, der das dann macht. Ansonsten gibt es kein Routing von Clients (mein Rechner ausgenommen) nach außen. Das hat den Charme, daß, falls doch mal sich so ein Windoze was einfängt (was es in meiner Niederlassung noch nicht gab...), dieser dann nach außen keinen Schaden anrichtet. (es sei denn via dem Proxy). Außerdem kann keiner Dinge tun, die er nicht für die Arbeit braucht. Ich sag nur Tauschbörsen.
Will sagen: einerseits eine Konfiguration, wo Clients direkten Weg ins Internet haben und andererseits 'Firewalls'.
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Hallo Andreas,
danke für deine Antwort, jetzt bin ich verwirrt
Das bei den Clients offensichtlich NAT im Spiel ist, ist Dir aber klar, oder?Klar wird da NAT im Spiel sein, siehst du darin ein Problem?*g* Das entspricht ungefähr auch dem beschriebenen Szenario. Allerdings bin ich mir nicht recht sicher, ob ich Dich richtig verstehe, was den 'direkten' von Clients Zugang ins Netz angeht.Die Clients hier in der Firma z.B. haben kein NAT nach außen. Zum Pornoseitenbrausen *g* gibt es einen Proxy, für Mail einen internen Mailserver, der das dann macht. Ansonsten gibt es kein Routing von Clients (mein Rechner ausgenommen) nach außen.
Der übliche Weg (und den werden auch die Pakete zu meinem Datenbankserver gehen) sollte doch in deinem Netzwerkumfeld ebenso wie bei denen wiefolgt aussehen:
Client-> default internal Gateway -> ggf. weitere internal Gateways -> Firewall -> Internet -> Firewall von Datenbankserver -> Gateway von Datenbankserver-> Datenbankserver -> und wieder zurück
Das NAT übernimmt in jedem Fall doch deine (oder deren) Firewall, oder? Und da kannst Du doch dann fein einstellen, auf welche IP du welchen Port zulassen möchtest, oder?
Vielleicht tut sich grade eine Wissenslücke bei mir auf, aber über NAT, daher auch meine nochmalige Nachfrage, habe ich mir nie große Gedanken gemacht ...
Was für Probleme kann es damit geben, ausser vielleicht, dass es kein NAT gibt (wovon nicht auszugehen sein dürfte)
Danke im Vorraus
Jochen
Geändert von dasblauehandtuch (05.12.2007 um 12:04 Uhr)
Danke ads,
schon wieder was neues gelernt.
hmm, NAT timeoout klingt unschön.Das NAT sollte kein Problem darstellen, solange die Mitarbeiter nicht mal länger eine Datenbank Shell offen lassen als NAT seinen Timeout hat.
Hast Du auch ne Idee, wo dieser Timeout so ungefähr liegt? ... und was man dagegen unternehmen könnte? ... muss man denn gegen diesen Timeout überhaupt etwas unternehmen? ... und ob man den in einem hinreichend aufmunitionierten Systemunfeld irgendwo einstellen kann?
Mein infantiles Gemüt versucht mich grade dahingehend zu beruhigen, dass der Timeout garantiert nicht zwischen query und rückgabe der Ergebnisse auftreten wird, sondern wenn überhaupt irgendwann zwischen zwei queries, weil die faulen Mitarbeiter tatsächlich ne Mittagspause machen
Falls der Postgres-ODBC-Client vor jeder query einen neuen connect durchführt, sollte dies unschädlich sein ...
Oder könnte dein Kommentar gar bedeuten, dass Du davon ausgehst (erlebt hast), dass mit dem timeout-ereignis auch die gesamte odbc-verbindung abgebrochen wird und neu initialisiert werden muss ... ?
zum thema
Es wird nicht der Port 5432 werden, eher vielleicht der Port 54213 oder so. Denke, wenn der dann auch fein administriert wurde5432 sollte vollkommen ausreichen, PostgreSQL selber lauscht auch an keinem anderen Port ... so du dann auch wirklich 5432 konfiguriert hast ;-)dürfts egal sein, oder?
Danke im Voraus
Jochen
Sicher, wenn das sauber gemacht ist ist das alles kein Problem. In der Realität hatte ich mal das Vergnügen mit einer Firma, die ein nicht kleines Client-Netz hatten, von denen einer oder einige wenige verseucht waren. Da kamen hunderte Viren in kurzer Zeit her. Da dort alle Clients ungehindert NAT hatten, hatten die ein Problem. Und nach einem Tag oder so bat ich dann deren Provider, die abzuklemmen. Und dann war Ruhe. Schließlich sehe ich nicht ein, unsere Bandbreite als Lehrgeld für deren Blödheit zu opfern.
Also, ich hab nix gegen NAT, wenn es gebraucht wird. Deren EDV-Sicherheit scheint ja auch nicht Dein Problem zu sein, oder?
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Also zwischen Query und Ergebnis tritt der höchstens auf, wenn der Query paar Minuten braucht ;-)
Irgendwo in /proc kann man das auch konfigurieren, aber ich weiss nicht mehr, wo. Das habe ich das letzte Mal für 2.4 Linux Kernel gemacht und seitdem hat sich einiges getan.
Da kann ich dir zustimmen ;-)Mein infantiles Gemüt versucht mich grade dahingehend zu beruhigen, dass der Timeout garantiert nicht zwischen query und rückgabe der Ergebnisse auftreten wird, sondern wenn überhaupt irgendwann zwischen zwei queries, weil die faulen Mitarbeiter tatsächlich ne Mittagspause machen![]()
Ja, die Verbindung ist danach tot und muss neu aufgebaut werden. Alle Änderungen, die nicht committed sind, werden von PostgreSQL automatisch zurückgerollt.Falls der Postgres-ODBC-Client vor jeder query einen neuen connect durchführt, sollte dies unschädlich sein ...
Oder könnte dein Kommentar gar bedeuten, dass Du davon ausgehst (erlebt hast), dass mit dem timeout-ereignis auch die gesamte odbc-verbindung abgebrochen wird und neu initialisiert werden muss ... ?
Sollte kein Problem darstellen.Es wird nicht der Port 5432 werden, eher vielleicht der Port 54213 oder so. Denke, wenn der dann auch fein administriert wurdedürfts egal sein, oder?
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Hi ads,
Oder könnte dein Kommentar gar bedeuten, dass Du davon ausgehst (erlebt hast), dass mit dem timeout-ereignis auch die gesamte odbc-verbindung abgebrochen wird und neu initialisiert werden muss ... ?na das sind mal richtig schlechte nachrichtenJa, die Verbindung ist danach tot und muss neu aufgebaut werden. Alle Änderungen, die nicht committed sind, werden von PostgreSQL automatisch zurückgerollt.
Hast Du auch ne Lösung für das Problem gefunden? Regelmäßige pseudoqueries auf den server wäre das einzige, was mir dazu aus dem stehgreif einfällt ....
was meinst du?
Danke
Jochen
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen