OpenWrt에서 LAN 전체를 OpenVPN 클라이언트로: 동작하는 순서

라우터의 LAN 전체를 하나의 터널 뒤에 두려면 네 가지 독립적인 작업이 필요하다. 터널 장치에는 소유자, 방화벽 존, 업링크 쪽으로 향하는 변환 대상, 그리고 일부 클라이언트가 VPN 밖에 있어야 한다면 출발지 주소 기반 라우팅이 필요하다. 연결은 되지만 아무것도 지나가지 않는 터널은 보통 이 네 가지 중 하나가 빠져 있다. 의존 순서로 작업하면 마지막에 생긴 실패는 방금 바꾼 단계의 몫이다. 아래의 각 단계는 눈으로 확인할 수 있는 것으로 끝나므로 다음 단계가 추측이 되지 않는다.

무엇이 터널을 공유할지 정한다

Wi-Fi와 DHCP를 나눠 주는 라우터가 클라이언트를 직접 실행할 수 있다. 그러면 연결된 모든 장치가 장치별 설정 없이 터널 뒤에 들어가고, 작은 사이트 대부분이 원하는 구성이 바로 이것이다. 터널이 끊길 때 영향 범위도 이 구성이 가장 넓은데, 모든 장치가 한꺼번에 경로를 잃기 때문이다. LAN 쪽에는 밖으로 나가는 살아 있는 경로가 남지 않는다.

첫 번째 라우터 뒤에서 자체 서브넷으로 클라이언트를 돌리는 두 번째 라우터는 터널을 자기 장치로만 한정한다. 제거하기도 쉽고 물려받는 사람에게 설명하기도 쉽다. 대가는 경로나 포트 포워딩 없이는 양쪽 사이의 도달성이 없다는 것이다.

어느 쪽이든 LAN 서브넷은 서로 다르게 만든다. 같은 범위는 한쪽이 직접 연결된 것처럼 보이게 하고, 그 결과 생기는 블랙홀은 VPN 고장처럼 읽힌다 몇 시간 동안.

터널에 소유자를 준다

터널을 이름과 장치를 가지며 자체 프로토콜이 없는 네트워크 인터페이스로 선언한다. 그러면 네트워크 시스템이 장치를 만들고 관리하며, 그 뒤의 모든 것은 장치가 아니라 이름으로 인터페이스를 가리킨다. 그것이 존이 터널을 찾게 해 준다.

같은 장치를 두 곳에서 만들지 않는다. 선언된 인터페이스 옆에 손으로 만든 터널이 있으면 존재하지만 존에 없는 장치가 생기거나, 다시 불러올 때 사라지는 장치가 생긴다. 둘 다 클라이언트가 실패한 것처럼 보이고, 둘 다 진짜 원인을 말하는 오류를 내지 않는다. 선언 방식의 길을 고르고 손으로 만든 쪽을 지운다.

네트워크, 방화벽, VPN 설정에서 이름을 똑같이 유지한다. 존은 네트워크를 이름으로 나열하므로 오타 하나면 인터페이스는 멀쩡해 보이는데 터널이 모든 존 밖에 남는다. 정책 없는 멀쩡한 인터페이스는 가장 알아채기 어려운 상태다.

존으로 넣고, 그다음 그 안으로 전달한다

방화벽 존은 입력, 출력, 전달, 매스커레이드라는 정책이 사는 곳이다. 어떤 존에도 없는 터널은 당신이 고르지 않은 기본값의 지배를 받고, 라우터 클라이언트에 그런 형태가 필요한 경우는 드물다. 아래 스탠자는 인터페이스를 선언하고, 존에 넣고, LAN 트래픽이 그 존으로 들어가도록 허용한다.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

21.02보다 오래된 릴리스에서는 같은 인터페이스 줄을 option ifname 라고 쓴다, 그러니 붙여 넣기 전에 설치된 펌웨어가 어느 형태를 읽는지 확인한다. 전달 스탠자가 있어야 LAN 트래픽이 터널을 아예 쓸 수 있다. 그것이 없으면 장치는 켜져 있고 클라이언트는 연결되었는데 어떤 LAN 호스트도 터널에 닿지 않는다. 라우터 클라이언트에서 가장 흔한 연결됨, 인터넷 없음 보고가 이것이다.

