OpenVPN redirect-gateway: 각 플래그가 경로에 하는 일

프로필에 redirect-gateway를 넣고 연결하면, 아무도 두 번 읽지 않는 플래그에 따라 컴퓨터의 기본 경로가 사라지거나, 둘로 나뉘거나, 원래 있던 자리에 그대로 남을 수 있다. 이 옵션은 라우팅 상태만 바꾸고 다른 것은 바꾸지 않으므로, 무엇을 했는지에 대한 믿을 만한 증거는 연결 후 클라이언트가 설치한 표뿐이다. 다음은 연결 후의 표, 터널 자체를 살아 있게 유지하는 경로, 그리고 이 지시문이 결코 덮는다고 주장하지 않는 IPv6 트래픽이다. 모든 단계는 터널이 올라와 있는 동안 클라이언트에서 실행할 수 있는 명령이다.

각 플래그가 기본 경로에 하는 일

플래그가 하나도 없으면 이 옵션은 평범한 기본 경로를 제거하고 그 자리에 터널을 놓는다. 그래서 연결이 살아 있는 동안 옛 게이트웨이는 표에서 사라진다. def1을 더하면 그 기본 경로가 목록에 남고, 대신 두 개의 더 좁은 경로가 일을 한다. bypass-dhcp를 더하면 DHCP 경로도 살아남는데, 클라이언트가 여전히 로컬 DHCP 서버에 닿아야 하는 네트워크에서는 이 점이 중요하다. OpenVPN 2.6 설명서 페이지의 플래그 목록은 한 번 읽기에 충분히 짧고, 각 항목은 표에 남는 경로를 바꾼다.

밀어 넣은 옵션도 도착하면 같은 방식으로 동작하므로, 클라이언트 프로필에는 아무것도 없는데 표는 완전히 리디렉션된 것처럼 보일 수 있다. 이것은 정상으로, 서버가 플래그를 보냈고, 클라이언트가 그것을 적용했으며, 로컬 파일은 그 지시문을 언급하지 않았다. 밀어 넣기가 아무것도 하지 않는 것처럼 보일 때는 끌어온 옵션을 받아들이거나 버리는 클라이언트 쪽 필터를 확인하라. 버려진 옵션은 어느 쪽에서도 오류를 내지 않는다.

def1은 기본 경로를 건드리지 않고 구체성으로 이긴다

두 개의 반쪽 기본 경로가 합쳐서 IPv4 공간을 덮는다. 0.0.0.0/1과 128.0.0.0/1이다. 둘 다 0.0.0.0/0보다 구체적이므로 조회는 이쪽을 우선하고, 진짜 기본 경로는 가장 덜 구체적인 일치를 요구하는 모든 것을 위해 표에 남는다.

프로필이 아니라 표를 읽어라, 어느 경우인지 보여 주는 것은 표뿐이다. 두 줄이면 구분할 수 있다:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

각 줄에서 목적지만이 아니라 인터페이스와 메트릭도 보라. 터널을 가리키는 기본 경로와 터널을 가리키는 반쪽 기본 경로 한 쌍은 같은 의도를 나타내지만, 터널이 끊길 때 다르게 실패한다. 한쪽에는 여전히 대체 경로가 남아 있기 때문이다. 두 필드를 모두 변경 기록에 적어라. 살아남은 대체 경로가 터널을 고칠 만큼 원격 세션을 오래 유지해 주는 경우도 있고, 의도가 완전한 터널이었을 때 트래픽이 새는 원인도 바로 그것이다.

터널 끝점에 계속 닿을 수 있게 하라

클라이언트에는 터널의 먼 쪽 끝으로 가는, 그 자체로는 터널을 지나지 않는 경로가 필요하다. OpenVPN은 다른 무엇을 바꾸기 전에 그 호스트 경로를 설치하며, 수동 경로 편집이나 두 번째 VPN 클라이언트가 그것을 없앨 수 있다. 그 뒤의 증상은 연결되었다고 보고한 다음 아무것도 통과시키지 않는 연결이다.

터널이 올라와 있는 동안 커널에 끝점 주소에 어떤 인터페이스를 쓸지 물어라. 답은 물리 인터페이스와 그 게이트웨이를 지목해야 하며, 결코 tun0이어서는 안 된다:

ip route get 198.51.100.20

그 조회가 터널 장치를 돌려주면 터널이 자기 전송을 직접 나르고 있다는 뜻이며, 패킷이 밖으로 나가야 하는 순간 무너진다. 로컬 프리픽스, 두 번째 어댑터, 정책 기반 라우팅이 여기서도 중요하다. 그래서 깨끗한 노트북에서 되는 리디렉션이 관리 인터페이스와 기본 경로 두 개를 가진 호스트에서는 실패할 수 있다. 보통은 프로필이 욕을 먹지만 실제로 일한 것은 주소 계획이다.

IPv6 트래픽은 계속 자기 표를 쓴다

IPv4를 리디렉션해도 IPv6는 그대로이며, 두 계열은 서로 다른 플래그로 바뀐다. v6 기본 경로가 동작하는 이중 스택 호스트에서는 v4 트래픽이 터널 안에 완전히 들어앉아 있는 동안 v6를 지원하는 모든 목적지가 물리 링크로 빠져나간다. 한 표에서 맞아 보이는 호스트가 다른 표에서는 새고 있다.

터널이 덮었다고 가정하지 말고 연결 후 v6 표를 확인하라. 이 지시문이 주소 계열 플래그를 두는 이유가 바로 그것이며, 그것을 빼먹은 프로필은 플랫폼이 기본으로 하는 일을 물려받는다:

ip -6 route show default
ip -6 route get 2001:db8::10

애플리케이션이 어느 인터페이스를 쓰는지 증명하라

연결된 상태는 차단이 아니고, 경로 변경은 킬 스위치가 아니다. 터널이 실패할 때 직접 트래픽이 멈춰야 한다면 그 정책은 방화벽에 살고 있으며 자체 시험이 필요하다.

프로필이 설명하는 경로가 아니라 애플리케이션이 실제로 지나는 경로를 시험하라. 먼저 경로를 물은 다음, 각 인터페이스에 차례로 요청을 묶고 먼 쪽이 무엇을 보고하는지 비교하라:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

두 요청이 같은 주소를 돌려주면 라우팅 표가 그래야 한다고 말해도 애플리케이션은 터널을 쓰지 않고 있다. 터널에 묶은 요청만 성공하면 그 목적지에서는 물리 경로가 필터링되어 있고 터널은 요청한 대로 일하고 있다. 플래그, 설치된 경로, 끝점 조회, 두 출구 결과를 변경 기록에 적어 다음 사람이 스크린숏 대신 사실을 물려받게 하라.