을(를) 실행 중인데 Ubuntu server 22.04로컬 컴퓨터에 특이한 포트 전달 문제가 있습니다. 이 기기에는 두 개의 이더넷 인터페이스가 있으며 연결된 enp1s0인터페이스에는 IP 주소가 있습니다 192.168.1.50. 전체 IP 구성은 다음과 같습니다.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:e0:4f:68:02:bb brd ff:ff:ff:ff:ff:ff
inet 192.168.1.50/24 metric 100 brd 192.168.1.255 scope global enp1s0
valid_lft forever preferred_lft forever
inet6 240f:74:de92::d1e/128 scope global dynamic noprefixroute
valid_lft 35597sec preferred_lft 35597sec
inet6 fd41:d8b6:99ba::d1e/128 scope global dynamic noprefixroute
valid_lft 35597sec preferred_lft 35597sec
inet6 fd41:d8b6:99ba:0:2e0:4fff:fe68:2bb/64 scope global mngtmpaddr noprefixroute
valid_lft forever preferred_lft forever
inet6 240f:74:de92:0:2e0:4fff:fe68:2bb/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 98462sec preferred_lft 98462sec
inet6 fe80::2e0:4fff:fe68:2bb/64 scope link
valid_lft forever preferred_lft forever
3: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 00:e0:4c:68:01:6e brd ff:ff:ff:ff:ff:ff
altname enp2s0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:55:86:e6:e5 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
내 라우터에 대한 포트 전달 규칙을 설정하여 들어오는 모든 TCP 또는 UDP 패킷 from wan to port 22211이forwarded to lan 192.168.1.50 port 22211
내 ufw구성에서는 이 포트의 라우팅을 허용했습니다.
$ sudo ufw status
[sudo] password for *
Status: active
To Action From
-- ------ ----
22211/tcp ALLOW Anywhere
22211/tcp (v6) ALLOW Anywhere (v6)
이제 이 포트에 대해 간단한 netcat 소켓( )을 시작하면 로컬 네트워크의 다른 컴퓨터를 통해 문제없이 nc -l -p 22211연결할 수 있습니다 . 다음은 다른 로컬 컴퓨터에서 텔넷으로 접속할 때의 로그 telnet입니다 . tcudump연결하고 편지를 보내고 aEnter 키를 누릅니다.
$ sudo tcpdump -pnvvi enp1s0 port 22211
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:01:48.350024 IP (tos 0x0, ttl 64, id 59572, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.196.38840 > 192.168.1.50.22211: Flags [S], cksum 0x527d (correct), seq 3440167578, win 32120, options [mss 1460,sackOK,TS val 3772353734 ecr 0,nop,wscale 7], length 0
21:01:48.350139 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.50.22211 > 192.168.1.196.38840: Flags [S.], cksum 0x3a60 (correct), seq 495600843, ack 3440167579, win 65160, options [mss 1460,sackOK,TS val 102903428 ecr 3772353734,nop,wscale 7], length 0
21:01:48.351892 IP (tos 0x0, ttl 64, id 59573, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.196.38840 > 192.168.1.50.22211: Flags [.], cksum 0x66b7 (correct), seq 1, ack 1, win 251, options [nop,nop,TS val 3772353737 ecr 102903428], length 0
21:01:50.698846 IP (tos 0x0, ttl 64, id 59574, offset 0, flags [DF], proto TCP (6), length 55)
192.168.1.196.38840 > 192.168.1.50.22211: Flags [P.], cksum 0xf275 (correct), seq 1:4, ack 1, win 251, options [nop,nop,TS val 3772356082 ecr 102903428], length 3
하지만 로컬 네트워크 외부에서 텔넷 형식을 시도하면 어떤 이유로 연결이 설정되지 않습니다. 오랫동안 나는 내 포트 전달 구성이 꺼져 있다고 확신했지만(동일한 라우터가 다른 포트를 내 로컬 네트워크의 다른 컴퓨터로 전달하는 것은 문제가 없었고 기본적으로 구성을 다른 포트에 미러링했지만) tcpdump로그 에서 볼 수 있듯이 아래에서는 패킷이 인터페이스에 도착합니다 enp1s0.
$ sudo tcpdump -pnvvi enp1s0 port 22211
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:58:05.448829 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x4448 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560510789 ecr 0,sackOK,eol], length 0
20:58:06.593532 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x405f (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560511790 ecr 0,sackOK,eol], length 0
20:58:07.613818 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x3c76 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560512791 ecr 0,sackOK,eol], length 0
20:58:08.603603 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x388c (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560513793 ecr 0,sackOK,eol], length 0
20:58:09.563590 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.36371 > 192.168.1.50.22211: Flags [S], cksum 0xcd21 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560514795 ecr 0,sackOK,eol], length 0
또한 netcat이 모든 인터페이스(0.0.0.0 부분)를 수신하고 있음을 알 수 있습니다.
$ sudo ss -tulpn | grep 22211
tcp LISTEN 0 1 0.0.0.0:22211 0.0.0.0:* users:(("nc",pid=3344,fd=3))
라우팅 테이블은 다음과 같습니다.
$ sudo route -vn
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 enp1s0
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp1s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp1s0
192.168.1.1 0.0.0.0 255.255.255.255 UH 100 0 0 enp1s0
그래서 외부 네트워크에서 들어오는 패킷이 포트 22211의 로컬 소켓에 도달하지 못하는 이유를 알 수 없습니다. 구성해야 할 추가 방화벽 구성이 있습니까?
편집: 흥미롭게도 실제로 ping 8.8.8.8시간이 초과되었습니다(예를 들어 ping google.com은 정상적으로 작동함).
답변1
TL;DR
복잡한 것이 작동하지 않으면 먼저 기본 사항이 올바르게 작동하는지 확인하십시오.
더 긴 버전
전문
이것은 질문하는 방법의 좋은 예입니다.
예를 들어 Ubuntu 22.04를 실행 중이고 시스템에 두 개의 이더넷 인터페이스가 있는 등의 배경 정보가 있습니다.
자세한 정보(예: IP 구성 정보)가 제공됩니다.
작동하는 예제와 작동하지 않는 예제가 모두 표시됩니다.
문제를 디버깅하는 중입니다.
오해를 바로잡으세요.
OP는 "그래서 외부 네트워크에서 들어오는 패킷이 포트 22211의 로컬 소켓에 도달하지 못하는 이유를 알 수 없습니다."라고 말했습니다. 데이터에 패킷이 도착하고 있음이 표시되면 해당 인터페이스에서 나가지 않는 응답이었습니다.
OP는 두 개의 인터페이스가 있다고 말했습니다. IP 정보에는 두 번째 인터페이스가 다운된 것으로 표시되지만 시스템이 다른 인터페이스에서 응답을 보낼 것으로 예상하고 있었던 것일까요?
자세한 내용을 먼저 요청하세요.
"라우팅 테이블에 126.33.189.168에 대한 경로가 작동 중인 인터페이스(enp1s0)를 통한 것으로 표시됩니까?" OP는 라우팅 테이블을 추가하여 응답했으며 다음과 같이 말했습니다.
"원본 메시지에 라우팅 테이블 정보를 추가했습니다. 또한 다른 인터페이스 eno1이 다운되었는지 확인했지만 아무런 변화가 없는 것 같습니다."
추가 정보에 대한 두 번째 요청입니다.
라우팅 테이블에는 숫자 주소가 아닌 기호 이름이 포함되어 있습니다. 매핑을 모르면 별로 유용하지 않았으므로
sudo route -vn" 숫자 값을 표시 하도록 출력을 표시하도록 편집 내용을 변경할 수 있습니까 ?"
응답자에게 자연스러운 방식으로 질문하십시오.
ip route대신 사용을 제안하는 의견 입니다 route -vn. 나는 수년 동안 사용해 왔으며 ip route이것이 더 나은 도구라고 주장합니다. 물어봐야 할 질문은 "우리가 OP에게 더 나은 도구를 가르치려고 노력하고 있습니까, 아니면 그가 문제를 해결하도록 돕기 위해 노력하고 있습니까?"입니다. 새로운 도구를 도입하는 것이 방해가 될 것이라고 생각합니다.
추가 정보에 대한 두 번째 요청 – 계속됩니다.
"192.168.1.50에서 잘 알려진 주소(예: 8.8.8.8)를 ping할 수 있는지 확인해 주시겠습니까?" 이는 반응을 이끌어냈다.
'당신 말이 맞아요. 어떤 이유로 핑이 8.8.8.8번이나 나갔나요? 하지만 ping google.com은 잘 작동합니다."
ping google.com작동하는 이유 디버그
- "그리고 ping google.com은 어떤 IP 주소를 선택합니까? (첫 번째 줄에 표시되어 있습니다.) 이는 IPv4에서 방화벽을 설정했지만 여전히 IPv6가 완벽하게 작동하는 것처럼 들립니다. "
나는 용어를 사용하지 않을 것입니다 firewalled. 서로 다른 메트릭을 가진 2개의 기본 경로를 표시하는 라우팅 테이블을 사용하면 이는 이제 거의 확실히 라우팅 문제였습니다.
세 번째 추가 정보 요청입니다.
대부분의 사람들은 인터넷에 단 한 번만 연결되어 있지만 부당한 가정을 하지 않으려고 노력합니다.
- "각각 인터넷에 연결할 수 있는 2개의 라우터가 있을 것으로 예상하십니까(아마도 2개의 서로 다른 ISP를 통해)?"
대답이 부정적으로 돌아왔을 때 OP에게 라우팅 문제를 해결하라고 지시하는 것(더 익숙한 명령을 사용하여)만 하면 모든 것이 작동합니다. 답변을 예상하고 질문에 지침을 추가하면 지연이 줄어듭니다.
- "8.8.8.8을 ping할 수 있는 것이 가장 중요한 문제입니다. 이를 해결하면 모든 것이 해결될 수도 있습니다."
실제 문제.
패킷이 로컬 네트워크가 아닌 인터넷으로 나가야 할 때 존재하지 않는 기계를 통해 보내라는 지시를 받았습니다.
존재하지 않는 이 컴퓨터에 패킷을 보내기 위해 호스트는 응답을 받지 못하는 ARP 패킷을 보냈습니다.
결국 호스트는 존재하지 않는 시스템에 대한 연결 시도를 포기하고 ping 명령에 오류를 보고했거나 들어오는 연결에 대한 승인을 보내지 않았습니다.
올바른 주소를 통해 인터넷으로 향하는 패킷을 보내도록 라우팅 테이블을 수정하면 모든 것이 작동하게 되었습니다.