VPN 존의 매스커레이드는 패킷이 떠나기 전에 모든 LAN 주소를 라우터의 터널 주소로 접어 넣는다. 그러면 반대편의 당신 서브넷으로 돌아오는 경로가 필요 없어진다.

반대편이 이미 당신 LAN으로 가는 경로를 알고 있다면, 매스커레이드를 끄면 출발지 주소가 그대로 보이고 클라이언트별 로그가 의미를 갖는다. 두 선택은 나중에 서로 다른 지원 질문을 만들므로 하나를 고르고 어느 쪽인지 적어 둔다. 기본 LAN에서 WAN으로의 전달을 없애는 것은 그 자체의 결과가 따르는 별개의 결정이다. 그것을 없애면 라우터 자신의 인터넷 접속도 함께 사라진다.

NAT에서 진짜 업링크를 지목한다

변환 규칙을 손으로 쓰는 펌웨어에서는 나가는 인터페이스가 잘못되는 필드다. 규칙이 vlan2 를 가리켜도 세션이 ppp0 에서 끝나면 아무 일도 하지 않는다. 인터페이스가 아예 없는 규칙은 비공개로 남아야 할 트래픽까지 변환할 수 있다. 터널은 계속 동작하므로 두 실수 모두 스스로를 알리지 않는다.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

그 규칙에서 ppp0 를 ip route 또는 실행 중인 인터페이스 목록에 있는 인터페이스로 바꾸고, LAN 호스트가 페이지를 여는 동안 카운터를 본다. 단일 통신사 라우터에서는 업링크용 매스커레이드 규칙 하나로 보통 충분하다. 터널 인터페이스용 두 번째 규칙은 첫 번째의 대체물이 아니다.

그다음 터널로 무엇이 들어가는지 정하는 클라이언트 옵션을 추가한다. redirect-gateway 지시자는 클라이언트의 인터넷 트래픽을 VPN으로 보내고, 그것이 없으면 터널은 서버가 밀어 넣는 경로만 나른다. DNS를 건드리기 전에 나온 라우팅 테이블을 확인한다.

두 번째 테이블로 Wi-Fi를 나눈다

라우팅 테이블 하나에 기본 경로 두 개를 담을 수 없다. 그래서 터널을 우회해야 하는 두 번째 SSID에는 자체 서브넷과 자체 테이블이 필요하다. 터널 쪽 SSID에 자체 범위를 주고, 테이블을 고르는 규칙으로 그 범위만 터널로 보낸다.

OpenWrt의 정책 라우팅 패키지가 바로 그 조합을 표현한다. 손으로 해도 되는데, 출발지 규칙과 기본값이 터널 장치를 가리키는 테이블을 쓰면 된다.

두 네트워크에서 나눔을 확인한다. 터널 쪽 SSID의 클라이언트는 VPN의 출구 주소를, 일반 SSID의 클라이언트는 통신사의 주소를 보여야 한다. 둘이 같아 보이면 규칙이 잘못된 출발지에 맞거나 테이블이 아예 조회되지 않는 것이다. 인터페이스 이름에 의존하는 규칙은 장치 번호가 바뀌면 깨지므로 다시 연결한 뒤에도 시험한다.

시계와 장치 플래그를 의심한다

이 persist-tun 플래그는 재시작을 넘겨 터널 장치를 그대로 둔다. 서버에는 어울리지만 상태를 처음부터 다시 세워야 하는 클라이언트를 헷갈리게 한다. 실패한 협상을 버틴 장치가 어느 단계가 실제로 깨졌는지를 가리므로 라우터 클라이언트를 진단하는 동안에는 이것을 뺀다. 클라이언트가 안정적으로 연결된 뒤에 되돌리고, 그 전에는 되돌리지 않는다.

시계는 또 하나의 조용한 실패다. 배터리 시계가 없는 라우터는 에포크에서 시작하므로 NTP가 따라잡을 때까지 인증서 검사가 실패한다. 부팅 일 분 뒤에 연결하는 클라이언트는 보통 시간 동기화를 기다리고 있으므로 인증서를 건드리기 전에 로그 시각을 실제 시간과 비교한다.