Bakit ginagawang parang localhost ng Port-Share ang lahat ng bisita sa website

Bawat linya sa access log ay nagpapakita ng parehong loopback address, habang ang pahina mismo ay naglo-load at wastong nabe-verify ang sertipiko. Walang sira sa diwa ng hindi maabot, at iyon ang dahilan kung bakit tumatagal ito nang ilang buwan. Ang nasira ay ang pag-attribute: itinatala ng web backend ang address ng hop na nagpasa ng koneksyon, at bawat kasunod na desisyon na nagtiwala sa log ay nagmana ng parehong maling sagot.

Ang mga pagsusuri sa ibaba ay mula sa kable pakanin. Huminto sa una na nagpapaliwanag ng halagang nakikita mo, dahil ipinapalagay ng bawat susunod na hakbang na totoo na ang mga nauna. Wala sa mga ito ang nangangailangan ng paghula sa front-end na configuration.

Sundan ang dalawang koneksyon, hindi ang linya ng log

Ang Port-Share ay nag-multiplex ng dalawang protocol sa isang TCP listener. Sinusuri ng OpenVPN ang mga unang byte ng papasok na koneksyon, pinapanatili ito kapag mukhang sariling protocol nito, at ibinibigay ang lahat ng iba pa sa pangalawang destinasyon. Ang destinasyong iyon ay karaniwang web server sa parehong host, kaya ang tinanggap na socket ng web server ay may prosesong OpenVPN bilang kapareha.

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

Ipinapakita ng unang utos kung sino ang may-ari ng pampublikong listener. Ipinapakita ng pangalawa ang mga koneksyong dumarating sa port ng backend, at ang address ng kanilang kapareha ang siyang ipi-print ng access log. Kung ang kaparehang iyon ay loopback, tumpak ang log at nawala ang impormasyon isang layer bago pa. Ang pagpapalit ng pangalan ng field sa log o pagpapagana ng client-IP module ay hindi magbabalik ng address na hindi kailanman dinala ng koneksyon.

Ito ang pagsusuring nagpapasya sa lahat ng iba pa. Kung ang kapareha ng backend ay address ng browser, hindi mo problema ang pagbabahagi ng port at ang format ng log ang problema.

Ang pagpapasa ng transport ay hindi pag-inject ng header

Ginagalaw ng tagapasa ang mga byte. Hindi ito nag-parse ng HTTP, kaya hindi ito makakapasok ng header sa isang kahilingang hindi nito kailanman binasa bilang kahilingan, at hindi ito makakadagdag ng anuman sa TLS stream na pinapayagan nitong dumaan nang walang galaw. Ang isang module na umaasa sa header ng proxy ay patuloy na maghihintay ng isang walang bahaging gumagawa.

Dalawang mekanismo ang maaaring magdala ng orihinal na address, at pareho silang nangangailangan ng kasunduan sa magkabilang dulo. Ang PROXY protocol ay nagdadagdag ng maliit na header sa unahan ng koneksyon, at ang backend ay dapat naka-configure na asahan ito; ang backend na hindi umaasa dito ay ituturing ang mga byte na iyon na simula ng kahilingan at mabibigo sa nakalilitong paraan. Ang mga pinagkakatiwalaang proxy header tulad ng X-Forwarded-For ay gumagana kapag ang proxy na nakakaunawa ng HTTP ang nagtatakda sa kanila at sinasabi sa backend kung aling mga kapareha ang pinapayagang magpatunay sa kanila.

Wala sa dalawa ang awtomatiko, at wala sa dalawa ang ligtas bilang default. Ang backend na naniniwala sa bawat papasok na ipinasang header ay nagbibigay-daan sa kliyente na piliin ang sariling address, na ginagawang paraan ng pag-iwas sa access control ang isang kamalian sa log. Patakbuhin ang demonstrasyon nang isang beses sa test host bago magtiwala sa anumang header sa production path.

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

Ang opsyonal na direktoryo ng pagmamapa ng pinagmulan

