Ei, yhteysmerkkijono ei voi käynnistää VPN-tunnelia

Kehittäjät etsivät edelleen paikkaa, jossa yhteysmerkkijono, JDBC-osoite tai tnsnames.ora-merkintä valitsee VPN:n. Sellaista paikkaa ei ole. Tunnelista vastaa käyttöjärjestelmä tai toimittajan asiakasohjelma, joka rekisteröi virtuaalisen sovittimen, ja jokainen sen yläpuolinen tietokantakirjasto käyttää syntyvää socket-kerrosta. Yhteysmerkkijono nimeää isäntänimen, portin ja tunnuksen, ja siinä on koko sanasto.

Myytti: yhteysmerkkijono voi valita tunnelin

Ajuri avaa TCP-socketin isäntään ja porttiin. Sillä ei ole rajapintaa tunnelin nostamiseen, ei kenttää tunneliprofiilille eikä tapaa todentaa VPN-yhdyskäytävään.

Siksi työkalut käyttäytyvät samoin, kun reitti on olemassa. SSMS, DBeaver, Eclipse Data Tools ja tavallinen sqlcmd toimivat kuin palvelin olisi lähiverkossa, koska socketin näkökulmasta se on. Virtuaalinen sovitin teki tietokannan aliverkon tavoitettavaksi, eikä ajuri koskaan tiedä miten.

Tämä selittää myös, miksi yhteysmerkkijono ei voi korjata katkennutta tunnelia. Kun linkki kuolee, ajuri ilmoittaa aikakatkaisusta tai yleisestä verkkoviasta, ja sovelluskoodi, joka pitää sitä kyselyongelmana, toistaa ikuisesti väärää kerrosta.

Nosta tunneli ennen kuin ajuri käynnistyy

Yhdistä VPN käyttöjärjestelmätasolla palveluntarjoajan tai verkkotiimin ohjeiden mukaan ja avaa työkalu vasta sitten. Käytännössä se tarkoittaa, että reitti tietokannan aliverkkoon on olemassa ennen kuin ajuri selvittää isäntänimen.

Pidä tunnelin valvonta sovelluksen ulkopuolella. PHP- tai Java-palvelu, joka yrittää nostaa linkin itse, koodaa yhden palveluntarjoajan käyttäytymisen liiketoimintakoodiin, ja jokaisesta vikasietotilanteesta tulee sovellusjulkaisu. Valvoja, joka omistaa tunnelin, tarkkailee sitä ja käynnistää sen uudelleen, on erillinen asia kyselypolusta.

Tarkista reitti ennen kuin syytät ajuria: jos isäntänimi ei selviä tai portti ei vastaa komentotulkista, mikään yhteysmerkkijono ei muuta sitä.

Myytti: Windows-todennuksen epäonnistuminen tarkoittaa, että reitti on rikki

Windows-todennus VPN:n yli epäonnistuu usein virheeseen, joka näyttää verkkovialta, vaikka reitti on kunnossa. Kun tili kuuluu toiselle toimialueelle eikä kannettava voi liittyä siihen, käynnistä asiakasohjelma nimenomaisilla tunnuksilla työpöytäistunnon identiteetin sijaan.

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

/netonly-kytkin säilyttää tunnukset vain etätodennukseen. Varmista SELECT SUSER_SNAME()-komennolla, mitä palvelin todella vastaanotti, sen sijaan että luottaisit yhteysvalintaikkunaan. Raporttien mukaan palvelimen osoitteen tunnuksen tallentaminen Windows Credential Manageriin toimii SSMS:ssä mutta ei aina toisen tilin alla ajettavassa palvelussa, joten tarkista ennen kirjautumisen muuttamista, mitä identiteettiä prosessi käyttää.

Viive muuttaa palvelinpuolen kohdistimen aikakatkaisuksi

Palvelinpuolen kohdistin pyytää tietokantaa pitämään tuloksen ja hakemaan sen asteittain, mikä muuttaa yhden suuren tuloksen moniksi pieniksi edestakaisiksi kierroksiksi. Lähiverkossa se on halpaa. Tunnelin yli, jossa on kymmeniä millisekunteja lisäviivettä, sama kysely voi ylittää komentojen aikakatkaisun siirtämättä juuri lainkaan dataa.

Vaihda asiakaspuolen kohdistimeen tai suurenna hakukokoa ja erottele rivit eriin, niin edestakaisten kierrosten määrä laskee. Pullonkaula on vaihtojen määrä, ei linkin nimellisnopeus, joten suorituskyvyn mittaaminen johtaa sinua harhaan, kun taas kierrosten mittaaminen ei. Testaa suurimmalla tulosjoukolla, jonka käyttäjäsi todella hakevat, älä yhden rivin kyselyllä, joka palaa heti. Jos aikakatkaisu siirtyy mutta ei katoa, suurenna komentojen aikakatkaisua ja hakukokoa yhdessä ja mittaa uudelleen.

Sama aritmetiikka pätee puheliaisiin ORM-kehyksiin ja jokaiseen asiakkaaseen, joka lähettää yhden lauseen riviä kohden. Jos kyselysuunnitelma on kunnossa ja siirto pieni, laske verkkoyhteyksien vaihdot ennen kuin virität tietokannan.

Tarkista portti, instanssi ja paikallinen suodatin

Nimetty instanssi kuuntelee dynaamisella portilla, joten vahvista portti sen sijaan että olettaisit 1433. Oletusinstanssissa arvo voidaan lukea TcpPort-rekisteriarvosta instanssin SuperSocketNetLib-avaimen alta. Oraclelle varmista, että tnsnames.oran isäntä selviää, että osoite vastaa ja että kuuntelijan portti on sallittu; 1521 on tavallinen oletusarvo, ei tae.

Sulje sitten pois tunnelin oma käyttöluettelo ja lopuksi paikallinen virustorjunta tai isäntäpalomuuri, joka estää yhteyden, vaikka asiakas ja palvelin olisivat samalla koneella. Tallenna epäonnistuva vaihe ennen asetusten muuttamista, koska nimenselvitys, TCP-tavoitettavuus ja TLS tai kirjautuminen epäonnistuvat kukin eri viestillä.

Kirjoita vaihe tikettiin. Muuten seuraava henkilö toistaa saman yhteysmerkkijonohakunsa, josta kaikki alkoi.