사이트 간 VPN과 원격 액세스 VPN: 각각 무엇을 연결하는가

두 설계 모두 VPN이라고 불리지만 서로 다른 문제를 해결합니다. 사이트 간 터널은 두 게이트웨이를 연결하므로 그 뒤의 모든 호스트가 아무것도 설치하지 않고 반대편의 허용된 주소에 도달할 수 있습니다. 원격 액세스 터널은 개별 장치를 네트워크에 연결하며 한 번에 한 클라이언트씩 연결합니다. 이 비교가 중요한 이유는 대부분의 배포 실수가 한쪽을 구성하면서 다른 쪽의 동작을 기대하기 때문에 생기며, 증상은 보통 터널이 실제로 도달한 서비스에서의 시간 초과입니다.

두 설계, 두 경계

어느 설계도 LAN 브로드캐스트 도메인을 확장하지 않습니다. 반대편 장치는 로컬 검색 목록에 나타나지 않으며, 그렇게 되리라 기대하는 것이 가장 먼저 버려야 할 가정입니다. 의도적으로 게시한 사설 DNS 이름은 어떤 검색 프로토콜보다 예측 가능하고 공급업체를 바꿔도 유지됩니다.

한 사이트에서 10.10.0.0/24, 다른 사이트에서 10.20.0.0/24를 사용합니다. 게이트웨이 A에는 10.20.0.0/24 접두사를 터널로 보내는 경로나 트래픽 선택자가 필요하고, 게이트웨이 B에는 그 거울상이 필요합니다. 그런 다음 양쪽 호스트는 평범한 IP 연결을 사용하며 터널이 존재한다는 사실을 알지 못합니다. 이 보이지 않음이 기능이며, 장애가 터널 오류가 아니라 평범한 네트워크 오류처럼 보이는 이유이기도 합니다.

정책 기반과 경로 기반은 같은 터널이 아닙니다

정책 기반 IPsec 배포에서는 협상된 트래픽 선택자가 어떤 출발지와 목적지 쌍이 보호되는지 정확히 정의합니다. 한 게이트웨이 뒤에 새 서브넷이 나타났는데 어떤 선택자도 이를 포함하지 않으면 터널은 계속 작동하고 새 서브넷은 그저 전달되지 않습니다. 경로 기반 설계에서는 인터페이스가 트래픽을 받고 라우팅 테이블이 결정하므로, 접두사를 추가하는 것은 터널 재협상이 아니라 경로 변경이 됩니다.

StrongSwan은 두 관점을 직접 보여 주며, 둘을 함께 읽는 것이 실제로 어떤 모델을 배포했는지 알아내는 방법입니다.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

필요한 접두사가 빠진 선택자 목록은 패킷 캡처 없이도 장애를 설명하고, 잘못된 인터페이스를 가리키는 경로는 돌아오는 방향의 거울 장애를 설명합니다. 무언가를 다시 협상하기 전에 둘 다 읽으십시오. 키 갱신은 한 번도 구성하지 않은 선택자를 추가하지 않기 때문입니다.

터널 전에 주소 지정을 계획하십시오

겹치는 범위는 구성으로 고칠 수 없는 설계 실수입니다. 두 사이트가 모두 192.168.1.0/24를 사용하면 192.168.1.50이 필요한 호스트는 후보가 둘이고 선택할 방법이 없습니다. 터널은 인증되고 보안 연결이 설정되며, 라우팅 결정은 그럼에도 잘못되거나 모호합니다.

세 가지 정직한 선택 중 하나를 고르십시오. 한 사이트의 번호를 다시 매기거나, 게이트웨이에서 겹치는 범위를 변환해 각 측이 서로 다른 접두사를 보게 하거나, 해당 호스트의 직접 라우팅을 포기하고 서비스를 다른 방식으로 게시하는 것입니다. 각각 비용이 있으며 두 해의 지평에서는 첫 번째가 보통 가장 저렴합니다. 터널이 생기기 전에 결정하십시오. 나중에는 그 변경이 이전 주소를 가진 모든 장치에 영향을 줍니다.

MTU 문제도 일찍 해결하십시오. 터널은 사용 가능한 페이로드를 줄이며, 단편화에 의존하는 설계는 게이트웨이에서 MSS를 고정하는 설계와 다르게 동작합니다.

전달과 정책은 터널 밖에 있습니다

게이트웨이는 터널 인터페이스와 LAN 인터페이스 사이에서 패킷을 전달할 의사가 있어야 하며, 양방향 모두 서비스를 허용하는 정책이 필요합니다. Linux에서는 이것이 두 개의 별도 설정이며, 전달된 흐름이 애초에 허용되는지 결정하는 방화벽 규칙도 있습니다.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

수신 호스트는 세 번째 계층을 추가합니다. 자체 방화벽이 여전히 원격 서브넷의 클라이언트를 받아들여야 합니다. 로컬 /24만 허용하는 파일 서버는 터널이 아무리 건강해 보여도 10.20.0.7에서 전달된 트래픽을 거부하며, 그 거부는 라우팅 장애로 잘못 읽히기 쉽습니다.

게이트웨이가 아니라 호스트에서 시험하십시오

게이트웨이 자체가 보내는 ping은 전달되는 사용자 트래픽과 다른 출발지 주소와 다른 정책을 따를 수 있습니다. 그래서 이것은 약한 시험이며 때로는 오해를 부릅니다. 애플리케이션이 실패할 때 성공하거나, 애플리케이션이 동작할 때 실패합니다.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

실제 호스트, 실제 출발지 주소, 애플리케이션이 사용하는 실제 프로토콜을 사용하십시오. 그런 다음 반환 경로를 따로 읽으십시오. 반환 경로가 없는 정상적인 전방 방향은 차단된 서비스와 똑같아 보이는 시간 초과를 만듭니다.

설계는 여러분이 답하려는 질문에 따라 고르십시오. 네트워크를 연결하는가, 아니면 장치를 받아들이는가? 어떤 공급업체를 구성하는지를 포함한 나머지 모든 것은 그 답에서 나옵니다.