FortiClient 전체 터널: 사무실 서브넷만 라우팅하기

터널이 올라오고 아이콘이 초록색이 되면 로컬 네트워크가 사라집니다. 프린터, NAS, 사무실 라우터가 모두 응답을 멈춥니다. FortiClient는 프로필이 요구한 대로 동작하고 있을 뿐입니다. 게이트웨이가 기본 경로를 밀어 넣었고 클라이언트가 그것을 설치했으며, 이제 모든 패킷에 터널로 들어가는 경로가 생겼습니다. 복구는 라우팅 테이블 편집과 그 뒤의 DNS 편집이며, 이 두 편집의 순서가 이 기기가 더 나은 상태로 끝날지 더 나쁜 상태로 끝날지를 결정합니다.

클라이언트가 설치한 것, 그리고 LAN이 사라진 이유

클라이언트 화면이 아니라 테이블을 읽는 것부터 시작하십시오. macOS에서는netstat -rn이 전체 테이블을 출력하고route -n get default이 현재 이기는 인터페이스와 메트릭을 알려 줍니다. Linux에서는ip route show과ip route get 8.8.8.8이 그 짝입니다. 둘 다 한 가지 질문에 답합니다. 더 구체적인 어떤 것과도 일치하지 않는 패킷을 어느 항목이 나를 것인가 하는 질문입니다.

터널 장치의 이름은 고정되어 있지 않습니다. macOS의 IKEv2 프로필은 보통 번호가 붙은utun을 보여 주고,SSL VPN클라이언트는ppp0를, OpenVPN은tun0을 보여 줍니다. 메트릭이 다른 두 개의 기본 경로가 동시에 존재할 수도 있고, 클라이언트 항목은 나타나는 순간이 아니라 다시 연결한 뒤에야 제어권을 가져올 수 있습니다. 그래서 오 분 간격으로 찍은 두 개의 테이블 덤프가 서로 다른 이야기를 할 수 있습니다.

터널 기본 경로가 먼저 사라져야 하는 이유

커널은 가장 길게 일치하는 프리픽스를 고르고, 여러 경로가 똑같이 구체적이면 메트릭이 가장 낮은 것을 고릅니다. 그래서0.0.0.0/0을 더 좋은 메트릭으로 설치하는 클라이언트는 원래 기본 경로를 지우지 않고 모든 목적지를 이깁니다. 물리적 경로가 아직 테이블에 남아 있고 여전히 장애를 설명하는 이유가 바로 이것입니다. 터널 기본 경로를 먼저 제거하면 이전 동작이 복원됩니다. 그다음에야 터널을 지나는 프리픽스 경로가 작성자가 의도한 일을 합니다.

그 단계 전에 프리픽스를 추가하는 것이 반쯤만 동작하는 기기를 만드는 실수입니다. 새 프리픽스의 트래픽은 터널을 따르고, 목록에 없는 모든 것도 터널 기본 경로를 따르므로, 아무도 추가하지 않은 서비스를 누군가 열기 전까지는 아무것도 고장 나 보이지 않습니다. 지우고, 복원하고, 그다음 추가하면 중간 상태가 예측 가능하게 유지됩니다.

macOS와 Linux에서의 순서

macOS에서는 이 순서가 터널 기본 경로를 지우고, 물리적 기본 경로를 복원하고, 사무실 프리픽스 하나를 터널로 되돌려 보냅니다. 여기에 있는 예시 인터페이스 이름은 자신의 테이블에 있는 이름으로 바꾸십시오.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

Linux에서는 같은 순서가 다른 도구를 씁니다. 기본 경로에는 LAN 게이트웨이를, 사무실 프리픽스에는 터널 장치를 지정합니다. 옛route명령도 옛 문법을 받아들이지만, 현재 문서에 맞는 형식은ip route입니다.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

