curl, wget, python 으로는 되는 http, https 통신이 telnet으로는 커넥션 조차 안 되는 현상이 발생 하였다. 앞단에 프락시가 있다는 것은 알고 있었다.
프락시 관련 설정을 한 것이 없으므로 앞단의 프락시는 투명 프락시일 것이라고 예상해 볼 수 있다.
transparent proxy라고 하면 서버 관리자가 어떤 설정을 했을까 추정을 해 보면 이렇다.
... 근데 아니었다.
생각해보니 MITM에 의한 보안을 한다고 치면, SSL의 경우 프락시를 태우는 순간 인증서 오류가 발생할 것이다. dns을 스푸핑 해서 목적지 도메인을 프락시로 바꿔치기 해놨을테니까. 그래서 대기업 보안에서는 사설 가짜 인증서을 프락시 IP와 목적지 도메인과 매핑시켜두고 CA 등록을 유도한다. 지금은 이 상황도 아니다. 결과적으로 transparent proxy는 아닌 것 같다.
로컬 도메인 사전에 장난을 쳐놨거나 getaddrinfo 류의 함수가 dns를 찾는 과정이 다른 것은 아닐까? 그래서 어떤 함수로 dns를 콜 하면 프락시 IP를 받아타고, 어떤 함수로 dns를 호출하면 ns에 정상 호출을 하거나..
... 아니었다.
결과는 내 뒷자리 매니저님이 찾아주셨는데, 시스템 관리자가 환경변수에다가 http_proxy, https_proxy를 박아둔 것이다. 물론 proxy 설정이 있는지 config 류를 찾아는 보았으나, 환경변수를 뒤져볼 생각을 먼저 했어야 한다. 결국 투명 프락시가 아니었다.
검색을 해보니 이게 그냥 일반 상식인 것이었다. 상식을 몰라서 괜히 딴 생각을 한 것.
wget, curl, python이 모두 같은 이름의 환경변수를 참조한다는 것은 뭔가의 프로토콜인가 싶어서 조사해보니 표준은 아닌 것 같다. rfc에 없다. 관례인가?
cgi에서 환경변수로 토쓰하는 HTTP_PROXY도 있는데 이는 웹서버 의존성이 있고, 정확한 리스트가 표준화 되어 있는 것은 아닌 것 같다. 이것은 해킹이 가능하다. 이름이 같기 때문이다.