VPN은 UART Wi-Fi 모듈 안이 아니라 뒤에 두십시오

UART Wi-Fi 모듈에는 TCP 소켓이 필요하고, 터널은 게이트웨이가 소유합니다. 그 주소를 지목하고, 반환 경로를 열어 두고, 암호화가 어디서 시작하는지 알아 두십시오.

UART Wi-Fi 모듈이 달린 마이크로컨트롤러가 그 뒤의 서비스에 도달하려고 VPN을 구현할 필요는 없습니다. 모듈은 이미 TCP/IP 스택을 돌리고 시리얼 포트로 소켓을 노출하며, 같은 LAN의 게이트웨이가 그 트래픽을 터널로 통과시킬 수 있습니다. 설계가 성립하는 것은 주소, 소켓, 경로, 경계라는 네 질문에 순서대로 답할 수 있을 때뿐이므로 체크리스트로 다루십시오. 처음 실패하는 관문에서 멈추십시오, 이후 관문이 그것을 보상할 수 없기 때문입니다.

각 계층에 하나의 역할을 부여하십시오

UART 링크는 마이크로컨트롤러와 모듈 사이에서 AT 명령과 페이로드를 나릅니다. 모듈은 Wi-Fi 네트워크에 가입하고 소스 주소를 포함한 IP 연결을 소유합니다. 게이트웨이는 터널과 자격 증명과 전달 정책을 소유합니다. 이 역할들을 분리해 두는 것이 각 단계에서 설계를 디버그 가능하게 만듭니다.

이 분리는 게이트웨이 정책을 쓰는 방식도 바꿉니다. 소스 규칙은 모듈의 LAN 주소를 지목해야 하며, 시리얼 링크 뒤에 있는 마이크로컨트롤러를 위한 상상의 주소가 아닙니다. 이 설계에서 마이크로컨트롤러는 자체 IP 정체성을 갖지 않습니다, 있는 척하면 절대 일치하지 않는 규칙이 생깁니다.

네트워크가 지원하는 어떤 예약 방식으로든 모듈에 고정 주소를 주거나, 장치를 자체 세그먼트에 두고 게이트웨이가 인터페이스로 일치시키게 하십시오. 재부팅 후 바뀌는 풀 주소는 작성할 때 옳았던 정책을 언젠가 깨뜨립니다.

게이트웨이가 모듈의 주소를 지목할 수 있는가?

어떤 소켓이 열리기 전에 모듈이 연결되어 있고 주소가 있으며 게이트웨이가 예상 인터페이스에서 그것을 보는지 확인하십시오. 가장 자주 조용히 실패하는 관문인데, 모듈은 LAN을 떠난 적 없는 연결 시도를 기꺼이 보고하기 때문입니다.

AT+CWMODE=1
AT+CWJAP="lab-wifi","passphrase"
AT+CIPSTA?
AT+CIPMUX=0

단일 연결 모드는 명령 순서를 단순하게 유지하며 하나의 서비스와 이야기하는 하나의 센서에 맞는 출발점입니다. 다중 연결 모드는 이후 모든 명령의 구문을 바꾸므로, 다른 펌웨어 버전에서 예제를 복사하기 전에 어느 모드에 있는지 정하십시오.

모듈에서 소켓을 여십시오

주소와 모드가 정해지면 모듈은 사설 서비스로 TCP 연결을 열 수 있습니다. 아래 주소는 문서용 대역의 예시이므로, 자기 것으로 바꾸고 같은 형태를 유지하십시오.

AT+CIPSTART="TCP","10.90.0.20",9000
AT+CIPSEND=18
{"t":21.4,"rh":48}

그 AT 명령은 평범한 TCP 소켓을 열 뿐이고, 소켓은 터널이 아닙니다, 그 안에서 VPN이 만들어지지도 페이로드가 암호화되지도 않습니다. 펌웨어의 TLS 모드는 자체 명령과 자체 인증서 처리를 가진 별도 기능이며, 임의의 UART 모듈은 둘 다 지원하지 않을 수 있습니다. 위 구문이 그 모듈에 적용된다고 가정하지 말고 펌웨어의 TCP/IP AT 명령 참조를 확인하십시오.

AT+CIPSEND의 페이로드 길이는 실제로 보내는 양과 일치해야 합니다, 그렇지 않으면 모듈은 영영 오지 않는 바이트를 기다리고 연결이 멈춘 것처럼 보입니다. 그 실패는 네트워크 문제처럼 보이지만 거의 항상 길이의 일 오차입니다.

연결을 게이트웨이를 통해 라우팅하십시오

게이트웨이에는 사설 목적지로 가는 경로, 장치 네트워크에서 터널로 전달할 권한, 모듈에 도달하는 반환 경로가 필요합니다. 원격 측이 장치 서브넷으로 되돌아 라우팅하지 않으면 설계에는 의도적인 변환 규칙이 필요하고, 그 규칙은 서비스가 보는 소스 정체성을 바꿉니다.

ip route get 10.90.0.20
sudo tcpdump -ni wg0 'host 10.90.0.20 and port 9000'
sudo conntrack -L | grep 9000

먼저 반환 경로를 지켜보십시오. 서비스에 도달하고 영영 돌아오지 않는 전달된 패킷은 게이트웨이에 아무 오류도 없이 모듈에서 시간 초과를 만들고, 사람들은 몇 시간 동안 Wi-Fi 링크를 들여다보게 됩니다. conntrack 항목은 게이트웨이가 응답을 보았는지 알려 줍니다.

터널이 실제로 어디서 끝나는지 정하십시오

터널은 게이트웨이에서 시작합니다. 그것은 UART 링크를 암호화하지 않으며, 모듈과 게이트웨이 사이의 LAN 세그먼트를 터널의 일부로 만들지도 않습니다. 그 세그먼트에서 보호가 필요한 것은 무엇이든 자체 수단이 필요하고, 이 예시의 평범한 TCP는 TLS가 아닙니다.

터널이 끊길 때 무슨 일이 일어나는지도 정하십시오. 전달이 VPN으로만 이루어져야 한다면, 전달 정책은 같은 목적지를 대체 경로로 허용해서는 안 됩니다, 대체 경로가 요구 사항을 조용히 무너뜨리기 때문입니다. 재연결 동작을 제한해, 연결이 끊긴 모듈이 시리얼 링크나 원격 서비스를 재시도로 넘치게 하지 마십시오.

네 가지 답을 함께 기록하십시오, 모듈의 주소, 소켓의 대상, 게이트웨이의 경로, 그리고 암호화가 시작되는 지점입니다. 다음에 이 장치를 디버그할 사람은 네 가지 모두 필요하며, 어느 것도 펌웨어만으로 추론할 수 없습니다.

관련 글