경로에 장치 대신 다음 홉이 필요하면 클라이언트 출력에서 peer를 가져오십시오. 추측하면 두 가지 오류 중 하나가 나오고, 그 의미는 다릅니다. 잘못된 게이트웨이는 즉시 network unreachable을 내고, 잘못된 터널 대상은 시간 초과를 냅니다. 명령을 다시 바꾸기 전에 어느 쪽을 받았는지 읽으십시오.

프리픽스, 리졸버, 그리고 어두운 채로 남는 DMZ

하나의 프리픽스로 작업 전체를 덮는 경우는 드뭅니다. 애플리케이션 서버, 관리 네트워크, DMZ, DNS 서버 자체가 각각 다른 대역에 있을 수 있으므로 시작하기 전에 이름을 댈 수 있는 모든 대역을 나열하고, 모든 ping 옆에서 조회도 시험하십시오. 시험 도중에 발견한 목적지가 바로 변경 기록에서 빠지는 대상입니다. 주소로는 응답하지만 이름으로 실패하는 경로는 대개 라우팅 옷을 입은 리졸버 문제입니다.

리졸버는 별개의 결정입니다. 프로필이 내부 DNS 서버를 밀어 넣었다면 기본 경로를 없앨 때 그 주소가 공개 이름에 대해 도달 불가능해지거나 터널을 통해서만 도달 가능해질 수 있고, 두 상태 모두 혼란스러운 부분 결과를 냅니다. 리졸버 주소를 터널로 라우팅하거나, 도메인별 해석을 설정해 공개 조회가 로컬 리졸버를 쓰게 하십시오.

Linux SSL 클라이언트에는 알아 둘 만한 필드 특정 실패가 있습니다. 터널은 연결되고 사무실 LAN은 응답하는데, DMZ 대역 하나가 어두운 채로 남습니다. 빠진 조각은 그 대역을 터널 게이트웨이로 보내는 경로이고, 게이트웨이는 기기마다 다르므로 주소를 하드코딩하는 것이 다음 노트북이 망가지는 방식입니다. 클라이언트 상태에서 그것을 도출하고 명령을 스스로 문서화되게 유지하십시오.

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

실행하기 전에 두 값을 읽으십시오.peer은 지점 간 터널의 먼 쪽 끝이며, DMZ 경로가 필요로 하는 주소입니다. 라우팅된 터널에서는 클라이언트가 보고하는 인터페이스나 게이트웨이가 그에 해당합니다. 둘 다 나타나지 않으면 클라이언트는 가정한 모드가 아닙니다.

다음 연결 이후, 그리고 언제 로컬에서 이 작업을 그만둘지

FortiClient는 잠자기나 네트워크 변경 뒤에 다시 연결하고 프로필이 지정한 것을 다시 설치합니다. 그래서 수동 경로는 다음 연결까지만 살아남고, 바로 그 구간에서 한 번의 성공한 시험이 수정처럼 보일 수 있습니다. 밤사이에 사라지는 경로는 예상된 동작이며 새로운 결함이 아닙니다.

지속되는 답은 두 가지입니다. 연결할 때마다 수정을 다시 실행하는 스크립트는 작성자보다 오래 살 수 있는 임시방편이고, 반면게이트웨이 관리자가 주는 분할 터널 프로필이 진짜 수정입니다. 그러면 클라이언트가 작업에 필요한 대역만 설치하기 때문입니다. 두 번째를 요청하고 첫 번째는 기다리는 동안만 쓰십시오. 전체 터널을 로컬에서 분할하기 전에 동의한 정책도 확인하십시오. 원격 네트워크가 당신의 모든 트래픽을 보는 것에 의존할 수 있습니다.

점검 목록은 짧습니다. 테이블을 읽고, 터널 기본 경로를 지우고, LAN 기본 경로를 복원하고, 모든 프리픽스를 추가하고, 이름 해석을 따로 고치고, 다시 연결할 때 경로가 돌아올 것을 예상하십시오.