Зошто Port-Share ги прикажува сите посетители на сајтот како localhost

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

Проверките подолу одат од кабелот навнатре. Запрете на првата што ја објаснува вредноста што ја гледате, бидејќи секој следен чекор претпоставува дека претходните веќе се точни. Ниту една од нив не бара да ја погодувате конфигурацијата на предниот дел.

Следете ги двете врски, не линијата во дневникот

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

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

Првата команда покажува кому му припаѓа јавниот слушател. Втората ги покажува врските што пристигнуваат на портата на заднината, а адресата на нивниот партнер е онаа што ќе ја испечати дневникот за пристап. Ако тој партнер е loopback, дневникот е точен и информацијата е изгубена еден слој порано. Преименувањето на полето во дневникот или вклучувањето на модул за IP на клиентот нема да врати адреса што врската никогаш не ја носела.

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

Препраќањето на транспортот не е вметнување заглавија

Препраќачот преместува бајти. Не го парсира HTTP, затоа не може да вметне заглавие во барање што никогаш не го чита како барање, и не може да додаде ништо во TLS тек што го пропушта недопренат. Модул што очекува заглавие од посредник ќе продолжи да чека такво што ниту еден компонент не го произведува.

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

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

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

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

Споделувањето на портата има опционален аргумент за директориум што запишува мапирање помеѓу оригиналната изворна адреса и врската за препраќање, на платформи каде оваа функција е имплементирана. Се очекува веб-страната да го консултира тоа мапирање; тоа не е заглавие и не се вметнува во барањето.

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

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

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

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

Три дизајни покриваат повеќето потреби. Држете ги јавниот слушател и веб-слушателот одделно, така што веб-серверот гледа вистински партнери и нема проблем со припишување. Ставете напред обратен посредник што разбира HTTP, завршете го или парсирајте го барањето таму и дозволете му да постави препратено заглавие за заднина што му верува само на тој посредник. Или задржете го споделувањето на портата и прифатете дека дневниците го покажуваат скокот, со правила за пристап напишани против идентитетот на апликацијата, а не против адреса.

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

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

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

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

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

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