Svenska ElektronikForumet

Hej alla !

Har tagit in ett nyckelskåp på prov, på jobbet. Modell "lyxigare" med elektronisk styrning och nätverksanslutning och möjlighet att lägga upp användare och koder
Modellen heter: Creone 9500 SC
Programvaran: Keywin

Detta skåp pratar med en SQL server på samma nätverk som den själv. "Klienterna", alltså som man använder för att koppla upp mot SQL databasen och göra alla inställningar. Dessa klienter fungerar utmärkt att ansluta mot SQL'en när man ligger på samma nätverk. Men så fort man sätter sig med klienten vid ett annat nätverk, WAN anslutning, så tappar den kontakten.

Har öppnat all form av brandväggar i vägen, kört den riktiga servern i DMZ, kört testserver i VMWARE och använt en mobil anslutning enbart för den.
Har följt dom 15-20 första länkarna man hittade på google vid sök på "SQL Express 2008 Remote Connection".
Alltså under "Protocols" aktiverat "TCP/IP" och ställt in IP adresser.

Har varit i kontakt med tillverkaren och den jag pratade med hade inte hört något om det förut...
Fast han kunde höra med några andra om jag återkom till honom.

Men jag tänkte höra här på forumet i alla fall, forumets samlade kunskap är ofattbart stor

Vad använder klienterna för att snacka med servern ?
ODBC ? JDBC ? Något annat ?

Det vet jag tyvärr inte. Det måste jag ta med tillverkaren.
Det gör det ganska svårt att se vad felet är då klientprogramvaran bara presenterar en ruta där man får fylla i en IP-Adress, sedan svarar den med om det går att ansluta eller ej

Skulle chansa på JDBC, fick upp en ruta om att programvaran krävde någon uppdaterad java komponent för att installera, kan ju dock varit något annat.
Får nog ta och engagera dom som skrivit programmet i detta, dom vet ju garanterat exakt vad som används

Tack så länge

Prova med VPN.

Antagligen är anslutningen inte krypterat och då är det förkastligt att öppna brandväggarna och ansluta via WAN.

Vilket operativsystem rör det sig om?

Använt tcpdump, eller ethereal?

VPN vore nog en bra lösning, både med tanke på säkerhet och....."smidighet innan vi når en fungerande lösning" eller vad man skall säga

Men, klienterna som skall ansluta ligger idag på ett företagsnätverk för att komma åt internet och verksamhetssystem.
Om man ansluter med datorn över VPN, försöker den då köra all kommunikation över tunneln ?

Det beror helt på hur du konfigurerar ditt VPN, det går att skapa en route som bara gäller sql-servern.

blueint skrev:Vilket operativsystem rör det sig om?

Använt tcpdump, eller ethereal?

Windows Server 2003 är operativsystemet som körs.

Tcpdump, ethereal är någon form av verktyg för att se vilka datapaket som skickas från/till burken ?
Dessa vet jag ingenting om men känns som att det skulle hjälpa mig en hel del.

Brandväggen var första hindret för att ens få igång det inom egna nätverket. Men där loggade jag och kunde läsa av loggfilerna vilka portar som användes så det löste sig bra.

Nu har jag fått in "Management Studio" i SQL Express 2008 och läst igenom loggfiler men kan inte hitta någonting som stämmer överens med mina inloggningsförsök.

mrfrenzy skrev: Det beror helt på hur du konfigurerar ditt VPN, det går att skapa en route som bara gäller sql-servern.

Okej, bra att veta, fast jag känner mig väldigt främmande för VPN.
Det innebär att jag måste in med inställningar i våra "IT-Datorer", och där har vi en IT-Avdelning som inte är "av denna jord" utan mer "du skall icke några andra gudar hava jämte oss..."

När du sitter med klienten på samma nät (d.v.s. när det funkar), så kör
kommandot "netstat" på klienten så ser du dina aktiva anslutningar och vilka portar som används.

SQLServer över tcp/ip är som standard konfigurerad att köra på port 1433 om jag inte minns
helt galet.

