OPNsense 뒤의 OpenVPN 클라이언트 고정 주소

이름에는 움직이지 않는 주소가 필요하며, OpenVPN의 pool 파일은 주소를 끈적하게 만들 뿐이다. 그 파일을 잃거나 다른 공통 이름으로 인증서를 다시 발급하면, 돌아온 클라이언트는 pool의 다른 곳에 떨어지고 그 DNS 레코드는 여전히 옛 주소를 가리킨다. 지속적인 답은 주소를 고정하는 클라이언트별 override와, 고정된 주소가 동적 범위 밖에 있도록 더 넓힌 터널 네트워크다. 그 확장 뒤의 계산이 바로 혼란의 대부분이 사는 곳이다.

OPNsense는 이 override를 서버의 클라이언트별 설정에 보관하며 인증서 공통 이름을 키로 쓰므로, 공통 이름이 주소 계획의 일부가 된다.

끈적한 임대는 고정 주소가 아니다

pool 파일은 주소-클라이언트 매핑을 기록하고 알려진 클라이언트가 다시 연결하면 그것을 돌려준다. 이것은 계약이 아니라 편의이며, 파일은 다시 생성될 수 있고, 클라이언트 신원이 바뀌면 매핑이 사라지며, 같은 pool을 공유하는 두 서버는 그것에 합의하지 않는다. 클라이언트별 override는 주소가 이력이 아니라 구성에서 오기 때문에 다르게 동작한다. override가 나머지 구성과 함께 백업되어 있다면 어플라이언스의 재시작과 재설치도 견딘다.

동적 대안, 즉 client-connect 스크립트와 동적 업데이트로 VPN을 DNS에 연결하는 방식은 동작하며, 업데이트를 받아들이는 리졸버와 연결할 때마다 실행되는 스크립트가 필요하다. 어플라이언스에서는 벤더가 제공하는 패키지로 제한되므로 보통 그 지점에서 그 계획은 멈춘다.

아무도 즐기지 않는 /30 계산

기본 net30 토폴로지에서 각 클라이언트는 자기 /30을 받는데, 첫 번째 사용 가능한 주소는 서버 쪽으로, 두 번째는 클라이언트로 간다. 따라서 override는 서버의 동적 터널 네트워크 밖에 있어야 하며, 그것은 먼저 그 네트워크를 넓히는 것을 뜻한다. 10.8.0.0/24의 서버는 10.8.0.0/23으로 옮길 수 있고, 옛 범위의 절반은 동적 클라이언트에 나머지 절반은 override에 남긴다. 원래 /24를 추가 IPv4 로컬 네트워크로 넣어 두 절반으로 가는 트래픽이 터널로 라우팅되게 한다.

각 override 주소는 /30 경계에 떨어져야 하므로 마지막 옥텟은 넷의 배수다. 10.8.1.0의 /30은 클라이언트에 10.8.1.2를 주며, DNS 레코드가 담는 주소가 바로 그것이다. 대신 10.8.1.3을 고르면 그 주소가 토폴로지가 한 번도 할당하지 않은 서브넷에 속하기 때문에 연결은 되지만 트래픽을 통과시키지 못하는 클라이언트가 생긴다.

override를 넓힌 범위의 위쪽에서 아래로 할당하면 동적 pool이 고정된 섬 주변이 아니라 빈 공간으로 퍼지므로 계획을 지키기 쉽다.

로컬 네트워크와 클라이언트가 질의하는 영역

클라이언트 간 트래픽에는 자체 권한이 필요하다. 서버의 IPv4 로컬 네트워크 목록에는 범위의 양쪽 절반, 즉 동적과 고정이 모두 들어가야 하며, 이것이 없으면 서버는 한 클라이언트의 패킷을 받아들이고도 다른 클라이언트로 통과시키는 정책을 갖지 않는다. 이름은 확인되는데 연결은 여전히 실패하기 때문에 증상은 DNS 장애처럼 보인다. 로컬 네트워크 항목만으로는 피어 간 전달이 활성화되지 않으므로 동시에 클라이언트 간 설정도 확인한다.

레코드는 원격 클라이언트가 실제로 질의하는 영역에 게시한다. LAN 리졸버만이 제공하는 영역의 레코드는 푸시된 리졸버가 다른 곳을 가리키는 클라이언트에게 보이지 않으며, 잘못된 영역에 레코드를 더 넣는다고 해서 그것이 고쳐지지 않는다. 무엇이든 추가하기 전에 푸시된 DNS 옵션과 검색 도메인을 확인한다.

새 연결에서 확인할 것

클라이언트를 다시 연결하고 다른 것을 시험하기 전에 할당된 주소가 그 override와 일치하는지 확인한다. 그다음 두 번째 클라이언트에서 이름을 확인하고 이름으로 서비스에 연결하면 DNS 레코드, 경로, 방화벽을 함께 시험하게 된다. 이름이 확인되어도 서비스에 닿지 않는다면 그것은 이름 짓기가 아니라 라우팅이나 정책 문제이므로 서버 쪽에서 응답 경로를 확인한다. override 표를 인증서 목록 옆에 두어 둘을 함께 검토한다.

다른 공통 이름으로 다시 발급된 인증서는 그 override와 일치하지 않게 되어 클라이언트를 동적 pool로 되돌린다. 어떤 신원 변경 뒤에도 그것을 예상해야 한다.