TCP 8080포트로 패킷이 나가질 않습니다.
글쓴이: sephiron / 작성시간: 일, 2016/01/31 - 9:50오후
KLDP에 오랜만에 글을 쓰네요. 마땅히 물어볼만한 곳이 없어서 여기에 질문을 올립니다.
현재상황
- 수원에서 티브로드 인터넷을 사용중
- 다른 인터넷 서비스는 다 잘 작동하는데 tcp 8080포트에서 서비스하는 모든 서버에 연결이 안됨. 예를 들면, http://portquiz.net:8080/ 같은 것들
- 인터넷 공유기를 사용중이나 관련성 없는 것으로 확인, 데스크탑에 모뎀을 직접 연결해봐도 똑같음
- 티브로드 네트워크 담당자(과장)과 통화한 결과, "8080포트의 경우 In만 막아놓았다. Out은 당연히 되어야 한다. 왜 니네집만 그러냐. 니가 정 못믿겠다면 주말까지 ACL을 다 내려놓겠다. 해볼거 있으면 해봐라"라는 이야기까지 들었음. 물론 그래도 안됨
- 광케이블 모뎀 자체의 관리기능이 있지는 않느냐고 묻자, 그런것은 없다함
- ubuntu(mint)에서
mtr -T -P8080 portquiz.net -r -c20을 실행하면,
라고 나옴. 192.168.0.1은 공유기, 121.254.30.1은 게이트웨이임
어떻게 하면 해결할 수 있을까요?
File attachments:
| 첨부 | 파일 크기 |
|---|---|
 11.PNG | 19.84 KB |
Forums:
확인해볼 사항입니다.
- 공유기 포트포워딩과 IP주소 (1개만 연결)
- 방화벽 포트가 열렸는지 확인 (윈도우. 가상PC)
- 백신 확인
- 가상 PC로 접속이 가능한지 확인. (안될경우. IP대역을 같게 해주거나. 브릿지 네트워크로 연결하는 등에 방법이 있습니다.)
이제 외부. 내부에서 telnet ip주소 포트번호로 접속해보면. 확인이 가능합니다.
외부 접속 확인
telnet 233.222.153.235 8080
내부 접속 확인
telnet 192.168.0.4 8080
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
iptables 해보셨나요? 내부 방화벽에 막아 놓은
iptables 해보셨나요?
내부 방화벽에 막아 놓은 것 같은데...
우분투면 sudo ufw 8080 해보세요.
아닙니다. windows, android 모두
아닙니다. windows, android 모두 안됩니다. 테더링 등으로 게이트웨이를 바꿔주면 잘 작동하는 것을 보니 pc 설정 문제는 아닙니다.
음 ..
8080 을.. Inbound SYN 패킷만 막았다는 의미겠죠..?
그게 아니라면 통신 안 되는게 맞을텐데..;;
일단.. G/W 쪽이 문제라는 걸 증명하려면.. 어디 공인 IP 쪽에 패킷 덤프 되는 서버 하나 띄워놓고..
내부에서 보낸 SYN 패킷이 도착하는지 확인해 보면.. outbound 는 문제 없는지 확인 될테고..
서버에서 SYN/ACK 보냈는데.. 내부에서 그걸 못받은 거라면.. inbound 에 문제가 있는 건데..
뭐.. drop 되었을 수도 있고.. 아니면 port forwarding 걸려 있거나 NAT 같은데 문제가 있어서 안 되는 걸 수도 있고..
하튼.. 먼저 증상을 구체적으로 확인해 봐야 할 것 같네요.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
outbound가 문제입니다.
in은 ISP에서 진작에 막아놨구요, out도 안되더라고요.
TCP 8080포트로 syn Traceroute 막히는 건 확인했습니다.
문제는 어느 G/W인지 잘 모르겠다는 거죠 ㅠ.ㅠ.
알 수 있는 방법이 없을까요? 2. 18.에 ISP네트워크 담당자가 집에 오기로 했는데, 느낌상 그사람도 모를거 같아요 ㅠ.ㅠ
음 ..
단순히 mtr 로는 어느 구간에서 막혔는지 알 수 없을겁니다.
mtr 이 syn 패킷의 ttl 을 낮게 설정해서 순서대로 보내서, 되돌아 오는 ICMP time exceeded in-transit 패킷을 보고, 중간 경로를 보여주는데..
121.254.30.1 에서는 ttl 이 0 이 된 syn 패킷을 drop 하면서 응답을 했지만.. 그 이후에 있는 뭔가는 ICMP 응답을 하지 않았다는 것 일뿐입니다.
패킷 덤프 떠 보니까 ttl 을 1 부터 9 까지 차례로 증가시키던데..
중간에 라우터가 9개 이상이면, 마지막 패킷도 portquiz.net 까지 못가고 drop 되었을 겁니다.
(이쪽에서 traceroute 해보면.. route 경로가 14개 정도 나오네요..)
어쨌든 공유기나 PC는 직접 확인 가능하니, "PC -- 공유기 -- 서버" 구성에서 PC 든 공유기든 문제 없다는 것이 확인 되었다면..
"PC -- 공유기 -- 그쪽 -- [인터넷] -- 서버" 처럼 구성해 놓고..
서버에 syn 패킷이 도착하는지 직접 확인해 봐야 한다는 얘기입니다.
서버에 syn 패킷이 도착했고, syn/ack 가 나갔는지 확인 되면..
결과적으로 그쪽에서 sport 8080 에서 오는 syn/ack 를 막고 있다는 소리가 되지 않을까요..?
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
자세한 답변 감사합니다.
ISP의 ROUTER를 리셋한 후 이전 ACL을 그대로 복사해서 붙여넣었더니 됐습니다. 네트워크 담당자도 "왜 이런지는 모르겠는데 됐으니 됐다"라고 웃으면서 갔네요.
라우터 버그 같네요.
관심 가져 주셔서 감사합니다.
보안 정책 문제 일수도 있습니다.
멀쩡한데 안되는 경우. 관련 분야 엔지니어 또는 담당자가 조금 깨작거리면 되는 경우가 있습니다. 기계라는 존재가 인간성이 없으니 사람이 꼭 개입해야 한다는 Policy이죠. 네트워크 담당자가 답이었던 케이스.
댓글 달기