[00:28] 아고 피곤하네요~ ㅜㅜ [00:32] 라우팅 테이블이라는게 dhcp 서버의 라우팅 테이블을 말씀하시는거겠지요? 라우팅 테이블이 없으면 디폴트 라우팅 타고 위로 올라갈텐데 [00:32] 그쪽 라우팅이 잘못되어 있거나 ( 혹은 빠져 있거나 ) , 보안장비가 차단하고 있을 수 도 있을 거 같습니다. [00:33] 안녕하세요 [00:33] 렉스님 안녕하세요~ [00:33] 조만간에 제주도 가신다구요? ㅎㅎ [00:33] 오즈님 좋은 아침이에요.^^ [00:33] 아. 넵. 9/19~9/21에 다녀올 예정입니다 [00:38] 겸사겸사 좋은곳 구경도 좀 하고 오셔요~ ㅎㅎ [00:45] autowiz: 음... 그러니까 예를 들자면, 제 컴퓨터는 172.17.5.54이고 DHCP서버는 172.17.5.2이고, 이 DHCP 서버의 매니지먼트용 IP는 172.16.1.16이라고 가정했을 때, 172.17.5.54 => 172.16.1.16으로 핑을 쏘면 응답이 없어요. 근데 반대로는 잘 되구요, DHCP 서버가 아닌 다른 서버 예를 들면 172.16.1.15등은 아무 이상 없이 잘 되구요 [00:52] dhcp 서버가 무조건 꼭 같은 대역에 있을 필요는 없을껍니다. 스위치가 dhcp 중계역활을 해준다는 전제 하에서요 . [00:52] 아무튼 위의 경우 dhcp 쪽에 IP 가 두개가 들어가는데 (랜카드가 하나건 두개건 ) , 172.17.5.54 에서 보낸 icmp 패킷이 172.16.1.16 에 도착한다음 , [00:52] 172.17.5.2 -> 172.17.5.54 로 icmp 응답을 해버릴거 같거든요 [00:57] #1. 172.16.1.16 에서 172.17.5.54 에서 보낸 icmp 패킷이 잘 들어오는지 확인해봐야 할거 같구요. [00:57] #2. DHCP 서버가 172.17.5.x 대역의 패킷이 172.16.1.16 으로 들어오는걸 차단하는지 확인해봐야 할거 같습니다. [00:57] (/proc/sys/net/ipv4/conf/all/arp_ignore arp_check 확인 ) [00:57] #3. arp tables 이랑 arping 으로 패킷이 지나갈 경로 예측해복 실제로 덤프도 떠봐야 정확해질거 같습니다 ㅎㅎ [00:59] rp_filter 라는것도 있는데 이건 들어오는 패킷의 source IP 가 라우팅 테이블에 등록되어 있지 않을경우 버리는거라고 합니다. [01:06] 강제로 패킷 복사해서(IP DNAT , MAC DNAT 까지 걸고 ) 특정 인터페이스로 보냈는데 tcpdump 에서는 패킷이 보이는데 데몬은 패킷을 못받고 있어서 나중에 보니 rp_filter 때문이었던 적이 있습니다. [02:11] 오즈님 장문의 조언 감사합니다 ㅎㅎ [02:25] 아닙니다 괜히 장황하게 설명한거 같습니다 ㅎㅎ 그냥 tcpdump 양쪽에서 걸어놓고 보면 금방 보일거 같습니다ㅋ [02:26] dhcp 띄우기 전까지는 괜찮았어요 [02:26] 이상하게 dhcp 서버로만 접속이 안되더라구요 [02:27] dhcp 돌리는 서버 쪽에서, 클라이언트 네트워크를 따로 라우팅 테이블에 추가해야 클라이언트가 dhcp 서버로 핑 응답을 받아요 [03:31] https://www.zdnet.com/article/free-software-advocate-richard-stallman-spoke-at-microsoft-research-this-week/ [03:31] ㅋㅋㅋㅋㅋㅋㅋ [03:32] MS가 스톨만을 초대하다니!! ㅋㅋㅋ [04:08] 최근 MS의 행보를 보면... 그렇게 놀라운 일은 아니네요 ㅎㅎ WOL도 그렇고.. Azure도 그렇고 친 OSS 프로젝트들을 많이 진행 중이라. ㅎㅎ [04:13] MS 기사보다 드라코님을 너무 오랜만에 뵈서 좋으네요~ ㅎㅎ [04:59] 태풍이 제정신을.ㅎ [05:00] @autowiz 님 ㅎㅎㅎ 안녕하세요 [05:01] 넵 안녕하세요~ ㅎㅎ [05:01] 이번 태풍 엄청 강한가 보던데 걱정이네요 ㅜㅜ