Miksi Port-Share saa kaikki verkkosivuston vierailijat näyttämään localhostilta

Jokainen käyttölokin rivi näyttää saman loopback-osoitteen, vaikka sivu latautuu ja varmenne tarkistetaan oikein. Mikään ei ole rikki siinä mielessä, että se olisi tavoittamaton, ja juuri siksi tämä kestää kuukausia. Rikki meni kohdistus: verkkotaustajärjestelmä tallentaa sen hypyn osoitteen, joka välitti yhteyden eteenpäin, ja jokainen myöhempi päätös, joka luotti lokiin, peri saman väärän vastauksen.

Alla olevat tarkistukset etenevät kaapelista sisäänpäin. Pysähdy ensimmäiseen, joka selittää näkemäsi arvon, koska jokainen myöhempi vaihe olettaa aiempien olevan jo tosia. Mikään niistä ei vaadi front-endin kokoonpanon arvaamista.

Seuraa kahta yhteyttä, älä lokiriviä

Port-Share multipleksoi kaksi protokollaa yhteen TCP-kuuntelijaan. OpenVPN tutkii saapuvan yhteyden ensimmäiset tavut, pitää sen, kun se näyttää sen omalta protokollalta, ja luovuttaa kaiken muun toiselle kohteelle. Tämä kohde on yleensä verkkopalvelin samassa isännässä, joten verkkopalvelimen hyväksymän pistokkeen vertaisena on OpenVPN-prosessi.

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

Ensimmäinen komento näyttää, kuka omistaa julkisen kuuntelijan. Toinen näyttää yhteydet, jotka saapuvat taustajärjestelmän porttiin, ja niiden vertaisosoite on se, jonka käyttöloki tulostaa. Jos tuo vertainen on loopback, loki on tarkka ja tieto katosi kerrosta aiemmin. Lokikentän uudelleennimeäminen tai asiakas-IP-moduulin käyttöönotto ei palauta osoitetta, jota yhteys ei koskaan kantanut.

Tämä on tarkistus, joka ratkaisee kaiken muun. Jos taustajärjestelmän vertainen on selaimen osoite, portin jakaminen ei ole ongelmasi ja lokin muoto on.

Siirtokerroksen edelleenohjaus ei ole otsikon syöttämistä

Välittäjä siirtää tavuja. Se ei jäsennä HTTP:tä, joten se ei voi lisätä otsikkoa pyyntöön, jota se ei koskaan lue pyyntönä, eikä se voi lisätä mitään TLS-virtaan, jonka se päästää läpi koskemattomana. Välityspalvelimen otsikkoa odottava moduuli jää odottamaan sellaista, jota mikään komponentti ei tuota.

Kaksi mekanismia voi kantaa alkuperäisen osoitteen, ja molemmat vaativat sopimuksen molemmissa päissä. PROXY-protokolla lisää yhteyden alkuun pienen otsikon, ja taustajärjestelmä on määritettävä odottamaan sitä; taustajärjestelmä, joka ei odota sitä, käsittelee nuo tavut pyynnön alkuna ja epäonnistuu hämmentävällä tavalla. Luotetut välityspalvelimen otsikot, kuten X-Forwarded-For, toimivat, kun HTTP:n ymmärtävä välityspalvelin asettaa ne ja taustajärjestelmälle kerrotaan, mitkä vertaiset saavat väittää niitä.

Kumpikaan ei ole automaattinen, eikä kumpikaan ole oletuksena turvallinen. Taustajärjestelmä, joka uskoo jokaista saapuvaa välitettyä otsikkoa, antaa asiakkaan valita oman osoitteensa, mikä muuttaa lokin epätarkkuuden pääsynvalvonnan ohitukseksi. Suorita esittely kerran testi-isännässä ennen kuin luotat mihinkään otsikkoon tuotantopolulla.

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

Valinnainen lähdekartoituksen hakemisto

