NAT를 VPN 서버에 둘까, 라우터에 둘까? 둘 다 동작한다
클라이언트의 기본 경로는 출구를 만들지 않습니다. VPN 서버에서 변환하는 방식과 풀을 라우터로 가져가는 방식을 비교하고 소유자를 하나 정하세요.
노트북에서 연결을 기본 경로로 표시하는 것은 누구나 기억하는 단계이며, 게이트웨이에서는 아무것도 바꾸지 않는 바로 그 단계입니다. 이제 클라이언트는 인터넷 요청을 터널로 보내며, 요청이 건물을 떠나는지는 포워딩, 변환 지점, 그리고 클라이언트의 사설 주소에 도달하는 반환 경로에 달려 있습니다. 두 가지 구성이 세 가지를 모두 제공할 수 있지만 작업을 서로 다른 곳에 두며, 응답 방향을 맡는 사람이 없을 때 둘 다 같은 조용한 방식으로 실패합니다. 둘 중 하나를 고르는 것은 클라이언트 풀을 누가 봐야 하는지에 대한 질문입니다.
신화: 클라이언트 경로가 출구를 만든다
강제 터널링은 클라이언트 측 정책이며, 트래픽이 물리 어댑터가 아니라 VPN 어댑터로 간다고 결정합니다. Microsoft의 VPN 라우팅 문서는 그 분할과 강제 동작을 설명하며, 이는 클라이언트의 라우팅 테이블에 대한 진술이지 서버의 포워딩 규칙에 대한 것이 아닙니다. 클라이언트 입장에서 터널은 인터넷이 사는 곳이고, 게이트웨이 입장에서 패킷은 위쪽의 누구도 들어본 적 없는 주소에서 도착한 것입니다. 어느 쪽도 단독으로 잘못 설정된 것이 아니므로, 노트북 앞의 사람에게 이 실패는 고장 난 서버처럼 보입니다.
그 불일치가 이 글의 나머지가 해결하는 문제 전체입니다. 무언가가 클라이언트의 사설 주소를 반환 가능하게 만들어야 하며, 선택은 어디에서 하느냐입니다.
먼저 반환 경로를 그리세요
어떤 설정도 건드리기 전에 실제 주소로 경로를 적고, 그 위에 두 개의 후보 변환 지점을 표시하세요. 이 실험실은 10.70.0.0/24 VPN 풀을 사용하며, 클라이언트 하나가 10.70.0.37에, 서버 LAN 주소가 172.16.40.10에, 라우터가 172.16.40.1에, 공용 출구가 203.0.113.40에 있습니다.
client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
(translate here?) (or here?)이미 인터넷을 탐색하는 서버는 자기 경로만 증명합니다. 클라이언트를 대신해 포워딩된 패킷은 다른 결정이며, 같은 머신의 포워딩 정책이 내리는 결정이고, 보통 빠져 있는 것이 바로 이것입니다. 다이어그램에 세 결정 지점을 표시하면 대화가 한 번에 그중 하나에 머뭅니다.
옵션 A: VPN 서버에서 변환
여기서 서버는 패킷을 라우터에 넘기기 전에 클라이언트의 출발지를 자신의 LAN 주소로 변환하고, 라우터는 나가는 길에 평소의 변환을 적용합니다. 응답에서는 라우터의 매핑이 서버 주소를 복원하고 서버의 매핑이 클라이언트 주소를 복원합니다. 직렬로 이어지는 두 개의 상태 기반 변환은, 둘 다 기록된다는 조건에서 정상이며 실행 가능하고, 라우터는 풀을 향한 경로가 결코 필요 없으며, 그것이 이 구성의 매력입니다.
Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefixNAT가 있다고 가정하는 대신 서버에 이미 무엇이 있는지 보려면 이 읽기를 사용하세요. 블로그에서 복사한 Linux masquerade 규칙은 Windows 구성이 아니며, VPN 수신기에 대한 호스트 방화벽의 허용은 클라이언트 요청을 앞으로 포워딩할 수 있는 권한과 같은 정책이 아닙니다. 배포의 서로 다른 부분이 둘을 활성화하는 경우가 많기 때문에, 서버의 포워딩 역할은 서버 자체의 관리 화면에서 확인하고 그다음 변환은 따로 살펴보세요.
옵션 B: 풀을 라우터로 가져가기
두 번째 구성에서는 서버가 클라이언트의 실제 출발지 주소를 포워딩하고 라우터가 이를 변환합니다. 이렇게 하면 클라이언트 풀이 경계에서 보이며, 트래픽 정책이나 로깅, 검사가 라우터에 있을 때 도움이 됩니다. 또한 라우터에는 10.70.0.0/24에 대한 172.16.40.10을 가리키는 반환 경로와 그 프리픽스를 실제로 포함하는 인터넷 정책이 필요하며, LAN 서브넷을 위해 작성된 규칙이 조용히 풀까지 확장되지는 않습니다.
경계 장치가 의도된 정책 소유자이고 라우팅 및 변환 테이블에 다른 프리픽스를 받아들일 수 있을 때 이것을 고르세요. 풀이 위쪽에서 보이지 않아야 하고 라우터를 같은 팀이 관리하지 않을 때는 서버 측 변환을 고르세요. 어느 선택도 클라이언트의 체크박스에서 나오지 않으며, 어느 쪽이 일반적으로 더 안전하지도 않고, 두 방식은 가시성과 유지 관리를 서로 다른 곳에 둡니다.
DNS, IPv6, 수용을 명시하세요
주소 변환은 이름 확인을 고치지 않습니다. 클라이언트는 VPN 프로필과 함께 제공된 리졸버, 특정 네임스페이스를 위한 사설 리졸버, 또는 승인된 공용 리졸버를 사용할 수 있으며, 그 정책 아래에서 도달할 수 없는 리졸버는 라우팅이 동작한 뒤에도 계속 실패합니다. 이름과 주소를 따로 시험하여 두 실패가 하나의 보고서로 합쳐지지 않게 하세요.
IPv6는 설계에서 자신만의 문단이 필요합니다. 동작하는 IPv4 변환은 IPv6 클라이언트에 경로가 있는지, 유효한 공용 출발지가 있는지, 터널이 끊길 때 이들을 차단하는 정책이 있는지에 대해 아무것도 말하지 않습니다. 이를 말하지 않고 두면 절반의 클라이언트는 조용히 게이트웨이를 우회하고 나머지 절반은 동작합니다.
수용을 위해 허용된 클라이언트 요청 하나와 그 응답을 두 경계에 걸쳐 추적하고, 그 순간 각 경계가 보아야 할 주소를 적으세요. 그 기록이 있기에 다음 풀 변경은 사라진 반환 경로의 소유자가 누구인지에 대한 논쟁이 아니라 오 분짜리 편집이 됩니다. 다음 엔지니어가 가장 먼저 찾는 것이 프로필이므로, 기록은 티켓이 아니라 클라이언트 프로필과 함께 보관하세요.