시나리오를 소개하겠습니다.
AP#1 <------> (Linux #1) <------> 중간 네트워크 <------> (Linux #2) <------> 무선 클라이언트
요약하자면, 무선 클라이언트에서 실행되는 애플리케이션이 액세스 포인트 #1과 투명하게 통신할 수 있어야 합니다(AP#1).
위에서 볼 수 있듯이 이름이 지정된 장치가 있습니다.AP#1, 이는 특정 애플리케이션에 대한 핫스팟을 생성합니다. 이 애플리케이션은 다음과 연결하여 사용할 수 있습니다.AP#1, 무선 클라이언트가 원격으로 사용하기를 원합니다. 구성을 건드릴 수 없기 때문에AP#1하지만 구성할 수는 있습니다.리눅스 #1그리고리눅스 #2, 다음을 시도했습니다.
- 리눅스 #1연관되다AP#1WPA 신청자를 사용하여 동일한 서브넷에 남아 있습니다.
- 리눅스 #2다른 서브넷에 무선 클라이언트에 대한 액세스 포인트를 생성합니다.
- 무선 클라이언트는 AP#1의 고정 IP와 통신하고 트래픽은 다음 위치에서 라우팅 및 NAT됩니다.리눅스 #1, 그래야 다음과의 통신이 가능합니다.AP#1투명하다.
지금까지는 무선 클라이언트가 AP#1의 주소를 ping할 수 있었습니다. 그러나 무선 클라이언트는 UDP 패킷을 255.255.255.255로 전송하여 통신을 시작합니다.AP#1응용 프로그램이 실제로 작동하기 시작하기 전에 응답합니다. 이러한 요청을 앞뒤로 라우팅할 수 있는 방법이 있습니까? 아니면 255.255.255.255는 일반적으로 라우팅할 수 없습니까?
이 구성을 gretap 터널로 변경하려고 생각했는데 이 토폴로지는 제가 구성할 수 없기 때문에 제가 본 예시와 조금 다릅니다.AP#1.
내 질문은 다음과 같습니다.
- 일종의 L2 터널을 구축하면 이 문제가 해결될 수 있다고 생각하시나요?
- 그렇다면 최선의 선택은 무엇입니까?
- 그렇다면 Linux #1에서 NAT를 제거하고 AP#1과 무선 클라이언트 간의 연결을 완전히 투명하게 만드는 것이 가능합니까?
미리 감사드리며 멍청한 질문에 대해 사과드립니다.
답변1
일종의 L2 터널을 구축하면 이 문제가 해결될 수 있다고 생각하시나요?
예, 그리고 양쪽 끝에 브리지가 있습니다. 그러나 Linux에서는 Wi-Fi 클라이언트 인터페이스를 연결하는 것이 쉽지 않을 수 있습니다(아래 참조).
이러한 요청을 앞뒤로 라우팅할 수 있는 방법이 있습니까? 아니면 255.255.255.255는 일반적으로 라우팅할 수 없습니까?
브로드캐스트를 전달하는 것은 금지되지 않습니다. 예를 들어 Cisco IOS에는 해당 옵션이 있지만 라우터는 루프를 피하기 위해 기본적으로 이를 수행하지 않습니다.
모호한 iptables 규칙을 사용하면 가능할 수도 있지만 Linux가 기본적으로 이를 수행할 수 있는지 확신할 수 없습니다. bcrelay브로드캐스트를 한 방향으로 전달할 수 있는 사용자 공간 데몬을 사용하는 것이 더 쉬울 것입니다 .
그렇다면 Linux #1에서 NAT를 제거하고 AP#1과 무선 클라이언트 간의 연결을 완전히 투명하게 만드는 것이 가능합니까?
전체는 아니고. IP 수준에서 완전히 투명하게 만들 수 있지만 표준 Wi-Fi 클라이언트는 자체 MAC 주소가 있는 프레임만 보낼 수 있으므로 단순히 클라이언트 Wi-Fi 인터페이스를 브리지할 수는 없습니다.레이어 2 NAT"Linux#1" 장치에서 어떤 종류의 것입니다. ("Linux#2" 장치는 AP이므로~할 수 있다레이어 2에서는 완전히 투명해야 합니다.)
표준 Linux에서 구현하는 방법을 모르지만 스테이션 모드로 설정된 독점 펌웨어(Mikrotik RouterOS 및 Ubiquiti airOS 장치)에서 ARPNAT를 본 적이 있습니다. 나는 많은 소비자 "무선 브리지"도 이를 구현한다고 생각합니다.
(Linux는 완전히 브리징 가능한 "4addr" 모드에서의 연결을 지원하지만 AP가 이를 지원하지 않을 가능성이 높습니다.)