Зашто Port-Share чини да сви посетиоци сајта изгледају као localhost

Сваки ред у дневнику приступа приказује исту loopback адресу, док се страница учитава и сертификат се исправно проверава. Ништа није покварено у смислу недоступности и зато ово преживљава месецима. Покварило се приписивање: веб позадина бележи адресу скока који је проследио везу, а свака каснија одлука која је веровала дневнику наследила је исти погрешан одговор.

Провере испод иду од кабла према унутра. Зауставите се на првој која објашњава вредност коју видите, јер сваки каснији корак претпоставља да су претходни већ тачни. Ниједна од њих не захтева нагађање конфигурације предњег дела.

Пратите две везе, а не ред у дневнику

Port-Share мултиплексира два протокола на једном TCP слушачу. OpenVPN прегледа прве бајтове долазне везе, задржи је кад изгледа као његов сопствени протокол, а све остало предаје другом одредишту. То одредиште је обично веб сервер на истом хосту, па прихваћени сокет веб сервера има OpenVPN процес као свог партнера.

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

Прва команда показује коме припада јавни слушач. Друга показује везе које долазе на порт позадине, а адреса њиховог партнера је она коју ће дневник приступа исписати. Ако је тај партнер loopback, дневник је тачан и информација је изгубљена један слој раније. Преименовање поља у дневнику или укључивање модула за IP клијента неће вратити адресу коју веза никада није носила.

Ово је провера која одлучује све остало. Ако је партнер позадине адреса прегледача, дељење порта није ваш проблем, него формат дневника.

Прослеђивање транспорта није убацивање заглавља

Прослеђивач премешта бајтове. Не парсира HTTP, па не може да убаци заглавље у захтев који никада не чита као захтев, нити може да дода било шта TLS току који пропушта нетакнут. Модул који очекује proxy заглавље наставиће да чека оно које ниједна компонента не производи.

Оригиналну адресу могу да носе два механизма и оба захтевају сагласност на обе стране. PROXY протокол додаје мало заглавље на почетак везе, а позадина мора бити конфигурисана да га очекује; позадина која га не очекује третираће те бајтове као почетак захтева и неуспети на збуњујућ начин. Поуздана proxy заглавља попут X-Forwarded-For раде када их поставља proxy који разуме HTTP и када се позадини каже који партнери смеју да их тврде.

Ниједно није аутоматско и ниједно није сигурно по defaultu. Позадина која верује сваком долазном прослеђеном заглављу допушта клијенту да одабере сопствену адресу, што нетачност у дневнику претвара у заобилажење контроле приступа. Изведите демонстрацију једном на тестном хосту пре него што поверите било ком заглављу на продукцијском путу.

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

Опциони директоријум мапирања извора

Дељење порта има опциони аргумент директоријума који бележи мапирање између оригиналне изворне адресе и везе прослеђивања, на платформама где је та функција имплементирана. Очекује се да веб страна консултује то мапирање; то није заглавље и не убацује се у захтев.

Тај дизајн вреди знати јер објашњава зашто нека постављања пријављују стварне адресе а нека не, уз наизглед идентичну конфигурацију предњег дела. Разлика је на страни примања и обично живи у модулу или закрпи коју већина пакованих веб сервера не укључује по defaultu. Прочитајте документацију свог веб сервера за тачну куку коју нуди и потврдите да је модул учитан уместо да то претпостављате.

Ако кренете тим путем, третирајте то као интеграцију с две половине: мапирање које пише прослеђивач и претрагу коју изводи позадина. Проверите обоје и потврдите да директоријум преживљава рестарт и да не расте неограничено на заузетом слушачу.

Одлучите која компонента јамчи за адресу

Пре него што промените конфигурацију, именујте компоненту којој је допуштено тврдити адресу клијента и компоненте које смеју томе да верују. Један записан одговор спречава уобичајено одступање у којем три различита слоја верују различитом извору.

Три дизајна покривају већину потреба. Држите јавни слушач и веб слушач одвојено, тако да веб сервер види стварне партнере и нема проблема с приписивањем. Поставите напред обрнути proxy који разуме HTTP, прекините или парсирајте захтев ту и допустите му да постави прослеђено заглавље за позадину која верује само том proxyју. Или задржите дељење порта и прихватите да дневници показују скок, с правилима приступа писаним према идентитету апликације, а не према адреси.

Оно што не функционише јесте третирати прослеђену loopback адресу као доказ да је захтев настао на овом рачунару. Тај закључак је управо обрнут: адреса је присутна управо зато што је локална компонента успоставила везу. Правило написано тако пропушта свакога ко може да дође до слушача.

Тестирајте правило, не страницу

Страница која се учита доказаће да пут прослеђивања ради и не говори ништа о приписивању. Тестирајте потрошача адресе: правило приступа, ограничење брзине, запис у ревизији, geo претрагу.

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

Упоредите овлашћени спољни захтев с оба записа, предњим и стражњим, и потврдите да правило које би требало да одбије још увек одбија, а оно које би требало да пропусти још увек пропушта. Ако је ред у дневнику тачан али се правило и даље понаша као да су сви локални, правило чита друго поље од онога које сте поправили.

Завршите тако што ћете ланац приписивања уписати у белешке за постављање: који слушач, који прослеђивач, које заглавље или мапирање и која је позадина конфигурисана да му верује. Следећој особи која прочита ред у дневнику требаће сва четири, а одсуство те белешке је начин на који исти тикет поново отвара се годину касније. Држите је уз конфигурацију, а не у chat нити.