NIC 하나 또는 둘? VPN 서버의 인터페이스 배치 결정

많은 VPN 서버에는 물리 어댑터 하나로 충분하며, 그것이 보편적인 설계도 아닙니다. 암호화된 연결은 그 어댑터로 들어오고, VPN 프로세스가 이를 복호화한 뒤 내부 트래픽이 가상 인터페이스로 나갑니다, 로컬 서비스나 라우팅된 LAN에 도달하기 전에 말입니다. 그것이 되는지는 목적지가 어디에 있는지, LAN에 클라이언트 풀까지의 귀로가 있는지, 공유된 물리 링크 하나가 주장하는 격리를 제공하는지에 달려 있습니다. 이 셋에 답하면 어댑터 수는 따라옵니다.

이를 결정하는 세 가지 조건

첫 번째 조건은 목적지입니다. VPN 호스트 자체에 있는 서비스는 터널 인터페이스만으로 도달되지만, LAN에 있는 호스트는 포워딩과 귀로가 필요합니다. 두 번째 조건은 그 귀로인데, LAN 장치가 클라이언트 풀에 경로로든 서버에서의 변환으로든 어떻게 도달할지 알아야 하기 때문입니다.

세 번째 조건은 분리입니다. 어댑터 하나는 암호화 여부와 무관하게 모든 패킷이 같은 링크와 대개 같은 정책 체인을 공유한다는 뜻이므로, 별도 하드웨어에 의존하는 격리 주장은 인터페이스 하나로 충족되지 않습니다. 그것은 경로에 관한 사실이며 운영체제 설정 방식에 관한 것이 아닙니다. 터널 트래픽을 필터링할 수는 있지만, 갖지 못한 경계를 주장할 수는 없습니다.

이 셋 중 어느 것도 섀시의 포트 수에 관한 것이 아닙니다. 라우팅, 주소 소유권, 그리고 설계가 물리적 분리에 얼마나 의존하는지에 관한 것입니다.

물리 구역, 별도 업링크, 처리량, 대역 외 복구 경로가 정당화한다면 어댑터 둘은 여전히 합당한 선택입니다. 그것들은 구체적인 요구 사항이며, 누군가 하드웨어를 주문하기 전에 문장으로 적어 둘 가치가 있습니다.

서비스가 VPN 호스트에서 실행될 때

가장 단순한 경우에는 포워딩이 전혀 필요 없습니다. 데몬은 터널 인터페이스에서 클라이언트의 패킷을 받아 로컬 소켓에 넘기고, 응답은 같은 인터페이스로 돌아옵니다. 호스트 입장에서 클라이언트 풀 주소는 진짜 로컬 주소입니다.

그래도 서비스는 터널이 도달할 수 있는 주소에서 수신해야 하고, 호스트 방화벽은 터널 인터페이스로 들어오는 트래픽을 받아들여야 합니다. 둘 다 아래 명령에서 확인됩니다.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

서비스를 공인 주소에만 바인딩하거나 실수로 터널 인터페이스를 필터링하면, 호스트까지 도달한 뒤 죽는 연결이 생깁니다. VPN 장애처럼 보이지만 대개는 소켓이나 방화벽의 결정입니다.

목적지가 LAN에 있을 때

여기서 단일 어댑터 설계가 까다롭다는 평판을 얻습니다. 서버는 클라이언트의 패킷을 LAN 쪽으로 포워딩해야 하고, LAN 장치는 응답을 클라이언트 풀로 되돌려 보내야 합니다. 그 풀을 LAN의 경로로 실어 나르거나, 서버에서 출발지 주소를 변환해 응답이 서버 자신에게 돌아오게 합니다.

두 답 모두 타당하며 서로 다르게 실패합니다. 귀로 경로는 원래 클라이언트 주소를 목적지에 그대로 보이게 하므로 로그에는 좋고 LAN 주소를 가정하는 방화벽 규칙에는 나쁩니다. 변환은 LAN을 단순하게 유지하고 클라이언트 신원을 목적지에서 숨깁니다.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

비대칭 경로가 전형적인 증상으로, 클라이언트의 요청은 도착하고, 응답은 다른 라우터로 나가며, 양쪽 끝 어디에도 오류 없이 연결이 시간 초과됩니다. 터널에 대해 무언가를 단정하기 전에 양쪽에서 캡처하십시오.

별칭이 두 번째 영역을 만들지 않는 이유

같은 어댑터에 두 번째 주소를 추가하거나, 두 번째 포트를 흉내 내는 더미 인터페이스를 만드는 것은 거의 아무것도 바꾸지 않습니다. 패킷은 여전히 같은 물리 링크, 같은 스위치 포트, 대개 같은 방화벽 체인으로 나가므로 둘 사이에 새로운 경계가 생기지 않습니다. 그것은 설정의 편의이지 세그멘테이션이 아닙니다. 이를 영역 경계로 취급하는 것이 격리 주장이 종이 위에서만 살아남는 방식입니다.

별도 영역은 경로에 실제 분리가 필요하며, 그 요구를 두 번째 어댑터가 충족합니다. 규칙이 VPN 쪽 트래픽과 LAN 쪽 트래픽이 절대 브로드캐스트 도메인을 공유하지 않는다는 데 의존한다면, 호스트의 주소 지정 방식과 무관하게 케이블 하나로는 그 속성을 줄 수 없습니다.

특정 모드에 대해 제품이 다중 인터페이스 토폴로지를 문서화한다면, 우회책을 만들어 내지 말고 그 제품의 문서를 따르십시오. 벤더는 릴리스 사이에 지원 토폴로지도 바꾸므로, 오래된 마법사 스크린샷보다 현재 가이드를 읽어야 할 또 하나의 이유입니다.

허용하는 트래픽에 비추어 배치를 점검하십시오

서버가 실어 나를 트래픽 분류를 클라이언트에서 호스트로, 클라이언트에서 LAN으로, 호스트에서 LAN으로, 그리고 암호화된 외부 연결로 나열하십시오. 각 분류에는 출발지, 목적지, 인터페이스가 있고, 배치는 네 가지를 동시에 충족해야 합니다. 그중 셋만 다루는 설계가 대개 티켓을 만들어 내는 설계입니다.

그다음 설계 문서의 다이어그램이 아니라 실제 인터페이스와 실제 캡처를 확인하십시오. 아래 명령은 두 화면을 모두 출력합니다.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

바깥 캡처가 암호화된 트래픽을 보여 주고 안쪽 캡처가 터널 인터페이스의 복호화된 트래픽을 보여 주며 물리 어댑터가 둘 다 실어 나른다면, NIC 하나가 일을 하고 있는 것입니다. 안쪽 캡처가 비어 있다면 문제는 터널이나 포워딩 규칙에 있으며 어댑터 수에 있지 않습니다. 그 두 캡처와 라우팅 테이블로 토폴로지를 정하면, 다음 변경에는 비교할 대상이 생깁니다.