/johan

Använd t.ex tcpdump och ta reda på vad som faktiskt går snett.

Vid ett annat nätvärk säger du, då antar jag att det är en annan IP adress in på servern och ett annat fysiskt nätverks kort har du kontrollerat så att SQL servern svarar på den anslutningen?
Denna länk ger lite information om olika anslutningars konfiguration. Sql server management studio är ett bra verktyg för att kontrollera kontakten med servern från din WAN punkt.

> Får nog ta och engagera dom som skrivit programmet i detta, dom vet ju garanterat exakt vad som används

Ja, det är ju det självklara alternativet *innan* man snor gratistid från ett forum...

> Skulle chansa på JDBC, fick upp en ruta om att programvaran krävde någon uppdaterad java
> komponent för att installera, kan ju dock varit något annat.

OK. Det är in viktig information. Java's funktioner för remote-call (RMI) har problem
att köra över NAT'ade nät by-default. Jag kämpade mycket med ett för
något år sedan (även med hjälp av en tekniker från Oracle som loggade in
på min laptop i köket remote från sitt kök i USA !), men fick det aldrig att
snurra. Jag skulle köra en Netbeans applikation hemmifrån ut från vårat privata
NAT'ade ADSL nät mot mon server på mitt NAT'ade kontorsnät. Det kan ha varit
att det var NAt när i båda ändar som gjorde att vi aldrig fick det att fungera.

Hur som helst, problemet med RMI är att de olika komponenterna lägger de
IP adresser som den andra änden verkar ha i själva RMI datat. Eftersom detta
alltså är de publika adresserna, och att de sedan jämförs med klienterns (eller
om det var serverns) egen adress, så smäller det av.

Lösningen är att hårdkoda den andra ändens IP adress genom en konfigurering
i Java miljön. Googla gärna på "java remote method invocation NAT" så får du
lite olika forum där detta diskuteras inkl en del förslag till lösningar.

En annan lösning är att *inte* köra RMI/Java/JDBC utan vanlig ODBC. Då får
man öppna lite andra portar och så, men det är "som vanligt".

> SQLServer över tcp/ip är som standard konfigurerad att köra på port 1433
> om jag inte minns helt galet.

Det är nog den vanliga SQLServer porten (som t.ex ODBC använder), inte JDBC
porten viket är 1099 by default.

> Men, klienterna som skall ansluta ligger idag på ett företagsnätverk för att
> komma åt internet och verksamhetssystem.
Och :
> Men så fort man sätter sig med klienten vid ett annat nätverk, WAN anslutning, så tappar den kontakten.

Du får nog beskriva lite bättre vad du menar med "företagsnätverk", "annat nätverk", "WAN" o.s.v.
Om du har ett WAN som enbart betyder routade arear inom samma privata nätverk (utan att
NAT'a över ett publikt nät), d.v.s där alla klienter och server ser den faktiskta IP adressen
hos motparten, så är det ju en sak. Annars är det en annan sak...

Funderat lite till...

Jag är inte 100% säker att JDBC och RMI portarna är samma
eller hänger ihop, så glöm det så länge...

Det viktigaste om du vill ha hjälp *här* på forumet
är att bättre beskriva mijön (nät o.s.v).

Cryptomaster skrev: Okej, bra att veta, fast jag känner mig väldigt främmande för VPN.
Det innebär att jag måste in med inställningar i våra "IT-Datorer", och där har vi en IT-Avdelning som inte är "av denna jord" utan mer "du skall icke några andra gudar hava jämte oss..."

Snabbaste lösningen på hela problemet är antagligen att be it-avdelningen sätta upp ett VPN mellan sql-servermaskinen och dom burkar som behöver köra fjärradministrationen, sedan är det hela klart.

Mest korrekta lösningen är att be IT-avd fixa det. Punkt.
Man behöver inte bry sig om *hur* de fixar det. Och *de*
ska ta kontakten med leverantören, om det behövs.
Nästa steg är eskallering via sin chef...