Access Server 클라이언트가 LAN에서 도달할 수 없는 이유

노트북이 연결되고 터널이 올라오면 내부 서비스로 가는 요청이 연결 단계에서 멈춘다. 서비스 쪽에서는 요청이 10.90.0.25 같은 주소에서 도착하고, 응답은 기본 게이트웨이로 나가며, 아무것도 돌아오지 않는 것은 그 게이트웨이가 10.90.0.25이 어디에 있는지 전혀 모르기 때문이다. 반대편에서 보면 같은 고장이 연결된 클라이언트에 ping을 보낼 수 없는 내부 호스트처럼 보인다. 둘 다 하나의 빠진 객체, 즉 VPN 클라이언트 풀으로 가는 반환 경로이며, 사설 네트워크만이 이를 추가할 수 있다.

서비스가 보는 출발지 주소를 읽어라

그 필드 하나가 나머지 전부를 결정한다. 내부 서비스가 풀 주소를 본다면 Access Server는 클라이언트 트래픽을 숨기는 것이 아니라 라우팅하고 있으며, 모든 응답이 풀로 되돌아가도록 라우팅되어야 한다. 대신 서버 자신의 사설 주소를 본다면 서버는 매스커레이드를 하고 있으며 반환 경로는 이미 동작하지만, 그 대신 서비스의 로그와 접근 규칙에서 클라이언트별 식별 정보를 잃는 비용을 치른다.

무엇이든 바꾸기 전에 양쪽 끝을 비교하라. 서버에서는 터널 인터페이스와 그 주소를 나열하고, 클라이언트에서는 실제로 어느 주소를 보유하는지 확인하고, 내부 호스트에서는 살아 있는 연결을 살펴보라.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

마지막 명령이 바로 고장 난 경우에 실패하는 명령으로, 터널 접두사를 도달 불가로 보고하거나, 더 나쁘게는 기본 게이트웨이를 돌려주며, 그래서 응답이 인터넷으로 나간다.

풀이 하나뿐이라고 가정하지 마라. 서버에는 동적 범위와 사용자별 정적 매핑이 함께 있을 수 있고, 정적 주소는 동적 접두사 밖에 완전히 있을 수도 있다. 기억나는 범위만 라우팅하면 고정 주소를 쓰는 사용자는 계속 고장 나 있고 나머지 모두는 문제가 해결되었다고 보고한다.

응답이 결정되는 곳에 경로를 추가하라

경로는 내부 서비스가 이미 사용하는 게이트웨이에 두는 것이지, 서비스가 자체 트래픽을 라우팅하지 않는 한 서비스에 두는 것이 아니다. 클라이언트가 가진 터널 주소와 다른 값인 Access Server의 도달 가능한 사설 주소를 가리키게 하라.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

클라우드 네트워크에서는 같은 문장이 라우팅 테이블 항목이 되며, 대상은 서버가 실행되는 인스턴스나 네트워크 인터페이스이고 그 인터페이스에서 출발지 및 목적지 검사가 꺼져 있다. 그 항목은 접근 권한을 주지 않으므로 보안 그룹, 네트워크 ACL, 호스트 방화벽이 여전히 트래픽을 허용해야 한다.

경로를 영구적으로 만들고 풀 크기를 정직하게 유지하라. 인접하지 않은 두 풀에는 두 개의 경로가 필요하고, 설정된 접두사를 넘어 커지는 풀은 응답이 갈 곳이 없는 클라이언트를 조용히 만들어 낸다. 풀 범위를 관리한다면 한 번 라우팅하고 그대로 둘 수 있는 요약을 선택하라.

포워딩과 필터는 경로와 일치해야 한다

라우팅은 경로의 절반에 불과하다. 서버는 터널과 사설 인터페이스 사이에서 포워딩할 수 있어야 하며, 리눅스에서는 net.ipv4.ip_forward과 그 인터페이스 쌍을 허용하는 포워딩 체인을 뜻하고, 강화된 호스트에서는 보통 방향마다 명시적 규칙을 둔다.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