Portin jakamisella on valinnainen hakemistoargumentti, joka tallentaa kartoituksen alkuperäisen lähdeosoitteen ja välitysyhteyden välillä alustoilla, joilla ominaisuus on toteutettu. Verkkopuolen odotetaan tarkistavan tämän kartoituksen; se ei ole otsikko, eikä sitä syötetä pyyntöön.

Tuo suunnittelu kannattaa tuntea, koska se selittää, miksi jotkin käyttöönotot raportoivat todellisia osoitteita ja toiset eivät, vaikka front-endin kokoonpano näyttää samalta. Ero on vastaanottavalla puolella, ja se asuu yleensä moduulissa tai korjauksessa, jota useimmat paketoidut verkkopalvelimet eivät ota oletuksena käyttöön. Lue verkkopalvelimesi dokumentaatiosta, minkä tarkan koukun se tarjoaa, ja vahvista, että moduuli on ladattu sen sijaan että olettaisit niin.

Jos valitset tämän tien, kohtele sitä kahden puoliskon integraationa: kartoitus, jonka välittäjä kirjoittaa, ja haku, jonka taustajärjestelmä tekee. Vahvista molemmat ja varmista, että hakemisto kestää uudelleenkäynnistyksen eikä kasva rajattomasti kiireisellä kuuntelijalla.

Päätä, mikä komponentti takaa osoitteen

Ennen kokoonpanon muuttamista nimeä komponentti, joka saa väittää asiakkaan osoitetta, ja komponentit, jotka saavat uskoa sitä. Yksi kirjattu vastaus estää tavanomaisen ajautumisen, jossa kolme eri kerrosta luottaa kukin eri lähteeseen.

Kolme suunnittelua kattaa useimmat tarpeet. Pidä julkinen kuuntelija ja verkkokuuntelija erillään, jotta verkkopalvelin näkee todelliset vertaiset eikä kohdistusongelmaa ole. Aseta eteen HTTP:n ymmärtävä käänteinen välityspalvelin, päätä tai jäsennä pyyntö siellä ja anna sen asettaa välitetty otsikko taustajärjestelmälle, joka luottaa vain siihen välityspalvelimeen. Tai pidä portin jakaminen ja hyväksy, että lokit näyttävät hypyn, kun pääsynvalvontasäännöt on kirjoitettu sovelluksen identiteettiä eikä osoitetta vastaan.

Se, mikä ei toimi, on kohdella välitettyä loopback-osoitetta todisteena siitä, että pyyntö syntyi tällä koneella. Tämä päätelmä on täsmälleen päinvastainen: osoite on läsnä juuri siksi, että paikallinen komponentti teki yhteyden. Niin kirjoitettu sääntö päästää sisään jokaisen, joka pääsee kuuntelijaan.

Testaa sääntöä, älä sivua

Latautuva sivu todistaa, että välityspolku toimii, eikä kerro kohdistuksesta mitään. Testaa osoitteen kuluttajaa: pääsynvalvontasääntöä, nopeusrajaa, auditointimerkintää, geo-hakua.

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

Vertaa valtuutettua ulkoista pyyntöä sekä front-endin että taustajärjestelmän tietueisiin ja vahvista, että säännön, jonka pitäisi hylätä, hylkää yhä, ja sen, jonka pitäisi sallia, sallii yhä. Jos lokirivi on oikein mutta sääntö käyttäytyy yhä kuin kaikki olisivat paikallisia, sääntö lukee eri kenttää kuin sen, jonka korjasit.

Lopeta kirjoittamalla kohdistusketju käyttöönottomuistiinpanoihin: mikä kuuntelija, mikä välittäjä, mikä otsikko tai kartoitus ja mikä taustajärjestelmä on määritetty luottamaan siihen. Seuraava henkilö, joka lukee lokirivin, tarvitsee kaikki neljä, ja juuri sen muistiinpanon puuttuminen saa saman tiketin avautumaan uudelleen vuoden kuluttua. Pidä se kokoonpanon vieressä, älä chat-ketjussa.