Nem, a kapcsolati sztring nem indíthatja el a VPN-alagutat

A fejlesztők még mindig azt a helyet keresik, ahol egy kapcsolati sztring, egy JDBC URL vagy egy tnsnames.ora bejegyzés kiválasztja a VPN-t. Ilyen hely nincs. Az alagutat az operációs rendszer vagy egy szállítói kliens hozza létre, amely virtuális adaptert regisztrál, és minden felette lévő adatbázis-könyvtár az ebből adódó socketréteget használja. A kapcsolati sztring gazdagépet, portot és hitelesítő adatot nevez meg, és ez a teljes szókészlet.

Tévhit: a kapcsolati sztring kiválaszthat alagutat

Az illesztőprogram TCP-socketet nyit egy gazdagéphez és porthoz. Nincs API-ja alagút felhozatalára, nincs mezője alagútprofilhoz, és nincs módja VPN-átjáróhoz hitelesíteni.

Ezért viselkednek az eszközök azonosan, ha létezik útvonal. Az SSMS, a DBeaver, az Eclipse Data Tools és egy egyszerű sqlcmd úgy viselkedik, mintha a kiszolgáló a helyi hálózaton lenne, mert a socket szemszögéből az is. A virtuális adapter elérhetővé tette az adatbázis-alhálózatot, és az illesztőprogram soha nem tudja, hogyan.

Ez magyarázza azt is, miért nem tud egy kapcsolati sztring helyreállítani egy megszakadt alagutat. Amikor a kapcsolat meghal, az illesztőprogram időtúllépésről vagy általános hálózati hibáról számol be, és az alkalmazáskód, amely ezt lekérdezési problémának tekinti, örökre a rossz réteget ismétli.

Hozza fel az alagutat, mielőtt az illesztőprogram fut

Csatlakoztassa a VPN-t operációs rendszer szinten, a szolgáltató vagy a hálózati csapat utasításai szerint, és csak utána nyissa meg az eszközt. A gyakorlatban ez azt jelenti, hogy létezik útvonal az adatbázis-alhálózat felé, mielőtt az illesztőprogram feloldja a gazdagépnevet.

Tartsa az alagút felügyeletét az alkalmazáson kívül. Egy PHP vagy Java szolgáltatás, amely maga próbálja felhozni a kapcsolatot, egy szolgáltató viselkedését kódolja az üzleti logikába, és minden feladatátvétel alkalmazáskiadás lesz. Az a felügyelő, amely birtokolja az alagutat, figyeli és újraindítja, külön kérdés a lekérdezési úttól.

Ellenőrizze az útvonalat, mielőtt az illesztőprogramot hibáztatja: ha a gazdagép nem oldódik fel, vagy a port nem válaszol a héjból, egyetlen kapcsolati sztring sem változtat ezen.

Tévhit: a Windows-hitelesítés hibája azt jelenti, hogy az útvonal törött

A Windows-hitelesítés VPN-en keresztül gyakran hálózati hibára emlékeztető hibával hiúsul meg, miközben az útvonal rendben van. Ha a fiók másik tartományhoz tartozik, és a laptop nem tud csatlakozni hozzá, indítsa a klienst kifejezett hitelesítő adatokkal az asztali munkamenet identitása helyett.

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

A /netonly kapcsoló csak a távoli hitelesítéshez tartja meg ezeket az adatokat. Ellenőrizze SELECT SUSER_SNAME() segítségével, hogy a kiszolgáló valójában mit kapott, ahelyett hogy a kapcsolati párbeszédre bízna. Beszámolók szerint a kiszolgálócím hitelesítő adatainak tárolása a Windows Credential Managerben működik az SSMS esetében, de nem mindig egy másik fiók alatt futó szolgáltatásnál, ezért a bejelentkezés módosítása előtt ellenőrizze, melyik identitást használja a folyamat.

A késleltetés időtúllépéssé teszi a kiszolgálóoldali kurzort

A kiszolgálóoldali kurzor arra kéri az adatbázist, hogy tartsa meg az eredményt és fokozatosan hozza azt, ami egy nagy eredményt sok kis oda-vissza úttá alakít. LAN-on ez olcsó. Egy alagúton keresztül, amely több tíz milliszekundum extra késleltetést ad, ugyanaz a lekérdezés túllépheti a parancs időtúllépését anélkül, hogy szinte semmit ne továbbítana.

Váltson kliensoldali kurzorra, vagy növelje a lekérési méretet és csoportosítsa a sorokat, és csökken az oda-vissza utak száma. A szűk keresztmetszet a cserék száma, nem a kapcsolat névleges sebessége, ezért az átviteli teljesítmény mérése félrevezeti Önt, az oda-vissza utaké nem. A legnagyobb olyan eredménykészlettel teszteljen, amelyet a felhasználói ténylegesen lehúznak, ne egy azonnal visszatérő egysoros lekérdezéssel. Ha az időtúllépés elmozdul, de nem tűnik el, növelje egyszerre a parancs időtúllépését és a lekérési méretet, majd mérjen újra.

Ugyanez az aritmetika érvényes a fecsegő ORM-ekre és minden olyan kliensre, amely soronként egy utasítást ad ki. Ha a lekérdezési terv rendben van és az átvitel kicsi, számolja meg a hálózati cseréket, mielőtt az adatbázist hangolja.

Ellenőrizze a portot, a példányt és a helyi szűrőt

Egy elnevezett példány dinamikus porton figyel, ezért erősítse meg a portot ahelyett, hogy 1433-at feltételezne. Alapértelmezett példányon az érték a TcpPort beállításjegyzék-értékből olvasható ki a példány SuperSocketNetLib kulcsa alatt. Oracle esetében ellenőrizze, hogy a tnsnames.ora gazdagépe feloldódik, hogy a cím válaszol, és hogy a figyelő port engedélyezett; az 1521 gyakori alapértelmezés, nem garancia.

Ezután zárja ki magának az alagútnak a hozzáférési listáját, végül pedig egy helyi vírusirtót vagy gazdagépi tűzfalat, amely akkor is blokkolja a kapcsolatot, ha a kliens és a kiszolgáló ugyanaz a gép. Rögzítse a meghiúsuló szakaszt a konfiguráció módosítása előtt, mert a névfeloldás, a TCP elérhetőség és a TLS vagy bejelentkezés mindegyike más üzenettel hibázik.

Írja be a szakaszt a jegybe. Különben a következő ember megismétli ugyanazt a kapcsolati sztring keresést, amellyel minden elkezdődött.