Supportkaarten komme binnen dy't sizze dat de app ien adres litet wylst de tsjinner in oar opnaam hat, en dan freegje hokker fan beide liicht. Gjinien fan beide; it binne twa waarnimmings fan twa ferskillende dingen. In adres bûn oan in ynterface, in adres bûn oan in socket en in boarne-adres sjoen troch in fiere tsjinst beantwurdzje trije aparte fragen. In VPN foeget netwurk kontekst ta oan 'e tillefoan en kollapset dy trije net ta ien getal foar it hiele apparaat. Lês de fjildnammen yn it kaartsje foardat jo de adressen lêze.

Wat it kaartsje meastentiids beskriuwt

Stel jo in tillefoan op Wi-Fi foar mei in tunnel omheech. It Wi-Fi-ynterface hat in LAN-adres, it tunnel-ynterface hat in tawiisd innerlik adres, en in oanfraach dy't troch de tunnel útgiet komt by in iepenbiere tsjinst oan fan hokker boarne dan ek dy't in oersetting ûnderweis oerlibbet. In app dy't it innerlike adres printsje lit en in tsjinner dy't de oersette boarne opnimt, beide rapportearje se sekuer, en dy twa wearden sille nea oerienkomme.

De trije waarnimmings ferskille yn wat se bewize kinne, net allinnich yn wat se beskriuwe.

ObservationWhat it describesWhat it cannot prove
An address on a local interfaceOne configured attachment: Wi-Fi, cellular or a tunnelThe source a remote site receives
A socket's local endpointThe binding used by that one connectionThe address after translation further along
The peer address at a serviceWhat arrived at that observation pointAny other interface on the phone

Hâld dy tabel njonken de koade dy't dizze wearden yn in kaartsje follet, want it measte fan 'e betizing hjir is in kolombetizing en net in netwurkflater.

Wat in socket-oprop wol en net beantwurdzje kin

Op API-nivo rapportearret getsockname it lokale einpunt dat op dit stuit bûn is oan in bepaald socket. Foar in ferbûn socket is dat de boarne dy't de kearn foar dy ferbining keas, wat al spesifiker is as hokker ynterface-list dan ek. It is gjin syktocht nei in iepenbier adres, en it oanroppen op in net-bûn socket fertelt jo hast neat. Wat it ek weromjout, kin letter op it paad noch oerskreaun wurde, dat allinnich de eigen waarnimming fan 'e tsjinst is gesachhawwend oer wat de tsjinst ûntfongen hat.

Op Apple-platfoarmen hat de ynterface-kant in apart oerflak: tunnel-ynstellingen listje de adressen op dy't oan it tunnel-ynterface tawiisd binne. Se lêze fertelt jo hoe't de tunnel konfigurearre is, en it fertelt jo net hokker paad in bepaalde oanfraach naam hat, want routing en regels per app beslisse dat per ferbining.

Dield tunnele meitsje it gat sichtber. Mar ien oanfraach kin troch de tunnel útgien wylst de folgjende, rjochte op in oare bestimming of adresfamylje, dat net docht, dat twa resultaten fan deselde app sekonden útinoar kinne earlik en ferskillend wêze.

Kies de waarnimming dy't by de fraach past

Kies bewust ynstee fan alles te ynstrumentearjen. Foar wat de backend sjocht, registrearje de boarne by de backend, en wêr't in omkearde proxy foar stiet, lês it kliïntadres út 'e trochstjoerheader dy't jo útrôljen eins set, en net út wat de kliïnt stjoerd hat.

Om te witten oft de tunnel konfigurearre is, lês it ynterface. Om te witten oft it ferkear fan dizze app it brûkt hat, stjoer ferkear fan dy app nei in bestimming dy't jo beheare en fergelykje de boarne oan beide einen.

Regels per app fertsjinje har eigen sin. In browserresultaat is bewiis oer dy browser, en in beheard tunnel per app kin twa apps op deselde tillefoan op itselde stuit op ferskillende paden sette. Dekking ferifiearje betsjut ferkear stjoere fan 'e oangeande app, yn 'e oangeande adresfamylje.

Ynterface-nammen binne gjin detektor

Brûk ek gjin ynterface-namme as VPN-kontrôle. De nammen binne gjin iepenbier kontrakt, en in tillefoan kin ferskate oanslutings hawwe wylst mar ien fan har jo oanfraach draacht.

Nammje it fjild nei de waarnimming dy't it hâldt. local_interface_address, socket_local_endpoint en service_observed_source binne ûnhandich en ûndûbelsinnich, en ûndûbelsinnigens is wat jo wolle as de wearde in wike letter yn in supportkaartsje bedarret. Ien kolom mei de namme device IP sammelt alle trije en wurdt dan fertroud as wie it ien.

Hâld identiteit bûten de adreskolom

In dielde VPN-útgong is gjin brûkersidentiteit, en in privee adres is gjin tagongsbewiis. Beide beskriuwe in paad en net in persoan, en ien fan beiden as autentikaasje behannelje makket fan in routingûngelok in autorisaasjebeslút.

As immen freget hokker adres de tillefoan hat, is it nuttige antwurd in fraach oer hokker ferbining en hokker waarnimmer. De definysje fan getsockname is it wurdich oan te heljen foar it middengefal, want dy beslacht de socket-fraach sûnder te dwaan as beslacht er de oare twa.

Skriuw dan op hokker fan 'e trije jo produkt eins sjen litte moat, en smyt de oare twa út it ynterface.

Relatearre artikelen