Ang pagbabahagi ng port ay may opsyonal na argumentong direktoryo na nagtatala ng pagmamapa sa pagitan ng orihinal na address ng pinagmulan at ng koneksyon ng pagpapasa, sa mga platform kung saan ipinatupad ang feature na ito. Inaasahang sasangguni ng web side ang pagmamapang iyon; hindi ito header, at hindi ito ini-inject sa kahilingan.

Ang disenyong iyon ay dapat malaman dahil ipinapaliwanag nito kung bakit ang ilang deployment ay nag-uulat ng tunay na address at ang iba ay hindi, na may halos magkaparehong front-end na configuration. Ang pagkakaiba ay nasa panig ng tumatanggap, at karaniwang naninirahan ito sa isang module o patch na hindi pinapagana bilang default ng karamihan sa mga naka-package na web server. Basahin ang dokumentasyon ng iyong web server para sa eksaktong hook na inaalok nito, at tiyakin na ang module ay na-load sa halip na ipagpalagay ito.

Kung tatahakin mo ang landas na ito, ituring itong integrasyon ng dalawang hati: ang pagmamapang isinusulat ng tagapasa at ang paghahanap na ginagawa ng backend. Tiyakin ang pareho, at tiyakin na ang direktoryo ay nakakaligtas sa restart at hindi lumalaki nang walang hangganan sa abalang listener.

Magpasya kung aling bahagi ang nangangalaga sa address

Bago baguhin ang configuration, pangalanan ang bahaging pinapayagang magpatunay ng address ng kliyente at ang mga bahaging pinapayagang maniwala rito. Ang isang nakasulat na sagot ay pumipigil sa karaniwang paglihis, kung saan tatlong magkaibang layer ang bawat isa ay may pinagkakatiwalaang ibang pinagmulan.

Tatlong disenyo ang sumasaklaw sa karamihan ng pangangailangan. Panatilihing hiwalay ang pampublikong listener at ang web listener, upang makita ng web server ang tunay na kapareha at walang problemang pag-attribute. Maglagay sa harap ng reverse proxy na nakakaunawa ng HTTP, tapusin o i-parse ang kahilingan doon, at hayaang magtakda ito ng ipinasang header para sa backend na nagtitiwala lamang sa proxy na iyon. O panatilihin ang pagbabahagi ng port at tanggapin na ang mga log ay nagpapakita ng hop, na ang mga tuntunin sa pag-access ay nakasulat laban sa pagkakakilanlan ng aplikasyon sa halip na address.

Ang hindi gumagana ay ang ituring ang ipinasang loopback address bilang patunay na ang kahilingan ay nagmula sa makinang ito. Ang hinuha na iyon ay eksaktong kabaligtaran: naroroon ang address dahil mismong isang lokal na bahagi ang gumawa ng koneksyon. Ang tuntuning nakasulat nang gayon ay tumatanggap sa sinumang makakaabot sa listener.

Subukan ang tuntunin, hindi ang pahina

Ang pahinang naglo-load ay nagpapatunay na gumagana ang landas ng pagpapasa at walang sinasabi tungkol sa pag-attribute. Subukan ang gumagamit ng address: ang tuntunin sa pag-access, ang limitasyon sa bilis, ang entry sa audit, ang heograpikong paghahanap.

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

Ihambing ang awtorisadong panlabas na kahilingan sa mga talaan ng front-end at ng backend, at tiyakin na ang tuntuning dapat tumanggi ay tumatanggi pa rin at ang dapat pumayag ay pumapayag pa rin. Kung tama ang linya ng log ngunit ang tuntunin ay kumikilos pa rin na parang lahat ay lokal, ang tuntunin ay nagbabasa ng ibang field kaysa sa itinama mo.

Tapusin sa pamamagitan ng pagsulat ng kadena ng pag-attribute sa mga tala ng deployment: aling listener, aling tagapasa, aling header o pagmamapa, at aling backend ang naka-configure na magtiwala rito. Ang susunod na taong magbabasa ng linya ng log ay kakailanganin ang lahat ng apat, at ang kawalan ng talang iyon ang dahilan kung bakit muling bumubukas ang parehong ticket makalipas ang isang taon. Itago ito sa tabi ng configuration at hindi sa isang chat thread.