Niyə Port-Share bütün sayt ziyarətçilərini localhost kimi göstərir

Giriş jurnalındakı hər sətir eyni loopback ünvanını göstərir, halbuki səhifə özü yüklənir və sertifikat düzgün yoxlanılır. Əlçatılmazlıq mənasında heç nə pozulmayıb, buna görə də bu vəziyyət aylarla davam edir. Pozulan şey aidiyyətdir: veb arxa hissə bağlantını yönləndirən addımın ünvanını qeyd edir və jurnala güvənən hər sonrakı qərar eyni səhv cavabı miras alır.

Aşağıdakı yoxlamalar kabeldən içəri doğru gedir. Gördüyünüz dəyəri izah edən ilk yoxlamada dayanın, çünki hər sonrakı addım əvvəlkilərin artıq doğru olduğunu fərz edir. Heç biri ön hissənin konfiqurasiyasını təxmin etməyi tələb etmir.

Jurnal sətrini deyil, iki bağlantını izləyin

Port-Share bir TCP dinləyicisində iki protokolu multipleks edir. OpenVPN gələn bağlantının ilk baytlarını yoxlayır, öz protokoluna bənzəyirsə onu saxlayır, qalan hər şeyi ikinci təyinat yerinə ötürür. Bu təyinat adətən eyni hostdakı veb serverdir, ona görə də veb serverin qəbul etdiyi soketin qarşı tərəfi OpenVPN prosesidir.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

Birinci əmr ictimai dinləyicinin kimə aid olduğunu göstərir. İkincisi arxa hissənin portuna gələn bağlantıları göstərir və onların qarşı ünvanı giriş jurnalının çap edəcəyi ünvandır. Əgər bu qarşı tərəf loopback-dirsə, jurnal dəqiqdir və məlumat bir qat əvvəl itib. Jurnal sahəsini adlandırmaq və ya müştəri IP modulunu aktivləşdirmək bağlantının heç vaxt daşımadığı ünvanı bərpa etməyəcək.

Bu, hər şeyi həll edən yoxlamadır. Əgər arxa hissənin qarşı tərəfi brauzerin ünvanıdırsa, port paylaşımı sizin probleminiz deyil, jurnal formatıdır.

Nəqliyyatın ötürülməsi başlıq yeritmə deyil

Ötürücü baytları hərəkət etdirir. HTTP-ni təhlil etmir, ona görə də heç vaxt sorğu kimi oxumadığı sorğuya başlıq əlavə edə bilməz və toxunmadan keçirdiyi TLS axınına heç nə əlavə edə bilməz. Proksi başlığı gözləyən modul heç bir komponentin istehsal etmədiyi başlığı gözləməyə davam edəcək.

Orijinal ünvanı iki mexanizm daşıya bilər və hər ikisi hər iki tərəfdə razılıq tələb edir. PROXY protokolu bağlantının əvvəlinə kiçik bir başlıq əlavə edir və arxa hissə onu gözləmək üçün konfiqurasiya edilməlidir; onu gözləməyən arxa hissə bu baytları sorğunun başlanğıcı kimi qəbul edib çaşdırıcı şəkildə uğursuz olacaq. X-Forwarded-For kimi etibarlı proksi başlıqları HTTP-dən anlayan proksi onları təyin etdikdə və arxa hissəyə hansı qarşı tərəflərin bunu təsdiq edə biləcəyi bildirildikdə işləyir.

Heç biri avtomatik deyil və heç biri standart olaraq təhlükəsiz deyil. Gələn istənilən ötürülmüş başlığa inanan arxa hissə müştəriyə öz ünvanını seçməyə imkan verir və bu, jurnaldakı qeyri-dəqiqliyi giriş nəzarətinin yan keçməsinə çevirir. Hər hansı başlığa istehsal yolunda güvənməzdən əvvəl nümayişi bir dəfə sınaq hostunda işə salın.

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

İstəyə bağlı mənbə xəritələmə kataloqu

