Puncte:0

Scriptul SQL Developer PL/SQL nu reușește să afișeze rezultatul prin OpenVPN după rularea unui anumit interval de timp

drapel in

Problema:

Când încerc să rulez colectarea statisticilor prin OpenVPN în baza mea de date Oracle 19c, SQL Developer nu returnează mesajul tipic „Procedura PL/SQL finalizată cu succes” dacă rulează mai mult de o anumită perioadă de timp.

Aparent, conexiunea se blochează după un timp și fie trebuie să mă deconectez de la OpenVPN, fie să omor SQL Developer în Windows Task Manager pentru a o închide.

Baza mea de date Oracle 19c și serverul OpenVPN sunt pe diferiți furnizori de cloud.

Rularea statisticilor de adunare pe această bază de date durează de obicei aproximativ o jumătate de oră.

Rularea comenzii gather stats pe SQL Developer

Ce am verificat:

  1. Nimic neobișnuit în jurnalele Iptables și OpenVPN de pe serverul OpenVPN sau în jurnalele de ascultător și alertă de pe serverul Oracle 19c.

  2. net.ipv4.tcp_keepalive_time și net.netfilter.nf_conntrack_tcp_timeout_established sunt setate la valorile implicite de 7200 (2 ore) și 432000 (5 zile) pe ambele mașini.

  3. Dacă mă conectez la baza de date ca sistem și rulez:

    selectați x.sid, x.serial#, x.username, x.status, x.osuser, x.machine, x.program, x.event, x.state, sql.sql_text din v$sqlarea sql, v$session x unde x.sql_hash_value = sql.hash_value și x.sql_address = sql.address și x.username = 'myuser';

După aproximativ o jumătate de oră, am observat că sesiunea pentru colectarea statisticilor este inactivă. Deci presupun că colectarea statisticilor rulează și se termină cu succes, dar pur și simplu nu returnează mesajul de ieșire menționat mai sus.

Adunați statistici care rulează în baza de date

Sesiunea de statistici adună inactivă după aproximativ o jumătate de oră

Ce am incercat:

  1. Pe o bază de date mai mică în aceeași instanță, rularea gather stats prin OpenVPN returnează mesajul de succes menționat mai sus. Acesta durează aproximativ 10 minute.

  2. Conectarea directă (fără OpenVPN) la baza de date prin adăugarea adresei mele IP la firewall-ul furnizorului de cloud și rularea statisticilor gather returnează, de asemenea, mesajul de succes menționat mai sus.

  3. Generarea unei perechi de chei publice/private SSH pe serverul Oracle 19c și utilizarea SSH Hosts pe SQL Developer, dar conexiunea este foarte instabilă/se resetează întotdeauna.

  4. Configurarea unui server proxy Dante. Aparent, SQL Developer poate folosi doar un fel de server proxy special.

  5. Configurarea unui VPN IPSEC cu StrongSwan. Windows-ul meu 10 nu a putut stabili o conexiune cu acesta din anumite motive.

Phill  W. avatar
drapel cn
Nu vreau să plouă pe parada ta, dar '19 nu face asta de la sine, automat?
js1018 avatar
drapel in
Dacă este cazul, nu eram conștient de asta. Chiar și așa, problema rămâne. Nu am încercat, dar se presupune că acest lucru se va întâmpla și cu orice alt script PL/SQL care rulează între 10 și 30 de minute peste OpenVPN.
Puncte:0
drapel in

În primul rând, am putut confirma că colectarea statisticilor se încheie într-adevăr cu succes rulând:

selectați * din v$session_longops unde opname ca '%Schema%' ordonat după start_time desc;

După aceea, am rulat următoarele comenzi tcpdump pe ambele servere:

tcpdump -i eth0 -A "(src <myipaddress> sau src <myoracle19caddress> sau dst <myipaddress> sau dst <myoracle19caddress>) și nu port ssh și nu port openvpn și nu icmp" (OpenVPN Server)

tcpdump -i eth0 -A "(src <myipaddress> sau src <myopenvpnserveraddress> sau dst <myipaddress> sau dst <myopenvpnserveraddress>) și nu port ssh și nu icmp" (Oracle 19c Server)

Și am descoperit că serverul Oracle 19c a trimis mesajul de succes, dar serverul OpenVPN nu l-a primit niciodată.

După ce am săpat pe diverse site-uri, am aflat că am înțeles greșit ce face de fapt net.ipv4.tcp_keepalive_time.

Aceasta înseamnă că [în mod implicit] rutinele keepalive așteaptă două ore (7200 secunde) înainte de a trimite prima sondă keepalive, apoi retrimiteți-l la fiecare 75 secunde.

După aceea am aflat despre o configurație de rețea a furnizorului de cloud unde am găzduit serverul meu OpenVPN.

Conexiuni inactiv

[...] implementați urmărirea conexiunii de 10 minute pentru Protocoale IP care au un concept de conexiune. Aceasta înseamnă că pachetele de intrare asociate cu o stabilită conexiunea sunt permise atâta timp cât este trimis cel puțin un pachet sau primit pentru conexiune în ultimele 10 minute. Dacă nu există pachete pentru conexiune au fost trimise sau primite timp de 10 minute sau mai mult timp, intrările de urmărire ale conexiunii inactive sunt eliminate. După intrările de urmărire ale conexiunii au fost eliminate, [...] nu permiteți pachete suplimentare de intrare până la cel puțin o nouă ieșire pachetul a fost trimis. Această urmărire a conexiunii se aplică tuturor surselor și destinații â atât adrese IP interne, cât și externe.

Cu aceste noi informații, am ocolit această limitare setând timpul de păstrare la o valoare mai mică de 10 minute, rulând următoarea comandă pe serverul Oracle 19c:

sysctl -w net.ipv4.tcp_keepalive_time=300 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=5

Și a făcut aceste modificări permanente salvându-le în /etc/sysctl.conf.

În cele din urmă, SQL Developer primește mesajul de succes și închide conexiunea.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.