마스커레이드와 정책 라우팅: VPN 게이트웨이를 통한 LAN 트래픽

LAN 전체를 VPN 터널 뒤에 두는 것은 쉬운 부분이다; 반대편이 그 클라이언트를 어떻게 보는지 정하는 것은 그렇지 않다. 마스커레이드는 각 LAN 소스를 게이트웨이의 터널 주소로 다시 쓰므로 반대편은 하나의 피어에게 응답한다. 정책 라우팅은 원래 주소를 유지하고 반대편이 그 주소에 도달하는 방법을 알아야 한다. 어느 쪽도 기본값이 아니다; 선택은 반대편을 누가 소유하는지, 기기별 정체성이 중요한지에 따른다.

두 설계는 서로 다른 것을 약속한다

마스커레이드는 LAN을 하나의 보이는 호스트, 즉 게이트웨이로 줄인다. 원격 네트워크는 그 하나의 주소에 응답하고, 게이트웨이는 응답을 흐름을 시작한 클라이언트로 다시 번역한다. 반대편에는 사설 프리픽스로 가는 경로가 필요 없다. 그래서 이 설계는 그것을 나르기를 거부하는 공급자와도 견딘다. 게이트웨이는 모든 연결의 소스도 되므로 반대편은 두 클라이언트를 구별할 수 없다.

정책 라우팅은 각 클라이언트의 주소를 그대로 유지한다. 원격 네트워크는 실제 소스를 보고 기록하거나, 호스트별 규칙을 적용하거나, 응답을 그 주소로 직접 보낼 수 있다. 이 가시성이 핵심이며 의무를 동반한다: 반대편에는 터널을 통해 되돌아가는 LAN 프리픽스 경로가 있어야 한다. 규칙을 켜기 전에 그 경로를 계획하라. 터널은 어쨌든 올라오고 응답만 빠질 것이다.

실패 방식은 약속만큼 다르다. 마스커레이드 규칙이 없으면 사설 소스로 나가서 돌아오지 않는 패킷이 생긴다. 반환 경로가 없으면 정책 라우팅에서도 같은 증상이 나타나지만, 고칠 곳은 게이트웨이가 아니라 원격 라우터다.

마스커레이드: 반대편에 하나의 피어

마스커레이드 경로에는 중요한 순서가 있다. 어떤 NAT 규칙도 쓸모가 있으려면 먼저 포워딩이 켜져 있어야 한다, 필터 테이블이 양방향 통과를 허용해야 하며, 그다음에야 터널 인터페이스에서 변환이 적용된다.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

클라이언트에게는 여전히 게이트웨이로 가는 경로가 필요하다. 게이트웨이가 기본 라우터이거나, 원격 프리픽스에 대한 특정 경로를 들고 있어야 한다; 별도 라우터가 기본으로 남는다면 그 라우터에 터널 대상에 대한 정적 경로가 필요하다. 그렇지 않으면 게이트웨이가 보기 전에 패킷이 잘못된 홉으로 간다.

DNS는 별도의 결정이다. 반대편의 리졸버는 응답이 클라이언트로 돌아갈 수 있을 때만 응답한다. 마스커레이드에서는 질의가 게이트웨이에서 온 것처럼 보이므로 리졸버의 반환 경로가 이미 충족된다; 정책 라우팅에서는 리졸버에 다른 원격 서비스와 같은 반환 경로가 필요하다.

정책 라우팅: 소스를 유지하고 반환 경로를 더한다

정책 라우팅은 테이블과 그것을 선택하는 규칙으로 시작한다. LAN 인터페이스에서 들어오는 트래픽은 전용 테이블로 보내지고, 그 테이블은 터널을 통한 기본 경로를 담는다. 메인 테이블은 그대로이므로 게이트웨이 자체가 만든 트래픽은 다른 경로를 따를 수 있다.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

그다음 반대편이 LAN 프리픽스를 터널을 통해 되돌려 라우팅해야 한다. 그것은 이 게이트웨이가 아니라 원격 라우터의 설정이다. 게이트웨이는 메인 테이블이 예상하는 것과 다른 인터페이스로 도착하는 응답도 받아들여야 한다; 엄격 모드가 그 패킷을 버릴 때 느슨한 역경로 필터링(rp_filter를 2로 설정)이 보통의 조정이다.

두 터널이 활성일 때 각 흐름을 들어올 때 태그하고 태그가 테이블을 고르게 하라. 입력 인터페이스만 보는 규칙은 두 터널의 트래픽을 같은 테이블로 보내므로 두 번째 터널이 첫 번째의 흐름을 훔친다. 그 태그를 재연결을 견디는 연결로 시험하라. 혼합 정책은 그때 드러난다.

소유권과 반대편이 무엇을 기록하는지로 결정하라

터널이 공급자에서 끝나면 마스커레이드를 써라. 그 사업자는 당신의 사설 LAN 대역을 라우팅하지 않을 것이고, 게이트웨이 뒤의 개별 클라이언트를 구별할 이유도 없다. 보이는 피어 하나가 그 정책이 지지하는 유일한 모델이므로 그것을 주고 변환은 당신 쪽 끝에 두라. 공급자는 피어 하나를 본다. 그것이 바로 그 정책이 기대하는 것이며, 당신의 클라이언트는 그 하나의 정체성을 물려받는다.

양쪽 끝이 당신 것이고 원격 서비스가 소스 주소로 동작한다면 정책 라우팅은 추가 경로를 얻을 자격이 있다. 그러면 방화벽 규칙, 사용자별 접근, 감사 로그가 클라이언트를 구별할 수 있다. 반대편에 도달성만 필요하다면 마스커레이드가 더 단순하고 반환 경로 오류 한 부류를 없앤다.

하이브리드 설계는 흔하다: 자기 네트워크 안에서는 정책 라우팅, 공급자 경계에서는 마스커레이드. 중요한 것은 어느 홉이 변환하고 어느 홉이 라우팅하는지 적어 두는 것이다. 한 클라이언트를 위해 실수로 추가한 NAT 규칙은 같은 체인의 모든 클라이언트에게서 소스를 숨긴다.

한 클라이언트에서 확인하고, 다음에 두 번째 클라이언트에서 확인하라

트래픽이 시작되는 곳에서 시험을 실행하라. 호스트가 쓰는 경로를 확인하고, 패킷이 터널 인터페이스에 나타나는 것을 보고, 변환을 위해 conntrack을 검사하라. 그 순서가 패킷이 의도한 경로를 탔음을 증명한다. 단지 어딘가에 도착한 것이 아니다.

재연결 후 시험을 반복하라. 인터페이스를 지정한 마스커레이드 규칙은 새 터널 주소에서도 살아남는다; 옛 주소를 지정한 규칙은 그렇지 않다. 다음에 두 번째 LAN 호스트를 시험하라. 한 머신에서 되는 설계는 게이트웨이 정책이 아니라 그 머신 자체의 경로에 기대는 경우가 많다.

선택한 모델, 변환했거나 보존한 소스, 반환 경로의 소유자를 게이트웨이 메모에 적어라. 그렇지 않으면 다음 사람이 클라이언트나 터널을 추가할 때 추측할 것이다. 추측은 잘 돌던 LAN-to-VPN 구성을 부분적인 것으로 만드는 길이다.