Kāpēc daudzi lietotņu savienojumi dala vienu OpenVPN sesiju

Iedomājieties pārlūku, kas ielādē HTTPS lapu, kamēr SSH klients sasniedz citu serveri un atrisinātājs atbild uz vaicājumu, viss vienā OpenVPN sesijā. Fiziskajā saskarnē jūs redzat vienu sarunu; tuneļa iekšpusē redzat trīs. Abi skati ir pareizi, un zināšana, kāpēc, ir atšķirība starp noderīgu un mulsinošu ierakstu. Sekojiet vienai iekšējai plūsmai no ligzdas līdz vadam, un slāpojums pārstāj būt abstrakts.

Viena ārējā saruna, daudzas iekšējās plūsmas

Katra lietotne atver savu ligzdu, un kodols tai piešķir piecinieku: avota adrese, avota ports, galamērķa adrese, galamērķa ports un protokols. Šie piecinieki pastāv jau pirms jebkura tuneļa iesaistīšanās. Tad maršrutēšana nolemj, ka tie visi iziet caur tuneļa ierīci, tāpēc OpenVPN nodotā pakete joprojām sevī nes oriģinālās galvenes. OpenVPN šifrē šo iekšējo paketi un iesaiņo rezultātu vienā ārējā UDP vai TCP sarunā ar partneri. Tātad ārējā saruna ir viena, bet plūsmu tajā ir tik daudz, cik lietotnes atvēra.

Nekas nesabrūk. Iekšējie piecinieki saglabājas no gala līdz galam, un tieši tāpēc tālā puse joprojām izšķir trīs plūsmas.

Ports, kas paliek nemainīgs

Nemainīgs paliek ārējais piecinieks: jūsu adrese, vietējais ports, ko klientam piesaistīja, partnera adrese un konfigurētais servisa ports. Tieši šis piecinieks ir tas, ko ugunsmūrim vai NAT ceļā ir jāļauj, un tieši to parādīs ieraksts augšupējā saitē. Tas arī mainās pēc atkārtotas savienošanās vai tīkla maiņas, jo klients var piesaistīt citu vietējo portu. Viens tunelis nenozīmē vienu nemainīgu avota portu uz visiem laikiem.

Iekšējie porti ir tas, kas rūp galapunktiem. HTTPS plūsma tuneļa iekšpusē saglabā galamērķa portu 443, lai gan ārējais transports atrodas uz porta, ko konfigurējis operators. Lietotnes galapunkti nekad neuzzina par ārējo.

Ko dekapsulēšana maina tālajā galā

Pie partnera ārējais slānis tiek noņemts, un paliek iekšējā pakete. No turienes pārsūtīšana un piekļuves politika attiecas uz iekšējo galamērķi un protokolu. Tīmekļa serveris joprojām saņem HTTPS savienojumu, SSH dēmons joprojām saņem SSH, un atrisinātājs joprojām saņem vaicājumu.

Tāpēc noteikums, kas atļauj ārējo transportu, nav tas pats noteikums, kas atļauj iekšēju pakalpojumu. Pirmais apraksta ceļu; otrais apraksta pilnvarojumu.

Ārējais TCP nozīmē vienu plūsmu, nevis vienu savienojumu

Kad ārējais transports ir UDP, katras iekšējās plūsmas liktenis ir neatkarīgs: pazaudēts datagramma ietekmē vienu pārsūtīšanu līdz tās pašas atkārtotai nosūtīšanai. Kad ārējais transports ir TCP, visas iekšējās plūsmas dala vienu uzticamu baitu plūsmu.

Tieši šī koplietotā plūsma ir daļa, ko cilvēki palaiž garām. Atkopšanās notiek vienreiz, par visu, tāpēc viens pazaudēts segments aizkavē katras iekšpusē multipleksētas lietotnes datu plūsmu. Galapunktos joprojām ir daudz savienojumu, bet uz vada — viens savienojums, un tieši uz vada dzīvo rindas galvas efekts. Klausīšanās portu skaits par to neko nepasaka, tāpēc portu skaitīšana ir slikts veids, kā domāt par tuneļa veiktspēju.

Precīzi aprakstiet savu iestatījumu

Nosauciet izvēlēto iekšējo datu plūsmu un konkrēto ārējo transportu, kas to pārnēsā, nevis sakiet, ka iekārta visu sūta pa vienu portu. Vietējie pakalpojumi, otrs tunelis un otra adrešu saime rada plūsmas, kas šajā sarunā nekad neienāk. Ieraksts augšupējā saitē parāda ārējo piecinieku; ieraksts tuneļa iekšpusē parāda iekšējos.

Paņemiet abus un lieciet laika atzīmes līdzās. Ja jums jāpierāda, kura lietotne radīja kuru iekšējo plūsmu, resursdatora ligzdu tabula ir labāks instruments, jo tā portus tieši saista ar procesiem. Tad pierakstiet novēroto ārējo piecinieku un novērošanas brīdi, jo nākamais ieraksts pēc atkārtotas savienošanās var pilnīgi likumīgi parādīt citus skaitļus.