Android hotspot bidezko portu-birbidalketa: hiru sarbide-puntu azalduta

Hotspota piztu duzu, VPNa konektatu, aplikazioan portu bat ireki, eta beste gailuak oraindik ezin du konektatu. Falta den pieza ia inoiz ez da portua bera. Galdera da zein makinak duen entzuten ari den socket-a eta zein helbidera iritsi behar duen beste gailuak. Telefonotik kanporantz egiten dut ibilbidea, zure pantailak esaten baitizu hiru sarbide-puntuetatik zein ari zaren probatzen.

Hasi zerbitzua benetan exekutatzen den tokian

Ireki konexioa onartu behar duen aplikazioa eta irakurri bere egoera-orria. Entzuten ari dela dioenean, idatzi zein helbidetara lotu den, xehetasun horrek erabakitzen baitu beheko kasu gehienak. Aplikazio bat 127.0.0.1 helbidera lotuta badago, soilik telefonotik iris daiteke, eta hotspot bezero, operadorearen mapatze edo VPN irteerak ez du hori aldatuko.

Egiaztatu, ondoren, zein gailuk exekutatzen duen zerbitzua. Telefonoa izan daiteke, eta orduan socket-a aplikazio horrena da; edo hotspotaren atzeko ordenagailu bat izan daiteke, eta orduan entzulea eta bere suebakia ordenagailuarena dira eta telefonoa paketeak birbidaltzen ari da soilik. Diseinu desberdinak dira, jabe desberdinekin, eta horiek nahastea da toki batean irekitako portuak bestean ezer egiten ez duen arrazoia.

Garatze-modua gaituta duen bertsio batean, adb shell tresnak socketak zerrenda ditzake /proc/net/tcp-en bidez, baina pertsona gehienentzat aplikazioaren beraren egoerak du balio. Gainera, saihesten du espero ez zenuen helbide batean aplikazioak irekitako socket bat probatzeko tranpa.

Lehen sarbide-puntua: hotspoteko beste gailu bat

Kasu lokala da, eta errazena da ondo egitea. Beste gailuak telefonora iristeko pasabide gisa ikusten duen helbidean iristen da, aplikazioak entzuten duen portuan, eta hotspotaz kanpoko ezerk ez du parte hartu behar. Ez da operadorearen mapatzerik behar, eta hornitzailearen ezaugarririk ere ez da behar, trafikoa ez baita inoiz segmentu lokala uzten.

Bi gauzek hausten dute. Aplikazioa loopback-era lotuta egotea, edo telefonoaren bezero-politikak konexio lokala ez baimentzea. Probatu aplikazioaren beraren protokoloarekin, TCP konexio soil batekin baino, aplikazioak autentifikazioa eskatzen badu, onartu eta gero baztertzen duen entzule batek itxitako portu baten itxura bera ematen baitu urrutitik.

Zerbitzua hotspotera lotutako ordenagailu batean exekutatzen bada, ordea, telefonoaren hotspot helbidea ez da inolaz ere helmuga. Ordenagailuaren helbidea behar duzu hotspot interfazean eta entzule bat ordenagailuan bertan, eta telefonoa jada ez da ezeren jabe, birbidaltzea izan ezik.

Bigarren sarbide-puntua: operadorearen bidea

Telefonora sare mugikorretik iristea beste arazo bat da, eta gehienetan ez du funtzionatzen IPv4-rako. Operadoreek terminalak partekatutako itzulpen baten atzean jartzen dituzte, eta horrexegatik gordetzen du RFC 6598 arauak helbide-tarte partekatu bat hain zuzen ere ezarpen horretarako. Eskatutako sarrerako konexio batek ez du iristeko mapatzerik, eta ezarpen lokalek ez dute horrelakorik sortzen, itzultzailea ez baita zure gailua.

Root sarbideak ere ez du hori aldatzen. Telefonoaren pila kontrolatzeko aukera ematen dizu, ez operadorearen itzultzailea, eta bestela agintzen duten errezetek operadoreak inoiz esleitu ez zuen helbide publikoa suposatzen dute normalean. Operadoreak IPv6 aurrizki publikoa eskaintzen duen lekuan, sarrerako bide bat egon liteke, baina entzuleak eta telefonoaren suebakiak autorizazio berezia behar dute oraindik ezerk erantzun aurretik.

Hirugarren sarbide-puntua: VPN irteera

Tunela lanean dagoela webgune batek jakinarazten duen helbidea irteeraren helbidea da tunelak estaltzen duen irteerako trafikoarentzat. Hori ez da zure izenean sarrerako konexioak onartzen dituen helbide bat. Sarrera gisa erabiltzeak hornitzaileak benetan eskaintzen duen ezaugarri bat behar du, hala nola birbidalitako portu bat edo zure kontuari lotutako sarrerako mapatze bat, gehi irteeratik bezerora doan bide erabilgarri bat.

Baimen-arau lokal batek ezin du mapatze hori sortu. Alda dezakeena aplikazioaren erantzunek hartzen duten bidea da, garrantzia duena aplikazioa tunelatik kanpo dagoenean: eskaera eta erantzuna sare-kontextu desberdinetan gerta daitezke, eta konexioak suebaki-arazo baten itxura duen moduan egiten du huts.

Probatu bide bat hasieratik amaierara, eta izenda ezazu jabea

Idatzi tupla probatu aurretik: nahi den iturria, helbide helmuga, garraioa, portua eta entzuten duen socket-aren jabe den makina. Elementuren bat suposizioa bada, probak ez dizu ezer baliogarririk esango, eta bigarren geruza bat aldatuko duzu lehena azaltzeko.

Probatu, ondoren, baimendutako bide hori aplikazioaren autentifikazioari eutsita. Saihestu entzule zabal bat argitaratzea edo zerikusirik ez duten kontrolak desgaitzea helbide publikoaren proba anbiguo batek erantzun dezan, bi aldaketek proba baino gehiago irauten baitute eta ez baitute frogatzen diseinuak funtzionatzen duenik.

Androiden tethering azpisistemak beheranzko trafikoa bere bide propioan birbidaltzen du, aplikazioen VPN kapturatik aparte, beraz hotspotera lotutako ordenagailu batean funtzionatzen duen nabigatzaileak ez du ezer esaten telefonoan dagoen zerbitzu baterako sarrerako sarbideaz. Funtzionatzen duela esan aurretik:

• Entzuten duen socket-a hartzaile nahi duenak irits dezakeen helbide batean dago, ez loopback-en.
• Beste alderdiak sarbide-puntu horri dagokion helbidea erabiltzen du, ez egoera-orri bateko irteera-helbidea.
• Operadorearen edo hornitzailearen aldeko edozein mapatze onartutako ezaugarri bat da, ez zuk lokalean gehitutako arau bat.
• Eskaerak eta erantzunak sare-kontextu bera zeharkatzen dute, eta aplikazioaren autentifikazioak oraindik ere gainditzen du.