셸 스 크 립 트 UDP 포트 상태 탐지

UDP 포트 탐지 및 셸 리 셋
필요 배경
서비스의 UDP 포트 가 정상 인지 확인 해 야 합 니 다.
분석 하 다.
UDP 는 상태 가 없고 연결 이 없 는 프로 토 콜 이라는 지식 이 내 마음 에 새 겨 져 있 기 때문에 첫 번 째 반응 은 이 탐 사 를 할 수 없다 는 것 이다.서비스 가 상태 검사 의 rest 인 터 페 이 스 를 추가 하 는 등 다른 차원 에서 만 방법 을 강구 할 수 있다.rest 인터페이스의 상 태 를 검사 하여 대응 하 는 UDP 포트 의 상 태 를 판단 합 니 다.
TCP 뿐만 아니 라 UDP 포트 가 감청 되 지 않 았 을 때 운영 체제 도 ICMP 포트 에 도달 할 수 없 는 메 시 지 를 보 내 는 것 을 알 게 되 었 다.ICMP 는 UDP 의 일부 가 아니 기 때문에 UDP 와 연결 되 지 않 고 상태 없 는 프로 토 콜 이라는 주장 과 모순 되 지 않 는 다.그 전에는 정말 수박 겉 핥 기 였 다.
계획
총 두 단계:

ping 대응 IP 검 측 대응 IP 정상 여부.제약 조건: 대응 하 는 노드 는 ping 응답 을 닫 을 수 없습니다.방화벽 은 ICMP 요청 과 응답 메 시 지 를 걸 러 낼 수 없습니다

빈 내용 의 UDP 메 시 지 를 보 냅 니 다. 1) ICMP 포트 에 도달 할 수 없 는 답장 을 받 으 면.포트 가 닫 혔 다 고 생각 합 니 다.2) ICMP 포트 를 받 지 못 하면 메시지 에 도달 할 수 없습니다.두 가지 가능성 이 있다. I) 포트 가 정상이다.답 이 없다.제약 조건: UDP 포트 에 대응 하 는 프로그램 은 메시지 내용 이 비어 있 는 메 시 지 를 처리 할 수 있어 야 합 니 다.II) 방화벽 은 ICMP 포트 의 메시지 제약 을 걸 러 냈 다. 운영 체 제 는 ICMP 포트 를 걸 러 낼 수 없고 메시지 자체 가 같은 랜 에 있 으 며 메시지 전송 과정 에서 방화벽 을 거치 지 않 을 것 이다.

비고: 검 측 을 기다 리 는 노드 와 같은 랜 에 있 기 때문에 상기 제약 은 모두 실시 할 수 있 습 니 다.UDP 프로 토 콜 자체 가 신뢰 할 수 없 기 때문에 한 번 만 성공 하지 못 하면 성공 하지 못 했다 고 보 는 등 여러 차례 탐 사 를 고려 할 수 있다.
이루어지다
python
누군가가 python 기반 솔 루 션 을 제공 했다.

패키지 프로그램 을 시작 합 니 다.

발송 내용 은 빈 UDP 메시지 다.

일정 기간 대응 하 는 ICMP 포트 를 잡 았 는 지 여 부 를 판단 하 는 것 은 메시지 에 도달 할 수 없다.이 방안 은 가방 을 잡 는 방식 으로 이 루어 져 우아 하지 못 한 것 이 분명 하 다.직관 적 으로 나 에 게 더 우아 한 해결 방안 이 있어 야 한 다 는 것 을 알려 주 었 다.더 중요 한 것 은 배 송 된 버 전 차원 에서 python 2 와 python 3 의 전환 과 관련 되 기 때문에 프로젝트 에서 python 스 크 립 트 를 사용 한 후에 해당 하 는 안전 스 캔 과 같은 작업 을 추가 해 야 합 니 다.전체적으로 python 스 크 립 트 를 사용 하면 버 전 차원 의 작업량 이 증가 합 니 다.

