건물에는 11개의 openwrt 기반 액세스 포인트가 있습니다. 때로는 사용자 지정 비밀번호를 사용하여 가상 네트워크를 추가해야 할 때도 있습니다. 저는 매개변수를 변경하기 위해 액세스포인트를 반복하는 것을 좋아하지 않습니다. 이것은 어렵고 실수를 낳습니다.
모든 구성을 유지하고 업데이트하는 전용 서버(가상 머신)를 갖고 싶습니다. 이에 대한 해결책이 있습니까?
각 액세스 포인트에 대한 구성을 생성한 다음 이를 모든 장치에 scp하는 스크립트를 생성할 수 있다는 것을 알고 있지만 처음부터 작업을 수행하기 전에 여기에서 질문하겠습니다. 나는 바퀴를 재발명할 계획이 없습니다(바퀴가 실제로 발명되지 않은 한). 동시 구성은 액세스 포인트가 있는 일반적인 네트워크에서 매우 일반적인 문제라고 생각합니다.
업데이트: 이것은 비밀번호 문제일 뿐만 아니라 Radius 서버를 사용하여 해결될 수 있지만 Radius는 다음과 같은 다른 문제를 해결할 수 없습니다.
- 새로운 essid 생성
- VLAN에 essid 할당
- essid 브로드캐스팅 활성화/비활성화
- 등등, 등등, 등등.
답변1
질문하셨습니다: "원격 서버의 OpenWrt 구성: 이에 대한 솔루션이 있습니까?"
저는 매일 80개가 넘는 OpenWRT 상자(백파이어(일부), 태도 조정(대부분) 및 배리어 브레이크(일부)를 혼합하여 실행하는 세 가지 하드웨어 플랫폼)를 다루고 있습니다. 작년에 검색을 시작했습니다.깊이OpenWRT에 적합한 "구성 관리" 플랫폼에 대해 설명합니다.
내 결과는 다음과 같습니다.
오픈WISP: 제 생각에는 매우 유망한 것 같습니다. 그들은 "사용자 정의" 펌웨어(일부 bash 스크립트가 추가된 "기본" 펌웨어와 이미 설치된 패키지의 사용자 정의 목록에 지나지 않음)를 구축했습니다. 이 펌웨어는 일단 플래시되면 (OpenVPN 클라이언트를 통해) 중앙에 간단히 "연결"됩니다. 서버에 설치하고 구성을 다운로드하여 로컬로 적용하세요. 새로운 AP를 쉽게 "배치"할 수 있는 멋진 웹 인터페이스도 있습니다. 불행히도 완벽하지는 않습니다. 예를 들어 "템플릿"(구성)을 정의하고 적용할 수 있지만.... 나중에 템플릿의 변경 사항은아니다하위 AP로 푸시됩니다. 또한 전체 관리 소프트웨어 스택은 Ruby(및 Rails)로 작성되었으며... 해당 언어/플랫폼을 "마스터"하지 않으면 문제가 될 수 있습니다. 테스트했을 때 Backfire를 기반으로 했습니다. 이제 내 말이 맞다면 업데이트된 릴리스에서도 사용할 수 있습니다(Attitude 또는 Barrier는 기억나지 않습니다). 또한 웹사이트는 확실히 많이 업데이트되지 않았으므로... 자세한 내용은 GitHub 저장소를 참조하세요. 간단히 말해서, 한 번 볼만한 가치가 있습니다.
SF: 브라질 대학에서 개발한 플랫폼(내가 이해하는 한...문서브라질 사람인 것 같네요) 흥미롭네요. 약간 오래되었지만(2년 정도), 다시 한 번 흥미로워 보입니다. 관리 플랫폼은 PostgreSQL을 백엔드로 사용하는 JavaEE(JBoss)입니다. 내 말이 맞다면 기본 펌웨어 위에 채택될 수 있어야 합니다.
에어키: 그들은 다음과 같이 자신을 선언합니다: "AirKey는 OpenWRT 기반 액세스 포인트를 위한 중앙 관리 플랫폼입니다.". 많이 업데이트되지 않았기 때문에 많이 조사하지 않았습니다. (마지막 업데이트, 4년 전!)
캐리어WRT, 또한 중앙 관리와 엄격하게 관련되지 않더라도 어느 정도 관심을 가질 수 있습니다. 제가 기억하는 한 여기서 가장 놀라운 점 중 하나는 지원되는 하드웨어가 제한적이라는 점입니다(하지만 직접 확인해 보세요).
당신이 말했듯이 : "나는 바퀴를 재발명할 계획이 없습니다(바퀴가 실제로 발명되지 않은 경우는 제외).", 스스로 무언가를 만들고 싶은 유혹을 느낄 수도 있습니다. 그러한 경우 다음 사항을 고려하십시오.
- OpenWRT는 다음을 지원합니다.JSON-RPC APIJSON 및 REST를 사용하여 UCI와 쉽게 상호 작용할 수 있습니다. 그러한 기술을 마스터한다면 이는 흥미로울 수 있습니다. (가벼운) 뭔가를 시도했지만... BackFire 이후에 뭔가 변경된 것 같습니다. 그리고 --제가 맞다면-- BackFire에서 작동했던 것이 AA 및 BB에서는 작동하지 않을 것입니다(다시 확인하세요). ).
이 모든 일이 끝난 후, 저는... 이제 "공식적인" 구성 관리 플랫폼으로 전환해야 할 때라고 결정했습니다. OpenWRT 플랫폼의 기본 제약에 대해 제가 선택하는 것은 다음과 같습니다.앤서블SSH 위에서 실행될 수 있고 다른 심각한 종속성이 없기 때문입니다. 그러한 시나리오를 위해 이미 구축된 것이 있습니다(확인여기그리고여기) 하지만 아직 테스트를 해봐야 합니다.
그래서 저는 @Michael Hampton의 의견에 동의합니다."Ansible은 이에 대해 매우 이상적입니다." 그리고 제 생각에는 단일 OpenWRT 상자를 "공통" 구성 관리 엔진으로 관리할 수 있는 공통 Linux 시스템으로 간주할 수 있기 때문에 가장 먼저 평가해야 합니다.
답변2
OpenWISP에 대해 이제 Ruby에 의존하지 않는 새로운 관리자 소프트웨어가 있으며 설치는 매우 간단합니다.OpenWISP 2 컨트롤러
기존 django 프로젝트에 통합할 수도 있습니다.메인 모듈을 확장하여: django-netjsonconfig.
또한 라우터용 새 openwisp 펌웨어를 컴파일할 필요가 없으며 현재 openwrt 설치가 관리자에 의해 프로비저닝되도록 구성 구성 요소만 설치하면 됩니다.openwisp-config.
예를 들어 다음 명령을 실행하여 해당 구성요소를 설치할 수 있습니다.
opkg install http://downloads.openwisp.org/openwisp-config/latest/ar71xx/openwisp-config-nossl_0.4.1a-1_ar71xx.ipk
문안 인사!
카시오
답변3
이것은 귀하의 질문에 대한 정확한 답변은 아니지만 각 AP의 구성을 업데이트하는 대신 RADIUS를 인증 메커니즘으로 고려할 수 있습니다. AFAIU 유연한 사용자/비밀번호 구성이 필요합니다.