VPN 포트를 열어도 클라이언트는 LAN에 닿지 않는다

터널은 올라오고 클라이언트는 인증을 마치지만 게이트웨이 뒤의 LAN은 보이지 않습니다. 이것을 고치려던 규칙은 VPN 포트를 허용하며 적힌 그대로 동작합니다. 그 규칙이 다루는 대상이 게이트웨이 자신으로 향한 패킷이기 때문입니다. 게이트웨이 뒤 호스트로 가는 클라이언트 트래픽은 목적지도, 검사되는 체인도 다릅니다. 로그인 성공은 커널이 어느 체인을 보는지를 바꾸지 않습니다.

두 개의 체인, 두 개의 목적지

패킷의 운명은 어디로 가는지로 정해지고 어떻게 도착했는지로 정해지지 않습니다. 게이트웨이 주소로 가는 트래픽은 로컬로 전달되고 입력 규칙으로 평가됩니다. 게이트웨이가 앞으로 넘기는 트래픽은 포워딩 규칙으로 평가됩니다. 같은 터널 인터페이스에서 두 종류의 패킷이 모두 생기므로 한 규칙으로 두 일을 덮을 수 없습니다.

모두 한 문장으로 정리됩니다. 리스너를 허용한 것이 그 뒤 네트워크를 허용했다는 뜻은 아닙니다. 근거가 다른 두 결정이며 양쪽에 같은 인터페이스 이름이 있어도 하나가 되지 않습니다.

리스너 규칙이 실제로 허용하는 것

리스너 패킷은 VPN 프로세스에서 끝납니다. 그래야 터널이 만들어질 수 있습니다. 게이트웨이의 관리 페이지와 로컬 진단 응답도 호스트 자신의 입력 경로를 쓰므로 게이트웨이까지의 확인은 성공하고 그 뒤는 모두 실패합니다. 두 결과 모두 맞고 어느 것도 LAN 이야기가 아닙니다.

프로세스가 다른 목적지의 트래픽을 캡슐에서 꺼내면 패킷은 포워딩 경로로 들어가고 그곳에서 허가가 필요합니다. 인증 성공은 클라이언트가 누구인지를 정하고 어디로 갈 수 있는지는 정하지 않습니다. 두 질문은 주인도, 로그도, 오류 메시지도 다릅니다.

클라이언트에서 시험하고 게이트웨이에서는 절대 시험하지 않습니다

게이트웨이에서 만든 시험은 호스트 자신의 출력 경로를 따르므로 포워딩 경로가 닫혀 있어도 통과합니다. 시험은 클라이언트에서 시작하고 흐름의 양 끝을 봅니다.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

요청이 tun0에 나타나고 목적지에 아무것도 닿지 않으면 패킷은 도착 후에 버려집니다. 포워딩 규칙이나 목적지 자체의 필터가 원인입니다. tun0에 아무것도 나타나지 않으면 클라이언트가 터널로 보내지도 않는 것이며 문제는 게이트웨이 정책이 아니라 클라이언트의 라우팅입니다. 올바로 나가고 아무것도 돌아오지 않는 요청과 비교해 보십시오. 그것이 돌아오는 경로의 사례입니다.

포워딩에 필요한 것은 하나가 아니라 셋

커널 포워딩이 켜져 있어야 하고, 필터 규칙이 흐름을 받아들여야 하며, 목적지에 닿고 응답이 돌아올 경로가 있어야 합니다. 셋 중 하나가 빠지면 클라이언트가 보는 침묵은 같습니다.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

세 출력을 함께 읽습니다. 첫째가 영이면 나머지 둘은 무의미합니다. 둘째가 기본 버리기 정책이면 게이트웨이 자신의 트래픽은 도는 채로 클라이언트 패킷만 버려집니다. 셋째 출력은 리스너 규칙이 처음부터 문제가 아니었음을 보여 줍니다.

문서에서는 두 규칙 묶음을 나눠 둡니다

리스너 규칙과 포워딩하는 서비스의 규칙을 다른 줄에, 다른 주인과 이유로 적습니다. VPN 포트가 바뀌거나 새 서비스가 공개될 때 이 분리가 한 변경이 다른 쪽을 조용히 넓히는 것을 막습니다.

인증된 피어를 모두 신뢰하는 LAN 구성원으로 보지 말고 필요한 클라이언트 범위와 서비스에 좁은 규칙을 씁니다. StrongSwan의 포워딩 노트는 같은 경계의 돌아오는 경로와 변환 쪽을 설명하며 이것도 세 번째 결정입니다.

마지막으로 사용자가 거부될 때 층을 바로 잡습니다. 요청이 호스트에 닿고 애플리케이션이 계정을 거부하면 그 층에서 애플리케이션 권한을 고칩니다. 포워딩을 넓혀도 파일 공유 자격 증명이 생기지 않으며 성공적으로 접속하는 다른 모두의 접근까지 넓힙니다.