상태 기반 필터링은 사람들을 잘못된 길로 이끄는 증상을 설명한다. 이미 성립된 흐름 안의 응답에는 새로운 인바운드 규칙이 필요하지 않으므로, SYN-ACK 이후 멈추는 연결은 허용 규칙 부재로 차단되는 것이 아니라 버려지거나 잘못 라우팅되는 것이다. 이 구분을 유지해야 하는데, 라우팅 변경과 방화벽 변경을 갈라 주기 때문이다.

비대칭 반환 경로는 같은 문제의 더 조용한 형태다. 두 개의 경로가 풀에 도달하고 응답이 요청이 들어온 인터페이스와 다른 인터페이스로 나가는 경로를 택하면, 엄격한 역경로 필터링이 이를 버리고 일부 클라이언트에서만 흐름이 실패한다.

라우팅 모드인가 매스커레이드인가, 의도적으로 선택하라

라우팅 모드는 서비스 쪽에서 클라이언트의 풀 주소를 유지하므로 클라이언트별 로깅과 정책이 가능해지고, 그 대가로 클라이언트에 응답해야 하는 모든 내부 네트워크에 풀 경로가 필요하다. 매스커레이드 모드는 응답이 서버로 돌아오기 때문에 그 요구를 없애지만, 서비스는 더 이상 클라이언트를 서로 구별할 수 없고 특정 클라이언트를 향해 무엇도 시작할 수 없다.

실행 중인 서버에서 그 동작을 바꾸면 기존 세션이 끊기므로 먼저 클라이언트 하나와 흐름 하나로 시험하라. 전환이 정답이라면 그것은 서버의 구성 결정이며, 나중에 불필요해질 경로를 덧붙여 우회할 일이 아니다.

클라이언트 뒤의 서브넷은 별개의 작업이다

노트북 자체의 LAN에 있는 장치에 도달하기은 노트북의 터널 주소에 도달하는 것과 같지 않다. 클라이언트가 서브넷 게이트웨이 역할을 해야 하며, 클라이언트 쪽에서 선언된 네트워크, 클라이언트 운영체제에서 활성화된 포워딩, 그 LAN에서 클라이언트로 돌아오는 경로가 필요하다. 노트북의 가정 범위에 사설 네트워크 경로를 추가하는 것은 이를 해 주지 않으며, 두 사용자가 같은 가정 범위를 쓰면 충돌을 만든다.

방향도 정책의 문제다. 클라이언트가 내부 서비스로 연결을 여는 권한이 내부 호스트가 그 클라이언트로 연결을 여는 권한을 자동으로 주지는 않는다. 경로가 고장 났다고 결론 내리기 전에 서버의 접근 정책과 클라이언트의 호스트 방화벽을 확인하라.

흐름 하나와 캡처 하나로 확인하라

일반적인 도달성 시험이 아니라 연결 하나로 경로를 증명하라. 같은 흐름을 양쪽 끝에서, 즉 서비스에 도착하는 요청과 그것을 떠나는 응답을 관찰하라.

tcpdump -ni any host 10.90.0.25 and port 443

수정 전에는 캡처가 응답이 라우팅하지 않을 게이트웨이로 나가는 모습을 보여 준다. 수정 후에는 응답이 서버로 나가고 흐름이 완료된다. 그다음 아직 덮지 못한 풀이 일주일 뒤가 아니라 지금 드러나도록, 두 번째 클라이언트 주소에 대해 게이트웨이가 쓸 경로를 확인하라.

이 일을 마무리하는 네 가지 점검으로 끝내라. 서비스의 출발지 주소가 의도한 모드와 맞는지, 게이트웨이가 사용 중인 모든 풀에 경로를 갖는지, 포워딩과 필터가 양방향을 허용하는지, 실제 흐름 하나가 처음부터 끝까지 완료되는지를 확인하면 되며, Access Server 라우팅 자주 묻는 질문은 설치된 릴리스에 대해 같은 원칙을 밝히는데 그 지원되는 구성 인터페이스는 오래된 안내서와 다를 수 있다.