Port paylaşımının, xüsusiyyətin tətbiq olunduğu platformalarda orijinal mənbə ünvanı ilə ötürmə bağlantısı arasında xəritələmə qeyd edən istəyə bağlı kataloq arqumenti var. Veb tərəfin həmin xəritələməyə müraciət etməsi gözlənilir; bu başlıq deyil və sorğuya yeridilmir.

Bu dizaynı bilməyə dəyər, çünki görünüşdə eyni ön hissə konfiqurasiyası ilə bəzi yerləşdirmələrin real ünvanlar, bəzilərinin isə yox, niyə bildirdiyini izah edir. Fərq qəbul edən tərəfdədir və adətən paketlənmiş veb serverlərin standart olaraq aktivləşdirmədiyi modulda və ya yamada olur. Veb serverinizin sənədlərində təklif etdiyi dəqiq qarmağı oxuyun və modulun yükləndiyini fərz etmək yerinə təsdiqləyin.

Bu yolu seçsəniz, ona iki yarıdan ibarət inteqrasiya kimi baxın: ötürücünün yazdığı xəritələmə və arxa hissənin etdiyi axtarış. Hər ikisini yoxlayın və kataloqun yenidən başlatmadan sonra da qaldığını və məşğul dinləyicidə hədsiz böyümədiyini təsdiqləyin.

Ünvana hansı komponentin zəmanət verəcəyini qərarlaşdırın

Konfiqurasiyanı dəyişməzdən əvvəl müştəri ünvanını təsdiq etməyə icazə verilən komponenti və ona inanmağa icazə verilən komponentləri adlandırın. Yazıya alınmış tək bir cavab, üç fərqli qatın hər birinin fərqli mənbəyə güvəndiyi adi sürüşmənin qarşısını alır.

Əksər ehtiyacları üç dizayn ödəyir. İctimai dinləyicini və veb dinləyicisini ayrı saxlayın, belə ki veb server real qarşı tərəfləri görsün və heç bir aidiyyət problemi olmasın. Önə HTTP-dən anlayan tərs proksi qoyun, sorğunu orada sonlandırın və ya təhlil edin və yalnız həmin proksiyə güvənən arxa hissə üçün ötürülmüş başlıq təyin etməsinə icazə verin. Və ya port paylaşımını saxlayın və jurnalların addımı göstərdiyini qəbul edin, giriş qaydaları ünvana deyil, tətbiq kimliyinə görə yazılsın.

İşləməyən şey, ötürülmüş loopback ünvanını sorğunun bu maşında yarandığına dair sübut kimi qəbul etməkdir. Bu nəticə tam əksinədir: ünvan məhz yerli komponent bağlantını yaratdığı üçün mövcuddur. Bu cür yazılmış qayda dinləyiciyə çata bilən hər kəsi qəbul edir.

Səhifəni deyil, qaydanı sınaqdan keçirin

Yüklənən səhifə ötürmə yolunun işlədiyini sübut edir və aidiyyət barədə heç nə demir. Ünvanın istehlakçısını sınaqdan keçirin: giriş qaydasını, dərəcə limitini, audit qeydini, coğrafi axtarışı.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

İcazə verilmiş xarici sorğunu həm ön hissə, həm də arxa hissə qeydləri ilə müqayisə edin və rədd etməli olan qaydanın hələ də rədd etdiyini, qəbul etməli olanın hələ də qəbul etdiyini təsdiqləyin. Jurnal sətri düzgündürsə, amma qayda hələ də hamını yerli sayırsa, qayda sizin düzəltdiyinizdən fərqli sahə oxuyur.

Yerləşdirmə qeydlərinə aidiyyət zəncirini yazmaqla bitirin: hansı dinləyici, hansı ötürücü, hansı başlıq və ya xəritələmə və hansı arxa hissənin ona güvənmək üçün konfiqurasiya edildiyi. Jurnal sətrini oxuyacaq növbəti şəxs dördünün hamısına ehtiyac duyacaq və bu qeydin olmaması eyni bileti bir il sonra yenidən açmağın yoludur. Onu söhbət lentində deyil, konfiqurasiyanın yanında saxlayın.