Redirecționarea porturilor pe hotspot Android: trei puncte de intrare

Ați pornit hotspotul, ați conectat VPN-ul, ați deschis un port în aplicație, iar celălalt dispozitiv tot nu se poate conecta. Piesa lipsă aproape niciodată nu este portul în sine. Este întrebarea ce mașină deține socketul de ascultare și ce adresă ar trebui să atingă celălalt dispozitiv. Parcurg asta de la telefon spre exterior, pentru că ecranul pe care vă aflați vă spune care dintre cele trei puncte de intrare îl testați de fapt.

Începeți de unde rulează efectiv serviciul

Deschideți aplicația care ar trebui să accepte conexiunea și citiți-i pagina de stare. Dacă spune că ascultă, notați adresa la care s-a legat, pentru că acel singur detaliu decide majoritatea cazurilor de mai jos. O aplicație legată de 127.0.0.1 este accesibilă doar din telefonul însuși, iar niciun client de hotspot, mapare a operatorului sau ieșire VPN nu va schimba asta.

Apoi confirmați ce dispozitiv rulează serviciul. Este fie telefonul, caz în care socketul aparține aplicației, fie un laptop în spatele hotspotului, caz în care ascultătorul și firewallul îi aparțin laptopului, iar telefonul doar redirecționează pachete. Sunt proiecte diferite cu proprietari diferiți, iar amestecarea lor este motivul pentru care un port deschis într-un loc nu face nimic în celălalt.

Pe o compilare care permite depanare, adb shell poate lista socketuri prin /proc/net/tcp, dar pentru majoritatea oamenilor starea aplicației înseși este sursa onestă. Evită și capcana de a testa un socket pe care aplicația l-a deschis pe o adresă la care nu vă așteptați.

Primul punct de intrare: un alt dispozitiv pe hotspot

Acesta este cazul local și cel mai ușor de făcut corect. Celălalt dispozitiv ajunge la telefon la adresa pe care o vede ca gateway, pe portul pe care aplicația ascultă, și nimic din afara hotspotului nu trebuie implicat. Nu este nevoie de mapare a operatorului și nu trebuie să existe nicio funcție a furnizorului, pentru că traficul nu părăsește niciodată segmentul local.

Două lucruri îl strică. Aplicația este legată de loopback, sau politica de client din telefon nu permite conexiunea locală. Testați cu protocolul aplicației înseși în loc de o conexiune TCP simplă dacă aplicația autentifică, pentru că un ascultător care acceptă și apoi respinge arată identic cu un port închis de la distanță.

Dacă serviciul rulează pe un laptop conectat la telefon, adresa de hotspot a telefonului nu este deloc destinația. Aveți nevoie de adresa laptopului pe interfața hotspot și de un ascultător pe laptop, iar telefonul nu mai deține nimic în afară de redirecționare.

Al doilea punct de intrare: calea operatorului

A ajunge la telefon din rețeaua mobilă este o altă problemă, iar de cele mai multe ori pur și simplu nu funcționează pentru IPv4. Operatorii pun telefoanele în spatele traducerii partajate, motiv pentru care RFC 6598 a rezervat un interval de adrese partajate exact pentru această configurare. O conexiune de intrare nesolicitată nu are o mapare prin care să ajungă, iar nicio configurație locală nu creează una, pentru că traducătorul nu este dispozitivul dumneavoastră.

Nici accesul root nu schimbă asta. Vă dă control asupra stivei telefonului, nu asupra traducătorului operatorului, iar rețetele care promit altfel presupun de obicei o adresă publică pe care operatorul nu a atribuit-o niciodată. Acolo unde operatorul oferă un prefix IPv6 public, poate exista o cale de intrare, dar ascultătorul și firewallul telefonului au în continuare nevoie de autorizare deliberată înainte ca ceva să răspundă.

Al treilea punct de intrare: ieșirea VPN

Adresa pe care o raportează un site cât timp tunelul este activ este adresa ieșirii pentru traficul de ieșire acoperit. Nu este același lucru cu o adresă care acceptă conexiuni de intrare în numele dumneavoastră. Folosirea ei pentru intrare necesită o funcție pe care furnizorul o oferă efectiv, cum ar fi un port redirecționat sau o mapare de intrare legată de contul dumneavoastră, plus o cale utilizabilă de la ieșire la client.

O regulă locală de permisiune nu poate fabrica acea mapare. Ce poate face este să schimbe pe ce cale merg răspunsurile aplicației, iar asta contează când aplicația este exclusă din tunel: cererea și răspunsul pot ajunge în contexte de rețea diferite, iar conexiunea eșuează într-un mod care arată ca o problemă de firewall.

Testați o singură cale de la un capăt la altul, apoi numiți proprietarul

Notați tuplul înainte de testare: sursa dorită, adresa destinație, transportul, portul și mașina care deține socketul de ascultare. Dacă vreun element este o presupunere, testul nu vă va spune nimic util și veți ajunge să schimbați un al doilea strat pentru a-l explica pe primul.

Apoi testați acea singură cale autorizată cu autentificarea aplicației intactă. Evitați să publicați un ascultător larg sau să dezactivați controale nelegate doar ca să răspundă o verificare ambiguă a adresei publice, pentru că ambele modificări supraviețuiesc testului și niciuna nu dovedește că proiectul funcționează.

Subsistemul de tethering al Android redirecționează traficul din aval pe propria cale, separat de captura VPN obișnuită a aplicațiilor, așa că un browser funcțional pe un laptop conectat nu spune nimic despre accesul de intrare la un serviciu de pe telefon. Înainte să-l numiți funcțional:

• Socketul de ascultare este pe o adresă pe care partenerul dorit o poate atinge, nu pe loopback.
• Partenerul folosește adresa care aparține acelui punct de intrare, nu adresa de ieșire dintr-o pagină de stare.
• Orice mapare de pe partea operatorului sau a furnizorului este o funcție acceptată, nu o regulă adăugată local.
• Cererea și răspunsul trec prin același context de rețea, iar autentificarea aplicației încă trece.