Android VpnService: blockéiert TUN-Liesen géint ENOBUFS-Schreiffehler

Zwou Symptomer erschénge an der selwechter VpnService-Schleif an et gëtt déiselwecht Saach beschëllegt: e Lieser deen ni zréckkënnt, an eng Schreifweis déi mat ENOBUFS feelt. Dat sinn net Variante vun engem Bug. Eng blockéiert Liesung ass eng Onmeenigkeit iwwer d'Flosskontroll mam Peer; eng feelgeschloe Schreifweis ass e Pak dat den Interface net unhëlt. Wann Dir se als ee Problem behandelt, verbréngt Dir en Dag mat Puffer ze justéieren déi ni bedeelegt waren. D'Opdeelung hei drënner ass wéi ech entscheeden, wéi eng Hallschent vun der Schleif ech fir d'éischt instrumentéieren.

Eng Schleif, zwee onofhängeg Feelerpunkten

Ären Service liest en IP-Pak aus dem TUN-Dateideskriptor, iwwerpréift en a schreift eng Äntwert zréck an deenselwe Descriptor. Alles wat op deem Wee brécht, daucht bei engem vun deenen zwee Uruff op, dofir ginn béid als gebrochenen Tunnel gemellt. D'Uruffer hunn ënnerschiddlech Kontrakter. Eng Liesung waartt bis de Kernel Iech e Pak gëtt, an eng Schreifweis gëtt dem Kernel e Pak, deen en dierf refuséieren.

Liesungen sinn déi einfach Hallschent fir drop ze denken. Eng Liesung déi näischt zréckgëtt, waart entweder op Verkéier deen ni kënnt oder waart well de Peer opgehalen huet ze schécken.

Eng blockéiert Liesung ass eng Onmeenigkeit iwwer d'Flosskontroll

D'Liese vun engem TUN-Gerät blockéiert bis e Pak verfügbar ass. Dat ass entworfen Verhalen, an dofir gesäit en Thread deen an read stallt op enger idler Verbindung normal aus. Et gëtt en Hänger wann Ären eegene TCP-Stack weider Date vun der lokaler App unhëlt awer ni genuch Fënster ugekënnegt fir datt de wäite Peer nach méi schécke kann. De Peer fëllt d'Fënster déi Dir ugekënnegt hutt, waart op en ACK an eng Fënsteraktualiséierung, a stoppt. Dann huet Ären Lieser näischt zréckzeginn, an d'App gesäit eng Verbindung déi op ass a stëll.

Déi heefeg Ursaachen sinn e Stack deen an de Socket schreift ouni déi ugekënnegt Fënster ze suivéieren, an een deen vergësst eng Fënsteraktualiséierung ze schécken nodeems en säi Puffer eidel gemaach huet. Vun dobausse gesi se identesch aus: Byte ginn eraus, näischt kënnt zréck, keen Feeler gëtt geworf. D'Lies-Thread op Parsing, DNS-Opléisung oder Disk-I/O blockéieren produzéiert déi selwecht Form vu Symptom aus engem onverbonnene Grond, also bestätegt datt den Thread wierklech an read ass ier Dir d'Flosskontroll beschëllegt.

Préift dem Peer seng Sendeschlange an d'Fënster déi en als lescht gesinn huet. Wann de Peer Daten hält well Är Fënster null ass, ass de Fix an Ärem ACK-Wee, net an der TUN-Liesung.

ENOBUFS ass e Gréisstproblem, net e Puffermank

Eng Schreifweis déi ENOBUFS op engem TUN-Interface zréckgëtt, refuséiert meeschtens d'Pakettlängt. Den Interface huet eng MTU, e méi grousse Pak kann net an d'Schlange gesat ginn, an d'Erëmprobéiere vum selwechte Pak feelt all Kéier op déiselwecht Manéier. Dee Determinismus ass den Hiweis. E richtige Puffermank verschwënnt wann den Drock fält, während eng Gréisstrefusatioun sech net drëm këmmert wéi laang Dir waart.

