Hvers vegna Port-Share lætur alla gesti vefsins líta út eins og localhost

Hver lína í aðgangsskránni sýnir sama loopback-vistfang, á meðan síðan hleðst og skírteinið staðfestist rétt. Ekkert er bilað í þeim skilningi að það sé óaðgengilegt, og þess vegna endist þetta í mánuði. Það sem bilaði er eignunin: vefbakendinn skráir vistfang þess stökks sem sendi tenginguna áfram, og hver síðari ákvörðun sem treysti skránni erfði sama ranga svar.

Athuganirnar hér að neðan fara frá snúrunni inn á við. Stoppaðu við þá fyrstu sem útskýrir gildið sem þú sérð, því hvert síðara skref gerir ráð fyrir að þau fyrri séu þegar sönn. Ekkert þeirra krefst þess að giska á stillingar framendans.

Fylgdu tveimur tengingum, ekki línunni í skránni

Port-Share margfaldar tveimur siðareglum á einum TCP-hlustunaraðila. OpenVPN skoðar fyrstu bætin í innkomandi tengingu, heldur henni þegar hún lítur út eins og hans eigin siðaregla, og afhendir allt annað öðrum áfangastað. Sá áfangastaður er venjulega vefþjónn á sama hýsli, svo samþykkt höfn vefþjónsins hefur OpenVPN-ferlið sem mótaðila.

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

Fyrsta skipunin sýnir hver á opinbera hlustunaraðilann. Önnur sýnir tengingarnar sem berast á bakendaportið, og mótaðilavistfang þeirra er það sem aðgangsskráin prentar. Ef sá mótaðili er loopback er skráin nákvæm og upplýsingunum var týnt einu lagi fyrr. Að endurnefna skráarreitinn eða virkja IP-einingu biðlarans endurheimtir ekki vistfang sem tengingin bar aldrei.

Þetta er athugunin sem ræður öllu öðru. Ef mótaðili bakendans er vistfang vafrans er deiling portsins ekki þitt vandamál og snið skráarinnar er það.

Framsending flutnings er ekki innspýting hauss

Framsendandinn færir bæti. Hann þáttar ekki HTTP, svo hann getur ekki sett haus í beiðni sem hann les aldrei sem beiðni, og getur ekki bætt neinu við TLS-straum sem hann lætur framhjá ósnortinn. Eining sem bíður eftir haus frá milliþjóni mun halda áfram að bíða eftir þeim sem engin eining framleiðir.

Tvær aðferðir geta borið upprunalega vistfangið, og báðar krefjast samkomulags á báðum endum. PROXY-siðareglan setur lítinn haus framan við tenginguna, og bakendinn verður að vera stilltur til að búast við honum; bakendi sem býst ekki við honum mun meðhöndla þessi bæti sem upphaf beiðninnar og mistakast á ruglingslegan hátt. Traustir hausar milliþjóna eins og X-Forwarded-For virka þegar milliþjónn sem skilur HTTP setur þá og bakandanum er sagt hvaða mótaðilar megi staðhæfa þá.

Hvort tveggja er ekki sjálfvirkt, og hvort tveggja er ekki öruggt sjálfgefið. Bakendi sem trúir hvaða innkomandi framsendum haus sem er leyfir biðlaranum að velja sitt eigið vistfang, sem gerir ónákvæmni í skránni að sniðgöngu á aðgangsstýringu. Keyrðu sýninguna einu sinni á prófunarhýsli áður en þú treystir nokkrum haus á framleiðsluleið.

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

Valfri upprunakortlagningarmöppan

Deiling portsins hefur valfrjálsa möppu færibreytu sem skráir kortlagningu milli upprunalega upprunavistfangsins og framsendingartengingarinnar, á kerfum þar sem eiginleikinn er útfærður. Gert er ráð fyrir að vefhliðin skoði þá kortlagningu; það er ekki haus og er ekki sprautað inn í beiðnina.

Þessi hönnun er þess virði að þekkja því hún útskýrir hvers vegna sumar uppsetningar tilkynna raunveruleg vistföng og aðrar ekki, með að því er virðist eins framendastillingum. Munurinn er á móttökuhliðinni og býr venjulega í einingu eða bót sem flestir pakkaðir vefþjónar virkja ekki sjálfgefið. Lestu skjöl vefþjónsins þíns um nákvæmlega þann krók sem hann býður upp á, og staðfestu að einingin sé hlaðin í stað þess að gera ráð fyrir því.

Ef þú ferð þessa leið, meðhöndlaðu það sem samþættingu tveggja helminga: kortlagninguna sem framsendandinn skrifar og uppflettinguna sem bakendinn gerir. Staðfestu báðar, og staðfestu að mappan lifi endurræsingu og stækki ekki ótakmarkað á annasömum hlustunaraðila.

Ákveddu hvaða eining ábyrgist vistfangið

Áður en þú breytir stillingunum skaltu nefna eininguna sem má staðhæfa biðlaravistfang og einingarnar sem mega trúa því. Eitt skriflegt svar kemur í veg fyrir hina venjulegu rek, þar sem þrjú mismunandi lög treysta hvert sínum uppruna.

Þrjár hannanir ná yfir flestar þarfir. Haltu opinberum hlustunaraðila og vefhlustunaraðila aðskildum, svo vefþjónninn sjái raunverulega mótaðila og ekkert eignunarvandamál sé til. Settu HTTP-skilning milliþjón fyrir framan, endaðu eða þáttaðu beiðnina þar, og leyfðu honum að setja framsendan haus fyrir bakenda sem treystir aðeins þeim milliþjóni. Eða haltu portdeilingunni og samþykktu að skrárnar sýni stökkið, með aðgangsreglum skrifuðum gegn auðkenni forritsins í stað vistfangs.

Það sem virkar ekki er að meðhöndla framsent loopback-vistfang sem sönnun þess að beiðnin hafi orðið til á þessari vél. Sú ályktun er einmitt öfug: vistfangið er til staðar einmitt vegna þess að staðbundin eining bjó til tenginguna. Regla sem er skrifuð þannig hleypir inn hverjum sem kemst að hlustunaraðilanum.

Prófaðu regluna, ekki síðuna

Síða sem hleðst sannar að framsendingarleiðin virki og segir ekkert um eignun. Prófaðu notanda vistfangsins: aðgangsregluna, hraðatakmörkin, endurskoðunarfærsluna, landfræðilegu uppflettinguna.

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

Berðu saman leyfða ytri beiðni við bæði framenda- og bakendaskrárnar, og staðfestu að regla sem ætti að neita neiti enn og regla sem ætti að leyfa leyfi enn. Ef línan í skránni er rétt en reglan hagar sér samt eins og allir séu staðbundnir, þá les reglan annan reit en þann sem þú lagfærðir.

Ljúktu með því að skrifa eignunarhlekkinn í uppsetningarnóturnar: hvaða hlustunaraðili, hvaða framsendandi, hvaða hausur eða kortlagning, og hvaða bakendi er stilltur til að treysta honum. Næsta manneskja sem les línu í skránni þarf alla fjóra, og skortur á þeirri nótu er ástæðan fyrir því að sama miðinn opnast aftur ári síðar. Haltu henni við hlið stillinganna, ekki í spjallþræði.