OpenVPN 허브 하나와 LAN 세 개: 주소 계획과 iroute 파일

세 개의 사설 LAN이 어느 사이트도 다른 사이트의 내부를 알 필요 없이 하나의 허브에서 만날 수 있으며, 설계 전체는 네 가지 짧은 구성 결정에 달려 있다. 이것을 작동하게 하는 것은 특이한 프로토콜 기능이 아니라 누구도 추측할 필요가 없는 주소 계획과, 어느 지사가 어느 프리픽스를 소유하는지 허브에 알려 주는 클라이언트별 라우트다. 둘 중 하나만 틀려도 터널은 여전히 올라오며, 바로 그 점이 실패를 혼란스럽게 만든다.

단계를 순서대로 진행한다. 각 단계는 앞 단계의 계획에 의존하며, 어느 것도 새로운 인증 기관을 필요로 하지 않는다.

누구도 추측할 필요 없는 계획부터 시작한다

구성 파일을 건드리기 전에 중복되지 않는 네 개의 프리픽스, 곧 허브 자체의 LAN, 각 지사의 LAN, 그리고 로밍 클라이언트에 부여할 풀을 적어 둔다. 중복이 없어야 나머지가 단순해지는데, 범위가 겹치면 라우팅이 최장 일치 퍼즐로 변해 클라이언트별 구성을 아무리 추가해도 고칠 수 없기 때문이다. 다음으로, 자기 LAN의 게이트웨이가 아닌 지사 라우터는 원격 라우트를 전혀 다른 곳에 설치해야 하므로 각 LAN의 기본 게이트웨이가 어느 머신인지 확인한다. 마지막으로, 그 이름이 클라이언트별 파일을 조회하는 키이므로 각 지사를 식별하는 인증된 이름을 확정한다.

예시 계획은 풀을 세 개의 LAN에서 충분히 멀리 둔다. 당신의 계획은 다를 수 있으며, 유일한 엄격한 규칙은 어떤 두 범위도 겹치지 않는다는 것이다.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

지사가 어디에 있는지 허브 커널에 알린다

허브는 지사마다 두 가지 정보, 곧 프리픽스를 터널 장치로 보내는 커널 라우트와 iroute 항목, 즉 어느 클라이언트가 그것을 소유하는지 OpenVPN 프로세스에 알려 주는 항목이 필요하다. 커널 라우트만으로는 데몬이 어떤 피어가 받아야 하는지 여전히 결정해야 하므로 패킷이 터널에 도달한 뒤 멈춘다. iroute 항목만으로는 패킷이 따라갈 라우트 없이 커널에 남는다. 두 줄 모두 데몬이 실제로 읽는 구성에 속하므로, 다른 것을 디버깅하기 전에 확인할 가치가 있다.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

커널이 규칙 적용 지점이어야 할 때는 client-to-client를 꺼 둔다. 이 옵션은 피어 간 트래픽을 데몬 내부에서 중계하므로 편리하지만, 그 때문에 포워딩 규칙이 흐름을 전혀 보지 못한다. 아래의 모든 설명은 커널이 지사 간 패킷을 모두 본다고 가정한다.

각 지사에 필요한 라우트를 준다

각 지사에는 다른 지사와 허브 LAN으로 가는 라우트가 필요하고, 자신이 직접 연결된 LAN에 대한 라우트는 필요 없다. 원격 프리픽스를 모든 라우터에 붙여 넣는 대신 허브에서 밀어 주면, 나중에 네 번째 사이트를 추가할 때 네 곳을 고치는 대신 클라이언트별 파일 하나만 추가하면 된다. 클라이언트별 파일은 iroute 줄도 담고 있어 소유권과 광고가 같은 곳에 유지된다. 서버의 권한 모델에 따라 디렉터리와 그 파일을 읽을 수 있게 하지 않으면 조회가 메시지 없이 실패한다.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

네 번째 사이트도 고유한 인증 이름, 소유한 프리픽스, 허브의 커널 라우트, iroute 항목, 그리고 접근이 허용된 사이트에만 보내는 광고라는 같은 패턴을 따른다.

끝났다고 하기 전에 양방향으로 시험한다

세 라우터 모두에서 IPv4 포워딩을 켠 다음, 단방향 시험이 누구의 예상보다도 자주 끊긴 반환 경로를 가진 채 통과하기 때문에, 방화벽이 의도한 흐름을 양방향으로 허용하는지 확인한다. 사이트 간에 출발지 주소 변환은 필요 없으며, 원래 출발지를 보존하는 것이 각 지사가 요청에 자기 정책을 적용할 수 있게 하는 바로 그 점이다.

한 지사 LAN의 호스트에서 다른 지사의 서비스로 시험하고, 방향을 뒤집어 시험하고, 마지막으로 지사에서 허브 LAN으로 시험한다. 이 세 결과는 서로 다른 증거이며, 어느 것도 나머지를 함축하지 않는다. 지사 라우터가 자기 LAN의 기본 게이트웨이가 아니면 원격 프리픽스를 실제 게이트웨이에 설치하고, 터널 클라이언트가 그 LAN으로 연결을 시작해야 할 때는 풀도 포함한다.

다음 사이트 추가가 그것을 기준으로 판단되므로 계획, 클라이언트별 파일, 방화벽 규칙을 하나의 문서로 기록한다.

설계가 유지되는 이유는 계획이 프리픽스를 고유하게 유지하고, 커널 라우트가 패킷을 옮기고, iroute가 소유자를 밝히고, 방화벽이 무엇이 허용되는지 결정하는 식으로 각 계층이 하나의 일만 하기 때문이다. 무언가 깨졌을 때 그 목록이 곧 확인 순서이기도 하다.