VPN 뒤에서 PHP의 REMOTE_ADDR가 실제로 말해 주는 것
웹 서버가 건네준 값이며 터널에 대한 질의가 아닙니다. 요청 경로를 따라가고, 누가 이를 다시 쓸 수 있는지 확인하고, 신원 판단은 애플리케이션에 두십시오.
VPN 사용자가 애플리케이션 로그에 게이트웨이에 속한 주소로 나타나는 이유, 또는 점심 이후에 바뀐 주소로 나타나는 이유를 누군가 묻습니다. 답은 이 값이 무엇인지에서 시작합니다. 웹 서버가 요청 환경에 넣은 하나의 항목입니다. 터널에 대한 질의도 아니고, 인증서 신원도 아니며, 그 번호가 한 사람의 것이라는 약속도 아닙니다. 이 세 가지 중 하나로 읽으면 서로 다른 방식으로 틀린, 자신감 있는 답이 나옵니다.
값은 서버에서 오고, 터널에서 오지 않는다
PHP는 스크립트를 실행한 쪽으로부터 요청 환경을 받습니다. PHP 서버 변수 참조는 이 항목들이 웹 서버가 만든 것이라고 설명하며, 사용 가능 여부는 요청이 어떻게 도착했는지에 달려 있습니다.
VPN의 명령줄 훅으로 실행되는 스크립트는 전혀 다른 실행 컨텍스트입니다. 웹 요청도, 클라이언트 소켓도, REMOTE_ADDR도 없습니다. 그래서 훅에 복사한 웹 코드는 잘못된 값이 아니라 빈 값을 냅니다. 훅에는 데몬이 채우는 자체 환경이 있고, 그 환경은 따로 문서화되어 있습니다. 그곳에서 REMOTE_ADDR을 찾는 것은 한 번도 설정된 적 없는 변수를 찾는 일입니다.
두 로그를 비교하기 전에 이 차이를 기억하십시오. 페이지 요청과 훅을 비교하고 있을지도 모르며, 그것은 비교조차 아닙니다. 먼저 실행 컨텍스트를 확인하고, 그다음 주소를 보십시오.
번호를 믿기 전에 요청 경로를 따라가라
보고된 주소는 웹 서버가 본 연결의 상대입니다. 클라이언트와 그 서버 사이에 무엇이든 넣으면 상대가 바뀝니다. 주소 변환, 종료, 부하 분산은 각각 관측을 사용자로부터 한 단계 더 멀리 밀어냅니다.
흔한 네 가지 경로는 네 가지 서로 다른 관측을 낳습니다.
| Path to the listener | What can be reported |
|---|---|
| Client routed straight to the private listener, no translation | The client's tunnel address |
| Gateway translates the source before forwarding | The gateway's translated address |
| Reverse proxy terminates the client and opens its own backend connection | The proxy's backend address |
| Load balancer in front of two proxies | Whichever hop the server treats as its peer |
경로를 목적지 이름, 주소 체계, 그리고 모든 변환 지점과 함께 적어 두십시오. 그 지도가 없으면 올바른 값과 잘못된 값이 로그 한 줄에서는 똑같아 보입니다. 도해 두 줄이 반나절의 논쟁을 아껴 줍니다.
교체는 설정된 곳에서만 일어난다
서버나 프레임워크는 클라이언트 주소를 의도적으로 교체할 수 있습니다. Apache의 remote-IP 모듈과 NGINX의 real-IP 모듈이 모두 그렇게 하며, PHP가 받는 값은 그 설정과 스크립트 핸들러에 넘긴 매개변수에 달려 있습니다.
그래서 REMOTE_ADDR이 언제나 손대지 않은 TCP 상대인 것은 아닙니다. 서버가 자체 정책을 적용한 뒤 보고하기로 선택한 상대입니다. 이 차이가 그 값이 증거인지 장식인지를 가릅니다.
이 배포에서 어느 필드가 권위 있는지, 교체가 일어날 때 원래 상대가 어떻게 보존되는지 서버 소유자에게 물으십시오. 아무도 답하지 못한다면 그 로그는 아직 아무것도 증명하지 못합니다.
전달 헤더를 신뢰로 읽지 마라
호출자는 스스로 전달 헤더를 보낼 수 있습니다. 쉼표로 나뉜 첫 항목을 검증된 사용자 주소로 다루는 것은 연결하는 누구든 믿기로 결정하는 일이며, 헤더의 목적과 정반대입니다. 헤더는 사슬을 기술하며, 신뢰할 수 있는 계층만이 그 사슬을 보증할 수 있습니다.
서버나 프레임워크의 신뢰 프록시 지원을 실제 프록시 사슬과 함께 설정해 사용하고, 그 사슬 밖 출처의 값은 버리게 하십시오. 손으로 쓴 파싱이 바로 흥미로운 장애 대부분이 사는 곳입니다.
프록시가 보고한 주소도 상류 방화벽이 보는 패킷 출처를 바꾸지 않습니다. HTTP 메타데이터와 네트워크 필터링을 별개의 관측으로 유지하십시오. 서로 다른 질문에 답하기 때문입니다.
판단에는 애플리케이션 신원을 사용하라
사용자 기록에 접근할 때는 인증된 주체와 애플리케이션의 인가 규칙에 의존하십시오. 내부 주소는 다시 할당될 수 있고, 변환된 주소 하나가 수백 명의 동시 사용자를 대표할 수 있습니다. 이 두 성질 모두 주소 검사로 고칠 수 없습니다.
운영에서 요청을 VPN 세션에 연결해야 한다면, 관측한 주소와 시각을 문서화한 변환 모델에 따라 권위 있는 세션 기록과 연결하십시오. 그래야 변호할 수 있는 연관이 생깁니다. 주소만으로는 그렇지 않습니다.
진단에는 서버 배열 전체가 아니라 필요한 몇 개 필드만 기록하십시오. 배열은 헤더와 인증 자료를 담을 수 있습니다. 유용한 결론은 이 값이 이 배포에서 무엇을 뜻하는지를 말하며, 어느 값이 가장 클라이언트처럼 보이는지가 아닙니다.