java
얼마 전에 이 글 을 읽 을 때 이런 말 을 보 았 습 니 다.
이 ICMP 오류 메 시 지 는 telnet 에서 발생 하 는 TCP 흐름 에 속 하지 않 지만 이 TCP 흐름 과 는 RELATED 의 것 이 고, RELATED 의 흐름 은 원시 흐름 의 conntrack 구조 체 계 를 계승 하 는 것 이 문제 의 근본 이 며, 이 세부 사항 이 없 으 면 잘못된 판단 을 가 져 올 수 있다.
현재 발생 한 문제 와 결합 하여 tcp 의 socket 연결 을 사용 할 때 받 은 connection refused 정 보 는 운영 체제 가 ICMP 포트 를 받 아 메 시 지 를 받 지 못 하기 때 문 이 라 고 생각 합 니 다.그래서 이 TCP 스 트림 에서 보 낸 ICMP 메 시 지 는 운영 체제 에 의 해 같은 socket 으로 보 내 졌 다.
우리 가 UDP 를 사용 할 때 도 socket 으로 연결 되 어 있 습 니 다. 그러면 UDP 도 같은 상황 이 아 닙 니까?한 번 찾 아 보 았 는데, 과연 그 랬 다.다만 UDP 는 조금 특별 합 니 다.

bind () 함수

를 명확 하 게 호출 해 야 합 니 다.

메 시 지 를 보 낼 때 오류 가 발생 하지 않 고 메 시 지 를 받 을 때 PortUnreachableException

으로 돌아 갑 니 다.
이 방안 은 분명히 python 스 크 립 트 패키지 보다 우아 하 다.하지만:

IP 가 ping 통 하 는 지 먼저 확인 해 야 합 니 다. 자바 코드 는 분명 불편 합 니 다.

기다 리 는 데 시간 초과 설정 이 필요 할 수 있 으 므 로 새로 스 레 드 를 열 어 처리 해 야 할 수도 있 습 니 다.

자바 코드 가 발생 한 결 과 는 최종 적 으로 keepalived 에 전달 되 어야 하기 때문에 비교적 번거롭다.

셸 스 크 립 트
자바 의 socket 이 이 문 제 를 해결 할 수 있다 면 셸 스 크 립 트 의 socket 은 이 문 제 를 해결 할 수 있 습 니까?만약 해결 할 수 있다 면 셸 스 크 립 트 는 비교적 우아 한 해결 방안 이 될 것 이다.
셸 은 TCP/UDP 연결 을 만 드 는 방법 을 제공 합 니 다:/dev/udp/host/port/dev/tcp/host/port
따라서 현재 셸 의 파일 설명 자 를 해당 하 는 ip/포트 로 직접 바 꿉 니 다. exec 8<>/dev/udp/10.0.2.15/12345 는 UDP socket 을 만 드 는 것 과 같 습 니 다.메시지 보 내기: echo "" >&8 패키지 결과:

00:48:18.291124 IP 10.0.2.15.40371 > 10.0.2.15.12345: UDP, length 1
00:48:18.291145 IP 10.0.2.15 > 10.0.2.15: ICMP 10.0.2.15 udp port 12345 unreachable, length 37

UDP 의 연결 성 이 없 기 때문에 명령 이 되 돌아 오 는 결 과 는 여전히 성공 적 이다.
대응 하 는 파일 설명자 에서 상태 읽 기:

root@debian2:~# cat 

물론 스 트림 에 데 이 터 를 직접 다시 쓰 는 것 도 같은 오 류 를 얻 을 수 있 습 니 다.

root@debian2:~# exec 8<>/dev/udp/10.0.2.15/12345
root@debian2:~# echo "" >&8
root@debian2:~# echo "" >&8
-bash: echo: write error: Connection refused

사용 완료 후 대응 하 는 흐름 닫 기: exec 8>&-참고: bash shell 연결 소켓 Bash One - Liners 설명, 파 트 III: 리 다 이 렉 션 에 관 한 모든 것