다음과 같은 네트워크 설정이 있습니다
[ISP Router] <---> [Raspbian] <---> [Debian 10 Workstation]
내 Raspbian "라우터"에 대한 정보는 다음과 같습니다.
iptables
새로 고쳐졌습니다 iptables -F
. 모든 체인의 기본 전략은 다음과 같습니다.ACCEPT
ip a
보고서에는 IP eth0
주소가 eth1
내가 기대하는 값으로 설정되어 있다고 나와 있습니다. ( eth0
즉 192.168.1.201
, ISP 라우터의 DHCP 서버에 예약된 주소로 설정합니다. eth1
정적 설정을 사용합니다 /etc/dhcpcd.conf
. 192.168.2.254
)
라우팅 테이블 정보는 다음과 같습니다.
default via 192.168.1.254 dev eth0 proto dhcp src 192.168.1.201 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.201 metric 202
192.168.2.0/24 dev eth1 proto dhcp scope link src 192.168.2.254 metric 203
눈에 띄게 잘못된 것은 없으며 iptables
명시적인 기본 정책을 사용하면 ACCEPT
라우팅 테이블의 모든 주소로 향하는 모든 패킷을 전달해야 한다고 생각합니다. cat /proc/sys/net/ipv4/ip_forward
반품 1
.
이것은 내 워크스테이션에서 보고한 정보입니다.
ip route
default via 127.0.0.1 dev enx00500b668976b proto dhcp metric 100
default via 127.0.0.1 dev enx00500b668976b proto dhcp metric 101
10.0.0.0/8 dev enp7s0 proto kernel scope link sec 10.0.0.1
127.0.0.1 dev enx00500b668976b proto dhcp scope link metric 100
192.168.2.0/24 dev enx00500b668976b proto kernel scope link src 192.168.2.10
이것은 나에게 조금 이상해 보입니다.
Rasbian 시스템에서는 ping을 할 수 있지만 192.168.1.254
내 워크스테이션에서는 이 주소를 ping할 수 없습니다. 이는 두 장치 간의 링크에 문제가 있음을 나타냅니다.
이 문제를 진단하려면 어떻게 해야 합니까?
위의 정보를 바탕으로 설정에 분명히 잘못된 점이 있습니까?
답변1
부분 답변 (아마도)
문제를 진단하는 방법에 대해 조사했습니다.
tcpdump
라즈베리파이에 설치해서 모니터링 해봤습니다 eth1
. "localhost를 소유한 사람"을 묻는 ARP 요청이 표시됩니다.
나는 /etc/dhcp/dhcpd.conf
그 줄을 편집하고 찾았습니다 option routers localhost;
. 나는 그것이 유효한 옵션이 아니라고 생각합니다 journalctl -xe
. (아니면 적어도 그렇지 않다고 생각합니다. 시작 시 오류를 발견하지 못했습니다.)
나는 이것을 로 변경했습니다 option routers 192.168.2.254
. 이것은 나에게 "잘못된 것 같습니다". Pi는 네트워크의 DHCP 서버이자 해당 네트워크의 라우터이기 때문에 나는 그것이 localhost
또는 ... 중 하나라고 생각했을 것입니다 .127.0.0.1
192.168.2.0
재부팅하고 iptables
다시 삭제하면 이제 라우터(Pi)를 통해 ping을 수행할 수 있습니다.
추가 정보
글쎄, 지금은 핑을 할 수 없지만 지금은 할 수 있어요...
내 워크스테이션에서는 이제 이것을 라우팅 테이블로 봅니다.
10.0.0.0/8 dev enp7s0 proto kernel scope link src 10.0.0.1
127.0.0.1 dev enx0050b668976b proto dhcp scope link metric 100
192.168.2.0/24 enx0050b668976b proto kernel scope link src 192.168.2.10 metric 100
이것은 내가 기대했던 것과 더 비슷해 보입니다.
다시 시작한 후에는
10.0.0.0/8 dev enp7s0 proto kernel scope link src 10.0.0.1
192.168.2.0/24 enx0050b668976b proto kernel scope link src 192.168.2.10 metric 100
지금은 작동하지만 왜 그런지 100% 확신할 수 없습니다. 플러시 클리어 NAT로 인해 발생한 iptables 문제일 가능성이 높습니다.
두 장치 모두 다시 시작되었습니다.
이것이 출력이다iptables --list -v
sudo iptables --list -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
185 21142 ACCEPT all -- lo any anywhere anywhere
124 11380 ACCEPT tcp -- eth1 any anywhere anywhere tcp dpt:ssh
107 16316 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
34 2936 DROP all -- eth0 any anywhere anywhere
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
라우팅 테이블:
default via 192.168.1.254 dev eth0 proto dhcp src 192.168.1.201 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.201 metric 202
192.168.2.0/24 dev eth1 proto dhcp scope link src 192.168.2.254 metric 203
워크스테이션 라우팅 테이블:
default via 192.168.2.254 dev enx0050b668976b proto dhcp metric 100
10.0.0.0/8 dev enp7s0 proto kernel scope link src 10.0.0.1
192.168.2.0/24 dev enx0050b668976b proto kernel scope link src 192.168.2.10 metric 100
default
그가 돌아온 것 같습니다 . 어딘가에서 잘못된 구성을 제외하고는 왜 이런 일이 발생하는지 잘 모르겠습니다.
이것은 `/etc/dhcp/dhcpd.conf에 있는 내 서브넷 정의입니다.
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.10 192.168.2.120;
option routers 192.168.2.254;
option broadcast-address 192.168.2.255;
}
192.168.2.254
다시 말하지만, 비슷한 것보다는 여기에 사용하는 것이 조금 이상 127.0.0.1
하지만 작동하는 것 같나요?