Połączenie tunelowe VPN (ang. Virtual Private Network — wirtualna sieć prywatna) tworzy szyfrowany kanał komunikacyjny w publicznej sieci internetowej, dzięki któremu komputer znajdujący się poza biurem funkcjonuje logicznie tak, jakby był wpięty bezpośrednio do lokalnej sieci firmowej. W momencie uruchomienia programu handlowo-magazynowego na komputerze pracownika zdalnego aplikacja wysyła zapytania do silnika bazy danych umieszczonego na komputerze głównym w biurze. Pakiety danych są hermetyzowane i szyfrowane wewnątrz tunelu, po czym trafiają do routera brzegowego w firmie, który odszyfrowuje ruch i przekazuje go do właściwego zasobu sieciowego. Gdy którykolwiek z elementów tego łańcucha — od translacji adresów, przez routing, aż po uprawnienia zapory sieciowej — jest niepoprawnie skonfigurowany, oprogramowanie handlowe nie może nawiązać sesji lub traci łączność w trakcie pracy.

Typowe trudności przy wdrażaniu nowego stanowiska zdalnego

Wdrożenie nowego pracownika zdalnego do obsługi systemu handlowo-magazynowego wiąże się zazwyczaj z koniecznością zapewnienia dostępu do kartotek towarowych, wystawiania dokumentów sprzedaży oraz sprawdzania stanów magazynowych w czasie rzeczywistym. Podczas próby uruchomienia takiego stanowiska pojawiają się charakterystyczne komunikaty błędów i objawy, które użytkownicy zgłaszają podczas rozmowy telefonicznej:

  • Brak możliwości połączenia z bazą danych — program handlowy wyświetla komunikat informujący, że serwer bazy danych jest nieosiągalny, mimo że na komputerze domowym działa przeglądarka internetowa i sam tunel VPN zgłasza stan aktywny.
  • Zrywanie sesji podczas generowania dokumentów — aplikacja uruchamia się poprawnie, lecz przy próbie otwarcia listy kontrahentów, filtrowania bazy lub zatwierdzenia faktury dochodzi do zamrożenia interfejsu i wymuszonego zamknięcia programu.
  • Niezgodność adresacji sieciowej — połączenie VPN zestawia się, lecz użytkownik nie może otworzyć żadnego folderu sieciowego ani spingować komputera z bazą danych (polecenie ping służy do weryfikacji drożności trasy i odpowiedzi hosta docelowego).
  • Konflikt uprawnień użytkownika — program zgłasza błąd autoryzacji silnika bazy danych lub brak dostępu do klucza licencyjnego przypisanego do stanowiska.
  • Brak widoczności nazwy komputera głównego — aplikacja próbuje połączyć się z serwerem po nazwie sieciowej zamiast po stałym, lokalnym adresie IP, co przy braku wewnętrznego serwera nazw (DNS) w tunelu uniemożliwia translację adresu.

Dlaczego program handlowy nie łączy się przez VPN — przyczyny techniczne

Niepowodzenie przy uruchamianiu zdalnego dostępu do bazy handlowej wynika zazwyczaj z konfiguracji sieciowej, specyfiki protokołów bazodanowych lub ograniczeń samego oprogramowania. Przyczyny ułożone od najczęstszych do rzadziej spotykanych:

1. Nakładanie się podsieci (konflikt adresacji IP)

To najczęstsza przyczyna problemów z routingiem w tunelach VPN. Jeśli domowy router nowego pracownika przydziela adresy z tej samej puli co router w firmie (np. domyślna podsieć wielu popularnych routerów domowych), system operacyjny laptopa nie potrafi jednoznacznie określić, czy pakiet skierowany do bazy danych ma pozostać w sieci domowej, czy przejść przez tunel do biura. Ruch sieciowy gubi się, a program handlowy nie otrzymuje odpowiedzi.

2. Brak translacji nazw DNS wewnątrz wirtualnej sieci prywatnej

Wiele programów handlowych jest skonfigurowanych w oparciu o nazwę komputera głównego, a nie jego adres liczbowy. Po zestawieniu tunelu VPN komputer zdalny często korzysta z domowych serwerów DNS dostawcy Internetu, które nie znają nazw urządzeń wewnątrz biura. W rezultacie aplikacja nie wie, pod jaki adres skierować zapytanie bazodanowe.

3. Blokowanie portów przez zaporę sieciową (firewall) i oprogramowanie ochronne

Silniki baz danych wykorzystywane przez programy handlowo-magazynowe komunikują się na ściśle określonych portach TCP/UDP. Jeśli zapora sieciowa na komputerze pracownika lub na komputerze głównym w biurze traktuje nowe połączenie tunelowe jako sieć publiczną (niezaufaną), pakiety bazodanowe są odrzucane na poziomie reguł bezpieczeństwa.