TCP huet en Mechanismus genau dofir, an et ass de Schrëtt deen d'Leit iwwersprangen: den MSS-Clamp. Wann Dir Segmenter am Benotzerraum synthetiséiert, wielt Dir d'Payloadgréisst, an se aus der MTU vum lokalen Interface amplaz vun der MTU vum Tunnel ze huelen, gëtt Segmenter eraus déi den Tunnel net ka droen. Clampt op déi kleng vun deenen zwee. De Clamp deckt nëmmen TCP, also muss en iwwergrousse UDP-Datagram vun Ärem Code fragmentéiert oder verworf ginn.

Loggt d'Längt vun all Pak deen Dir schreift während Dir debuggect. D'Längt déi feelt ass d'Äntwert, an et wäert sech tëschent Versich net änneren.

Dräi Miessungen déi d'Fäll trennen

Dir braucht keen Debugger fir ee vun den zwee Feeler. Dräi Observatioune genuch fir Iech an de richtege Sektioun ze leeden, an se huelen manner Zäit wéi en Neibau.

Wann déi drëtt Zeil entsprécht, ass d'Schleif selwer an der Rei an de Problem läit do wou den Tunnel en net ka gesinn: eng ongeschützt Transportsocket déi Ären eegene VPN-Verkéier zréck an den Tunnel dréit, wat sech meeschtens als Verbindung weist déi geléngt an dann näischt liwwert.

Reparéiert d'Plombage vun deenen zwee Weeër ofhänken

Keen Symptom ass et wäert ze jeeën bis den Interface richteg gebaut ass. D'Builder-Uruffer déi zielen sinn d'Adress, d'Route, d'MTU an d'Zoustëmmung, an dëser Reihenfolg:

Builder()
  .addAddress(10.8.0.2, 32)
  .addRoute(0.0.0.0, 0)
  .setMtu(1400)
  .establish()

Setzt d'MTU op de richtege Wäert vum Tunnel amplaz se op deem ze loossen wat d'Beispill benotzt huet. Alles wat Dir méi spéit schreift ass duerch déi Zuel begrenzt, an eng Diskrepanz tëschent der MTU déi Dir setzt an der MSS op déi Dir clampt ass de heefegste Wee fir de Schreiffeeler no engem Fix erëm anzeféieren. Duerno schützt d'Socket déi de Verkéier zum VPN-Server selwer dréit. Ouni protect ginn déi Paken zréck an Ären eegene Tunnel geroutet an d'Verbindung gëtt ni fäerdeg, wat wéi eng blockéiert Liesung ausgesäit awer eng Routing-Schleif ass.

Zoustëmmung kann een net ëmgoen. En Service deen ugefaang gëtt ouni datt prepare null zréckgëtt, kritt keen Interface, an establish gëtt null zréck amplaz ze werfen, also préift den Descriptor ier Dir Är Schleif start. VpnService-Referenz ass dee Punkt wou Dir de Builder-Kontrakt bestätegt amplaz e Beispill ze kopéieren.

Verifizéiert eng Richtung zur Zäit

Schéckt en UDP-Echo duerch den Tunnel a kuckt d'Pakettlängten ier Dir TCP beréiert. Dann oppent en Handshake a bestätegt datt d'Segmenter ënner der MSS bleiwen déi Dir berechent hutt. Zielt Paken amplaz Verbindungen, sou datt eng Stockung als Lach am Compteur erschéngt amplaz engem hänge Socket. Wa Liesungen no enger Salve Schreifweisen ophale, ass d'Fënster de Verdächtegen; wa Schreifweisen direkt feelen, ass et d'Längt.

Start dann d'Gerät nei a widderhielt eemol, well e VpnService deen nëmmen bis zur éischter Netzwierkännerung funktionéiert ass e Routingproblem an net eng Flosskontroll.