Sokeltsjinpart of trochstjoerde kop: hokker adres fertrouwe jo?

In oanfraach dy't by jo applikaasje oankomt, draacht twa soarten adresbewiis: it tsjinpart dat de netwurkferbining iepene, en in HTTP-fjild dat beweart it adres fan in eardere klant te wêzen. Se beantwurdzje ferskillende fragen. It sokeltsjinpart wurdt waarnommen, wylst de kop beweard wurdt troch wa't him skreaun hat, en gjin fan beide soe de oare stilwei ferfange moatte yn in loch of in tagongsregel. De fergeliking hjirûnder hâldt se apart en lit dan de iene opstelling sjen wêryn't de kop brûkber wurdt.

Beskriuw it paad foardat jo eat fergelykje:

Client -> approved reverse proxy -> application origin

Yn dy opstelling is it sokeltsjinpart fan 'e oarsprong ornaris de proxy, en in trochstjoerde kop kin de bewearing fan 'e proxy oer de klant drage. Syn wearde komt út 'e behearske relaasje mei dy proxy, net út 'e namme fan 'e kop.

Twa soarten adresbewiis

It sokeltsjinpart is in feit oer ien TCP-ferbining: eat hat in hânjûn fan dat adres foltôge. It is net needsaaklik de minske, it apparaat of it akkount dêr't jo om jouwe, want in VPN of in Tor-útgong kin legitim de boarne wêze dy't in tsjinst waarnimt. It bliuwt lykwols it ienige adres dat de host sels ferifiearre hat, en dat is syn hiele wearde.

In trochstjoerfjild is metadata oer in keatling. X-Forwarded-For, X-Real-IP en it standerdisearre fjild Forwarded kin troch elke klant skreaun wurde dy't in einpunt berikt dat se weromstjoert, dus har betrouberens hinget folslein ôf fan wa't tastien wie se yn te stellen.

Hâld beide yn 'e oanfraachkontekst ûnder ferskillende nammen. In applikaasje dy't it tsjinpart mei de kop oerskriuwt, ferliest it fermogen om letter in fertrouwensflater te rekonstruearjen, en dat is krekt it momint dat jo it nedich hawwe.

In kop ferleit de ferbining nea

It skriuwen fan in adres yn in trochstjoerfjild feroaret de boarne fan 'e TCP-ferbining dy't by de tsjinner oankomt net, en it feroaret ek nearne op it paad de rûteleasing. Gewoane VPN-rûteleasing of boarne-NAT leveret ferkear sûnder hokker HTTP-kop dan ek. Likegoed skriuwt in transytpoarte in goed beskerme HTTPS-útwikseling net oer sûnder de opstelling fan it TLS-einpunt te feroarjen.

De omkearde flater is like gewoan: HTTPS makket in trochstjoerde kop fan 'e klant net wier. It beskermet it ferfier fan in falske bewearing like goed as fan in wiere.

As in kollega in kopfersin foarstelt om in rûteleasingsprobleem op te lossen, is de diagnoaze al misgien. Reparearje it paad, of reparearje de proxykonfiguraasje dy't de kop skriuwt.

Nammenei de proxy dy't bewearje mei

Twa regels meitsje in trochstjoerfjild brûkber, en beide binne konfiguraasje ynstee fan koade. De râne normalisearret of smyt alles fuort wat fan bûten komt, neffens syn eigen dokumintearre gedrach foar dy fjilden. Dêrnei nimt de oarsprong in ferfangend adres út it proxypaad dat jo neamd hawwe en út neat oars. Dy twadde regel jildt allinnich salang't klanten de oarsprong net op in oare wize berikke kinne, want in oarsprong dy't sawol direkte as fia proxy kommen oanfragen beäntwurdet, wit net hokker fan beide er tsjinnet.

It echte-IP-module fan NGINX lit de splitsing dúdlik sjen. set_real_ip_from neamt de ôfstjoerders waans bewearing telt, en real_ip_header seit hokker fjild it draacht; de earste docht it fertrouwen, de twadde seit allinnich wêr't jo sjen moatte.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

In rjochtline foar kopkar allinnich fêstiget noch neat oer wa't de wearde stjoerd hat.

Ferfiersfeiligens moat de hiele wei rinne tusken de komponinten dy't jo fertrouwe. In râne dy't korrekt normalisearret, ferliest dy wearde op it momint dat in ûnbeskerme hop leger del ien oars de bewearing bewurkje lit wylst dy reizget.

Behannel keatlings mei mear as ien hop bewust

Ferskate proxies hawwe in eksplisyt keatlingmodel nedich. Nim net de linkerskou of rjochterskou kommaskieden wearde om't in blogberjocht dat die; fyn út hokker fan jo proxies taheakket, hokker ferfangt en hokker it ynkommende fjild bewarret. NGINX kin bygelyks de list efterstfoar troch syn fertroude set rinne en stopje by it earste adres dat it net besit, en dat is de regel fan dat produkt, net in wet dy't elk ramt folget. Lês de dokumintaasje fan jo eigen proxy mei deselde twa fragen: hokker wearde kiest er, en hokker ôfstjoerders leaut er?

Skriuw de keatling del: hopfolchoarder, hokker hop it fjild set en hokker hop ynkommende kopyen fuortsmyt. Hâld dy notysje dan neist de proxykonfiguraasje, net allinnich yn 'e ticket. Test it dan troch in oanfraach mei in ferfalske kop troch it goedkarde falidaasjeproses te stjoeren en te befêstigjen dat de oarsprong it negearret.

As jo in hop tafoegje, besjoch dat dokumint dan op 'e nij. In nije lêstbalansearder foar de fertroude proxy yn kin feroarje hokker adres wint sûnder dat immen de applikaasje bewurket.

Hâld beide waarnimmings yn it loch

Wêr't diagnostyk tastien is, loch dan it tsjinpart fan 'e ferbining en it normalisearre klantadres as twa aparte fjilden, en foegje allinnich de trochstjoermetadata ta dy't it doel echt nedich hat. Bewiis de ynset dan mei twa oanfragen: ien fia proxy dy't beide wearden ferstannich fêstlizze moat, en ien direkte poging nei de oarsprong dy't wegere wurde moat.

Tink derom wat it pear betsjut. De kop foeget kontekst ta dy't levere wurdt troch in komponint dy't jo keazen te fertrouwen; it tsjinpart bliuwt it ienige adres dat jo host wier sjoen hat. Gjin fan beide is bewiis fan yndividuele identiteit, en in ûntwerp dat ien fan beide as bewiis behannelet, sil him oer immen fersinne.