4. Architektura programu handlowego nieprzystosowana do pracy w sieci rozległej (WAN)

Część starszych systemów handlowych to aplikacje typu plik-baza (gdzie cały plik z danymi jest odczytywany bezpośrednio przez sieć lokalną) lub aplikacje wymagające bardzo niskich opóźnień (ang. latency). Połączenie internetowe przez VPN, nawet stabilne, generuje wyższe opóźnienia niż kabel sieciowy w biurze. Skutkuje to ogromnym spowolnieniem pracy lub błędami blokady rekordów przy próbie zapisu.

5. Ograniczenia licencji stanowiskowych i mechanizmów autoryzacji

Programy handlowe weryfikują liczbę aktywnych stanowisk za pomocą serwera licencji sieciowej lub kluczy sprzętowych. Gdy nowy pracownik próbuje uruchomić program, serwer licencji może odrzucić połączenie z powodu wyczerpania puli stanowisk lub braku uprawnień konta użytkownika w strukturze bazodanowej.

6. Fragmentacja pakietów i niepoprawny parametr MTU

Parametr MTU (ang. Maximum Transmission Unit) określa maksymalny rozmiar pakietu przesyłanego w sieci. Tunel VPN dodaje do każdego pakietu własny nagłówek szyfrujący, co zmniejsza dostępną przestrzeń na właściwe dane. Jeśli rozmiar pakietu przekracza limit routera, pakiet musi zostać podzielony (pofragmentowany). W przypadku zablokowania mechanizmu fragmentacji na trasie internetowej dochodzi do niewyjaśnionych zawieszeń programu przy przesyłaniu większych tabel danych.

Kiedy to nie jest ta usterka

Zanim rozpocznie się przebudowę konfiguracji tunelu VPN lub rekonfigurację bazy danych, należy wykluczyć inne źródła problemu, które dają zbliżone objawy:

  • Awaria łącza internetowego w biurze lub u pracownika — niestabilne połączenie bezprzewodowe Wi-Fi w mieszkaniu pracownika (np. duża utrata pakietów, zakłócenia sygnału) powoduje zrywanie tunelu, co jest problemem fizycznej transmisji radiowej, a nie konfiguracji VPN.
  • Zablokowane konto pracownika w programie — błąd logowania wynikający z nieprawidłowego hasła, braku nadanych ról w systemie handlowym lub wygaśnięcia konta użytkownika nie jest usterką sieciową.
  • Wyłączony komputer pełniący rolę serwera w firmie — jeśli główny komputer z bazą danych został uśpiony przez mechanizmy oszczędzania energii w systemie operacyjnym, żadne stanowisko (zarówno lokalne, jak i zdalne) nie uzyska dostępu do bazy.
  • Uszkodzenie struktury samej bazy danych — jeśli program nie uruchamia się także na komputerach stacjonarnych w biurze, problem leży w integralności bazy lub zatrzymaniu samej usługi bazodanowej, a nie w dostępie zdalnym.

Przebieg konfiguracji i diagnostyki dostępu zdalnego

Prawidłowe wdrożenie bezpiecznego dostępu do oprogramowania handlowego przez VPN wymaga uporządkowanego podejścia technicznego. Na miejscu u klienta serwis wykonuje pełną diagnostykę środowiska sieciowego oraz wdraża odpowiednie mechanizmy transmisji danych.

Diagnostyka środowiska i topologii sieci

Prace rozpoczynają się od weryfikacji adresacji IP po obu stronach połączenia. Sprawdzane są tablice routingu (ścieżki przepływu pakietów w systemie operacyjnym), status działania usługi serwera bazy danych oraz drożność portów komunikacyjnych za pomocą narzędzi diagnostycznych sieci. Weryfikacji podlega również stabilność łącza internetowego oraz parametry opóźnień.

Wdrożenie tunelu VPN i trasowania pakietów

Konfigurujemy bezpieczne szyfrowane połączenie tunelowe pomiędzy komputerem pracownika zdalnego a siecią biurową. W zależności od posiadanych przez klienta urządzeń sieciowych zestawiane jest połączenie oparte o bezpieczne protokoły szyfrujące z certyfikatami i kluczami wymiany. Ustawiamy statyczny routing, aby wyłącznie ruch skierowany do firmowej bazy danych przechodził przez zaszyfrowany tunel, podczas gdy prywatny ruch internetowy pracownika może pozostać poza siecią firmową (ang. split tunneling — dzielone tunelowanie), co odciąża łącze w biurze.

Konfiguracja połączenia programu z bazą danych

