☰

iptables/https: 라우터는 포트 443에서 들어오는 트래픽을 가져옵니다.

tag-icon • tag-icon iptables nginx https
iptables/https: 라우터는 포트 443에서 들어오는 트래픽을 가져옵니다.

나는 이것이 nginx/https의 문제라고 생각하지만, iptables내가 오해하는 것과 관련이 있을 수도 있습니다.

저는 최근에 웹 서버(nginx)와 인터넷 사이의 라우터에 방화벽을 설정했습니다. Nginx는 포트 80 및 443에서 수신 대기하도록 설정되어 있으며 Let's encrypt 인증서를 사용하여 대부분의 80개 호출을 443으로 리디렉션합니다. 적절한 전달을 사용하면 모든 것이 잘 작동합니다. 적어도 아직 어떤 결함도 발견하지 못했습니다.

방화벽(iptables 필터 테이블)은 ACCEPT정책으로 설정되어 있지만 패킷이 체인 끝에 도달하면 이를 기록하고 삭제하는 체인 INPUT으로 전달됩니다 .LOGDROP

로그를 검토한 결과, 서버 포트 443에서 라우터로 전송된 패킷이 삭제된 것을 발견했습니다. 예(MAC 및 IP 주소 무작위화, .136예 서버, .122예 라우터):

Oct 10 05:18:47 ASUS user.warn kernel: IPTables-Dropped: IN=br0 OUT= MAC=3C:AE:78:D4:B1:E3 SRC=192.168.1.136 DST=192.168.1.122 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10743 DF PROTO=TCP SPT=443 DPT=33272 WINDOW=0 RES=0x00 RST URGP=0

이러한 시도는 밤사이에 반정기적으로(10분마다 1~3회 시도) 나타났다가 사라집니다.

로그를 올바르게 해석했다고 가정하면 서버는 https 포트에서 직접 라우터에 연결합니다. 이는 말이 되지 않습니다. 라우터에 암호화되거나 암호화되지 않은 웹 콘텐츠가 필요한 이유는 무엇입니까? 묻지도 않고 받는 것 같나요?

FORWARDhttps 콘텐츠에 대한 외부 요청이 체인을 양방향으로 통과하므로 여기에 표시되지 않는다고 가정합니다 . 내가 말했듯이 AFAICT 서버에 대한 모든 https 요청은 예상대로 응답됩니다.

내 질문은 다음과 같습니다

이 패킷에 대한 가능한 설명은 무엇입니까? 이상한 서버 틱으로 인해 nginx가 요청하지 않고 패킷을 보내게 됩니까? 아니면 어딘가에 있는 컴퓨터로부터 요청을 받아 잘못 응답하게 됩니까?

답변1

제공한 예제 로그 메시지는 RST대상 포트에서 수신 대기 중인 항목이 없을 때 일반적으로 커널에서 보내는 패킷입니다.

Oct 10 05:18:47 ASUS user.warn kernel: IPTables-Dropped:
    IN=br0 OUT= MAC=3C:AE:78:D4:B1:E3 SRC=192.168.1.136 DST=192.168.1.122
    LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10743 DF PROTO=TCP SPT=443 DPT=33272
    WINDOW=0 RES=0x00 RST URGP=0

특히, 192.168.1.122에서 192.168.1.136:443까지의 이전 요청이 있었는데, 당시에 포트 443에서 수신 대기 중인 항목이 없었기 때문에 서버 192.168.1.136에서 거부되었습니다. (또는 192.168에 방화벽이 있습니다.) .1.136에는 REJECT해당 주소/포트 조합에 대한 규칙이 있습니다. 이 수준에서는 차이점을 알 수 없습니다. )

불행하게도 이는 .122의 라우터가 .136의 nginx와 통신을 시도해야 하는 이유를 설명하지는 않지만 로그 파일 메시지를 더 쉽게 해석하는 데 도움이 될 수 있습니다.

관련 정보