Hoekom baie app-verbindings een OpenVPN-sessie deel

Stel jou 'n blaaier voor wat 'n HTTPS-bladsy laai terwyl 'n SSH-kliënt 'n ander bediener bereik en 'n oplosser 'n navraag beantwoord, alles deur een OpenVPN-sessie. Op die fisiese koppelvlak sien jy een gesprek; binne die tonnel sien jy drie. Albei sienings is korrek, en om te weet hoekom is die verskil tussen 'n nuttige opname en 'n verwarrende een. Volg een binnestroom van socket tot draad, dan hou die gelaagdheid op om abstrak te wees.

Een buitenste gesprek, baie binnestrome

Elke toepassing open sy eie socket, en die kern gee dit 'n vyf-tupel van bronadres, bronpoort, bestemmingsadres, bestemmingspoort en protokol. Daardie tupels bestaan voordat enige tonnel betrokke is. Roetering besluit dan dat almal deur die tonneltoestel vertrek, so die pakket wat aan OpenVPN oorhandig word, dra steeds die oorspronklike opskrifte binne-in. OpenVPN versleutel daardie binnepakket en wikkel die resultaat in 'n enkele buitenste UDP- of TCP-gesprek met die eweknie. Die buitenste gesprek is dus een, terwyl die strome daarbinne soveel is as wat die toepassings geopen het.

Niks val in duie nie. Die binnetupels oorleef van begin tot einde, en daarom kan die oorkantste kant steeds die drie strome uitmekaar hou.

Die poort wat vas bly

Wat konstant bly, is die buitenste tupel: jou adres, die plaaslike poort wat die kliënt gebind het, die eweknie-adres en die gekonfigureerde dienspoort. Dit is die tupel wat 'n vuurmuur of 'n NAT in die pad moet toelaat, en dit is die een wat 'n opname op die opkoppeling sal wys. Dit is ook die een wat verander ná 'n herverbinding of 'n netwerkwisseling, want die kliënt kan 'n ander plaaslike poort bind. Een tonnel beteken nie vir ewig een vaste bronpoort nie.

Dit is die binneporte waaroor die eindpunte gee. 'n HTTPS-stroom hou bestemmingspoort 443 binne die tonnel, selfs al sit die buitenste vervoer op watter poort die operateur ook al gekonfigureer het. Die toepassing-eindpunte leer nooit van die buitenste een nie.

Wat ontsluiting aan die verre kant verander

By die eweknie kom die buitenste laag af, en die binnepakket is wat oorbly. Van daar af geld aansturing en toegangsbeleid vir die binneste bestemming en protokol. Die webbedienaar ontvang steeds 'n HTTPS-verbinding, die SSH-daemon ontvang steeds SSH, en die oplosser ontvang steeds 'n navraag.

Daarom is 'n reël wat die buitenste vervoer toelaat nie dieselfde reël as om 'n interne diens toe te laat nie. Die eerste beskryf 'n pad; die tweede beskryf magtiging.

TCP buiten beteken een stroom, nie een verbinding nie

Wanneer die buitenste vervoer UDP is, is elke binnestroom se lot onafhanklik: 'n verlore datagram raak een oordrag tot sy eie herversending. Wanneer die buitenste vervoer TCP is, deel alle binnestrome een betroubare bytestroom.

Daardie gedeelde stroom is die deel wat mense miskyk. Herstel gebeur een keer, vir alles, so 'n enkele verlore segment vertraag verkeer van elke toepassing wat daarbinne gemultiplekseer is. Dit is steeds baie verbindings by die eindpunte en een verbinding op die draad, en dit is op die draad waar die kop-van-die-lyn-effek woon. Die aantal luisterende poorte sê niks hieroor nie, en daarom is poorte tel 'n swak manier om oor tonnelprestasie te redeneer.

Beskryf jou eie opstelling akkuraat

Noem die geselekteerde binneverkeer en die spesifieke buitenste vervoer wat dit dra, eerder as om te sê die masjien stuur alles deur een poort. Plaaslike dienste, 'n tweede tonnel en die ander adresfamilie skep almal strome wat nooit hierdie gesprek betree nie. 'n Opname op die opkoppeling wys die buitenste tupel; 'n opname binne die tonnel wys die binne s'n.

Neem albei, en sit die tydstempels langs mekaar. As jy moet bewys watter toepassing watter binnestroom geskep het, is die socket-tabel op die gasheer die beter instrument, want dit karteer poorte direk na prosesse. Skryf dan die buitenste tupel neer wat jy waargeneem het en die oomblik toe jy dit waargeneem het, want die volgende opname ná 'n herverbinding kan wettiglik ander nommers wys.