Dostosowujemy pliki konfiguracyjne programu handlowego na komputerze pracownika. Zamiast zmiennych nazw sieciowych wprowadzamy bezpośrednie adresowanie IP serwera wewnątrz wirtualnej sieci prywatnej. Tworzymy reguły w zaporze sieciowej systemu operacyjnego, przypisując tunel VPN do profilu sieci prywatnej i odblokowując wyłącznie niezbędne porty dla silnika bazodanowego oraz menedżera licencji.

Wdrożenie alternatywnego dostępu terminalowego

W sytuacji, gdy aplikacja handlowo-magazynowa posiada architekturę uniemożliwiającą wydajną pracę bezpośrednio przez tunel VPN (ze względu na przesyłanie zbyt dużych ilości danych przez łącze o ograniczonej przepustowości), konfigurujemy bezpieczny dostęp terminalowy (RDP — ang. Remote Desktop Protocol) wewnątrz tunelu VPN. W takim scenariuszu program handlowy działa bezpośrednio na maszynie w biurze, a przez szyfrowany tunel przesyłany jest wyłącznie obraz pulpitu i sygnały klawiatury oraz myszy. Eliminuje to ryzyko uszkodzenia bazy danych przy nagłym rozłączeniu Internetu domowego.

Czego nie robić i co można sprawdzić przed wezwaniem pomocy

Nieprawidłowe próby samodzielnego wymuszenia połączenia mogą prowadzić do obniżenia bezpieczeństwa całej sieci firmowej lub uszkodzenia plików bazy danych.

Czego nie wolno robić na własną rękę:

  • Nie wolno całkowicie wyłączać zapory sieciowej (firewalla) ani programu antywirusowego — otwiera to sieć na nieautoryzowany dostęp z zewnątrz. Prawidłowe rozwiązanie polega na dodaniu precyzyjnych reguł dla konkretnych portów, a nie na wyłączaniu ochrony.
  • Nie należy przekierowywać portów bazy danych bezpośrednio na publiczny adres IP routera bez tunelu VPN — wystawienie silnika bazy danych bezpośrednio do otwartego Internetu jest poważnym błędem bezpieczeństwa, narażającym firmę na ataki typu brute-force i zaszyfrowanie danych przez złośliwe oprogramowanie.
  • Nie należy wymuszać zamykania zawieszonego programu handlowego przez menedżer zadań podczas operacji zapisu — gwałtowne przerwanie sesji podczas transakcji bazodanowej może skutkować uszkodzeniem tabeli lub zablokowaniem rekordów dla pozostałych pracowników w biurze.

Co można zweryfikować samodzielnie:

  • Sprawdzić, czy komputer główny (serwer) w biurze jest włączony, zalogowany i ma stały dostęp do Internetu.
  • Podłączyć komputer zdalny do domowego routera za pomocą kabla sieciowego Ethernet zamiast Wi-Fi, aby wyeliminować wpływ niestabilnego sygnału bezprzewodowego.
  • Upewnić się, czy aplikacja klienta VPN nawiązuje połączenie i otrzymuje wewnętrzny adres IP z puli firmowej.
  • Zrestartować domowy router pracownika w celu odświeżenia tablicy połączeń u lokalnego operatora telekomunikacyjnego.

Współpraca z serwisem i organizacja obsługi

Zapewnienie stabilnej i bezpiecznej łączności zdalnej dla nowych pracowników wymaga precyzyjnego dopasowania parametrów sieciowych do używanego oprogramowania biznesowego. Serwis realizuje usługi wyłącznie w formule bezpośredniego dojazdu do klienta na terenie Warszawy oraz okolicznych powiatów podwarszawskich.

Obsługa prowadzona jest przez całą dobę, 7 dni w tygodniu, również w dni wolne od pracy, co pozwala na przeprowadzenie prac wdrożeniowych i konfiguracyjnych w godzinach, w których program handlowy nie jest intensywnie używany przez pozostały personel biura. Zawsze przed przystąpieniem do jakichkolwiek działań technicznych przeprowadzana jest diagnoza oraz przedstawiana indywidualna wycena prac do akceptacji.

Większość prac konfiguracyjnych związanych z siecią, uprawnieniami, oprogramowaniem handlowym i tunelami VPN realizujemy bezpośrednio na miejscu u klienta — zarówno w biurze firmy, jak i w miejscu pracy zdalnej pracownika. W sytuacji, gdy komputer wymaga dodatkowych prac warsztatowych lub modernizacji sprzętowej pod kątem wydajności, odbieramy sprzęt i odwozimy go po zakończonej procedurze testowej własnym transportem. W przypadku konieczności zachowania szczególnych procedur bezpieczeństwa, na życzenie klienta bezpłatnie podpisujemy umowę o poufności (NDA).

W celu zamówienia wizyty serwisowej oraz skonfigurowania bezpiecznego dostępu zdalnego do programu handlowego prosimy o kontakt telefoniczny pod numerem 22 257 87 54.