Kodėl daugelis programų jungčių dalijasi viena OpenVPN sesija

Įsivaizduokite naršyklę, kraunančią HTTPS puslapį, kol SSH klientas pasiekia kitą serverį ir resolveris atsako į užklausą, visa tai per vieną OpenVPN sesiją. Fiziniame sąsaja matote vieną pokalbį; tunelio viduje matote tris. Abi perspektyvos teisingos, o žinojimas, kodėl, yra skirtumas tarp naudingo ir klaidinančio įrašymo. Sekite vieną vidinį srautą nuo lizdo iki laido ir sluoksniavimas nustoja būti abstraktus.

Vienas išorinis pokalbis, daug vidinių srautų

Kiekviena programa atidaro savo lizdą, ir branduolys jai suteikia penketą: šaltinio adresas, šaltinio prievadas, paskirties adresas, paskirties prievadas ir protokolas. Tie penketai egzistuoja dar prieš įsikišant bet kuriam tuneliui. Tada maršrutizavimas nusprendžia, kad visi jie išeina per tunelio įrenginį, todėl OpenVPN perduotas paketas vis dar neša originalias antraštes savyje. OpenVPN užšifruoja tą vidinį paketą ir apgaubia rezultatą vienu išoriniu UDP arba TCP pokalbiu su partneriu. Taigi išorinis pokalbis yra vienas, o srautų jame tiek, kiek programų atsidarė.

Niekas nesugriūva. Vidiniai penketai išlieka nuo pradžios iki pabaigos, ir todėl tolimoji pusė vis dar atskiria tris srautus.

Prievadas, kuris lieka fiksuotas

Pastovus lieka išorinis penketas: jūsų adresas, vietinis prievadas, kurį priskyrė klientas, partnerio adresas ir sukonfigūruotas paslaugos prievadas. Būtent šį penketą turi praleisti ugniasienė arba NAT kelyje, ir būtent jį parodys įrašymas viršutinėje jungtyje. Jis ir keičiasi po pakartotinio prisijungimo ar tinklo pakeitimo, nes klientas gali priskirti kitą vietinį prievadą. Vienas tunelis nereiškia vieno pastovaus šaltinio prievado visam laikui.

Vidiniai prievadai yra tai, kas rūpi galiniams taškams. HTTPS srautas tunelio viduje išlaiko paskirties prievadą 443, nors išorinis transportas sėdi tame prievade, kurį sukonfigūravo operatorius. Programos galiniai taškai niekada nesužino apie išorinį.

Ką dekapsuliavimas pakeičia tolimajame gale

Pas partnerį išorinis sluoksnis nuimamas, ir lieka vidinis paketas. Nuo ten persiuntimas ir prieigos politika taikomi vidiniam tikslui ir protokolui. Žiniatinklio serveris vis dar gauna HTTPS ryšį, SSH tarnyba vis dar gauna SSH, o resolveris vis dar gauna užklausą.

Štai kodėl taisyklė, leidžianti išorinį transportą, nėra ta pati taisyklė kaip vidinės paslaugos leidimas. Pirmoji aprašo kelią, antroji — įgaliojimą.

Išorinis TCP reiškia vieną srautą, o ne vieną ryšį

Kai išorinis transportas yra UDP, kiekvieno vidinio srauto likimas nepriklausomas: prarastas datagramas paveikia vieną perdavimą iki jo paties pakartotinio siuntimo. Kai išorinis transportas yra TCP, visi vidiniai srautai dalijasi vienu patikimu baitų srautu.

Būtent šis bendras srautas yra ta dalis, kurią žmonės praleidžia. Atkūrimas įvyksta vieną kartą, viskam, todėl vienas prarastas segmentas uždelsia kiekvienos viduje multipleksuotos programos srautą. Galiniuose taškuose vis dar daug ryšių, o laide – vienas ryšys, ir būtent laide gyvena eilės galvos efektas. Klausančių prievadų skaičius apie tai nieko nesako, todėl prievadų skaičiavimas yra prastas būdas mąstyti apie tunelio našumą.

Tiksliai aprašykite savo sąranką

Įvardykite pasirinktą vidinį srautą ir konkretų išorinį transportą, kuris jį neša, o ne sakykite, kad mašina viską siunčia vienu prievadu. Vietinės paslaugos, antras tunelis ir kita adresų šeima sukuria srautus, kurie niekada nepatenka į šį pokalbį. Įrašymas viršutinėje jungtyje rodo išorinį penketą; įrašymas tunelio viduje rodo vidinius.

Paimkite abu ir sudėkite laiko žymes greta. Jei reikia įrodyti, kuri programa sukūrė kurį vidinį srautą, pagrindinio kompiuterio lizdų lentelė yra geresnis įrankis, nes ji tiesiogiai susieja prievadus su procesais. Tada užsirašykite stebėtą išorinį penketą ir stebėjimo momentą, nes kitas įrašymas po pakartotinio prisijungimo gali teisėtai rodyti kitus skaičius.