물론 후자

다른거 다 잘 꽁꽁 숨겨놨는데 저거 하나를 실수했누

실수인지 의도인지는 정확하게 알수는 없는데

1. 원격기능이나 파일전송같은 관리차원에서 의도적으로 저 도메인에 실제 아이피를 노출시켰을 가능성

2. 실수로 해당 도메인에 클라우드플레어 경유기능을 끈 경우

두가지로 볼 수 있어

그리고 WebNX는 호스팅업체 이름이야

이름이 1, 2로 된거 보면 아마도 클라우드플레어 측에 장애가 일어났을 경우에 서버 헬스체크용 또는 이중화 용도 등으로 뚫어둔 거일수도

만약 저 도메인마저도 클라우드플레어로 경유시켰다면 알기 더 힘들어졌겠지

ㄴㄴㄴ 클플해도 다 찾을 수 있음

단지 조금 귀찮을 뿐

클라우드플레어의 투명성 보고서에 따르면 미국 법원의 요청이 있다면 제공할 수 있다고 나와있는것같아

메갈의 조상님 정도라는데

해충연합갤러리였구나

약간 잘못알고있는것같은데, HTTP의 경우에는 TCP위에서 통신되는 프로토콜이라서 헤더에 송신지 수신지 아이피가 포함되서 나가게 되어있어

실제로 HTTP에서 웹페이지에 접근하는 순서는 도메인에 대한 네임서버를 먼저 확인한 후 해당 아이피로 전달하는 플로우를 갖고있는데

도메인에 대한 아이피를 찾기 위한 플로우가 먼저 진행되는데 해연갤 기준으로 보자면

1. "hosts 파일"에서 hygall.com의 아이피를 조회

2. "Root 네임서버"에서 com에 대한 네임서버를 조회

3. "com 네임서버"에서 hygall.com의 아이피를 조회

4. "com 네임서버"에서 hygall.com에 대한 네임서버를 조회

5. "hygall.com 네임서버(클라우드플레어)"에서 hygall.com의 아이피를 조회

하는 방식이야.

하지만 맨 처음 해연갤에 접속할때는 저 플로우를 모두 처리했지만 /etc/hosts에 해연갤에 대한 아이피를 등록한 이후에는 1번항목만 처리하고 HTTP를 이용해 접속데이터를 보내는거라서 송신지와 수신지 모두를 다 프로토콜에 담고있어

물론 서버에서도 클라우드플레어를 통해 접속했는지 아닌지 확인할 수 있는 방법 또한 있지 특히 해연갤에서 쓰고있는 nginx같은 경우에는 아예 컨피그가 내장되어있을 정도니까

아 맞네 순간 착각했음ㅋㅋ 써놓고 이상해서 수정하려고보니 답글 달려있네

멋지다 너 나랑 같이 일하자

출발지 도착지 정보가 없다(x)

(클라이언트 입장)내가 요청보내는 곳이 진짜 애플리케이션 서버인지, (서버 입장) 요청을 보낸 주소가 진짜 클라이언트 주소인지 알 수 없다 (o)

예를 들어 클라이언트 주소가 223.62.10.11 인데 121.39.41.7에 접속한다면, 해당 아이피는 보통은 실제 서버의 주소가 아닌 로드 밸런서 등의 주소일 거고... 실제로 요청을 처리하는 애플리케이션 서버는 송신자 주소가 로드 밸런서의 내부 사설 IP인 10.21.100.12 따위로 된 요청을 받게 되어서 별도로 외부망에서 들어온 요청을 앞단에서 로깅하지 않았다면 애플리케이션 서버 자체는 요청의 실제 송신자를 특정불가함. 옛날에 배울 때 이런 정보 넘겨주기 위해 헤더값으로 넣거나 이런것도 해봤던거 같은데 가물가물 하다...

실제 요청을 보내고 받는 아이피를 정확하게 알 수는 없지 네 말마따나 방화벽이 있거나 라우터나 공유기단에서 NAT시키는경우나 로드밸런서가 있다면. 거기에 로깅까지 안하면 답 없는거지 뭐.

하지만 그래도 그 중 최종적으로 요청하는 아이피는 나타나니까 거기서 데이터를 갈아엎던 하면 뭔가 나오지 않을까..........

뭔지 모르지만 ㅊㅊ

"Root 네임서버"는 전 세계에 있는 com, kr, net, us 등등 도메인주소 맨 끝 단어(?)에 대한 네임서버를 저장해놓은 데이터베이스인데

"Root 네임서버"한테 "얘 아냐?" 하고 물어보면 "ㄴㄴ 나는 모르고 'com 네임서버'가 알거야" 하고 알려주는거지

그럼 똑같이 "com 네임서버"한테 "얘 아냐?"하고 물어보고 "모르는데, 'hygall.com 네임서버(클라우드플레어)'는 알거야"라고,

클라우드플레어한테 또 "너는 얘 아냐?" 물어보면 "ㅇㅇ 얘 앎 뫄뫄로 가면 만날 수 있어" 하고 답해주는게 네임서버 플로우고

그 과정을 건너뛰게 하는게 /etc/hosts 파일인거지

문체부에서 게등위에 민원 떠넘기듯이 이렇게 밑으로 계속 떠넘겨서 정보를 뱉어내는 거임

와 시발 한방에 이해했다

되게 잘안다

부가 설명으로 루트 네임서버는 “.”임

우리가 보는 url엔 생략되어 있는데dogdrip.net. << 마지막 .

. 아래에 com, net 등등 NS가 등록 되어 있는 거

맞아 실제로 네임서버 레코드 등록할때 마지막에 . 찍어서 마무리 찍는 이유도 루트네임서버를 따르라는 뜻에서 하는거였던거같기도하고

hosts 파일이 무조건 우선인 이유는 인터넷의 역사와 관련이 있는데 전세계 대학과 연구기관 등만 연결되어있던 인터넷 초창기엔 DNS 서버가 없어서 각 기관의 도메인 정보를 담은 커다란 하나의 hosts 파일을 서로 돌려가며 쓰곤 했었음. 우리 업데이트 했어요 하고 FTP에 올리고 나면 이미 다른 사람들이 자기 도메인 적어 업뎃해놓은거랑 충돌나고, 서로 버전이 안맞아 접속 안되고... 이러다가 이거 좀 자동화되면 안됨? 해서 DNS가 탄생. 이때의 흔적으로 지금도 hosts 파일의 내용이 무조건 최우선임

Virtualhost 설정해둔듯

이제 모든게 설명되네

한 서버에 한개의 홈페이지만 운영하는건 자원낭비라 대부분 저런 개인이 운영하는 것 같은 홈페이지는 한 서버를 vhost로 나눠서 사용하지

비추 실명제

클플의 타겟서버가 webnx인 것으로 추측되고있어

webnx는 단순히 호스팅업체니까