אַ צונאָמען וואָס איז דעפֿינירט נאָר אויפֿן SSH סערווער קען אַרבעטן דורך זײַן דינאַמישן SOCKS ווײַטערפֿירונג אויב די אַפּליקאַציע שיקט דעם נאָמען פֿון ציל. אויב זי לייזט עס ערשט לאָקאַל אויס און שיקט אַ נומערישן אַדרעס, באַקומט די hosts מאַפּע פֿונעם סערווער קיינמאָל נישט דעם אָריגינעלן נאָמען צו אויסלייזן.

די געוויינטלעכע דינאַמישע ווײַטערפֿירונג פֿון OpenSSH פֿירט אַ דאָמען־ציל צו דער סערווער־זײַט פֿאַר דער אַרויסגייִקער פֿאַרבינדונג. דאָרט ניצט OpenSSH דעם סיסטעם־אַדרעס־זוך API. אויף אַ טיפּישן glibc Linux האָסט קאָנטראָלירט NSS די hosts דאַטן־באַזע און די זוך־סדר, דערפֿאַר קען אַן איינציקייט אין דער hosts טעקע אָנטייל נעמען. דאָס איז נישט קיין DNS רעקאָרד וואָס איז קאָפּירט געוואָרן אויפֿן לעפּטאָפּ.

האַלט דעם געמיינטן נאָמען, למשל preview.internal, אין דער URL פֿון דער וועבזײַט און קלײַבט אויס דעם SOCKS מאָדע פֿונעם קליענט פֿאַר אַ ווײַטן האָסט־נאָמען. פֿאַרבײַטן דעם האָסט־נאָמען אין דער URL מיט אַן IP קען ענדערן סײַ HTTP Host סײַ TLS אידענטיטעט; דערגרייכיקייט מאַכט נישט קיין צערטיפֿיקאַט גילטיק פֿאַר אַן אַנדער נאָמען.

אויב דער צונאָמען פֿאַלט נאָך אַלץ דורך, באַשטימט די סבֿיבֿה וואָס פֿירט דורכן ווײַטן זוך. אַ קאָנטיינער, chroot אָדער אַ באַזונדער דינסט־אינסטאַנץ ניצט מעגלעך נישט די hosts טעקע וואָס איר האָט רעדאַגירט. אַנדערע SOCKS אימפּלעמענטאַציעס קענען ניצן זייערע אייגענע לייזער, דערפֿאַר טאָר מען נישט אָננעמען דאָס סיסטעם־זוך־באַנעמען פֿאַר יעדן פּראָקסי סערווער.

פֿאַרבונדענע אַרטיקלען