openfortivpn이 계속 DNS를 덮어쓰나요? 진짜 소유자를 찾아보세요

연결이 올라오는 순간부터, 클라이언트가 인증하고 pppd가 협상한 뒤 무언가가 운영 체제에 DNS 설정을 기록하는 과정을 따라가 보세요. VPN이 리졸버를 바꿨다는 사실만 안다면, 그중 어느 단계가 그랬는지는 아직 모르는 것입니다. 그중 둘이 가능하며, 문서화된 pppd 통합을 쓰는 클라이언트에서는 둘이 하나의 주체처럼 보일 만큼 가깝게 움직입니다. 기록자를 지목하는 것이 첫 단계이고, 그 대체자를 고르는 것이 두 번째이며, 이는 나름의 실패 방식을 지닌 별개의 결정입니다.

아래 순서는 연결이 무엇을 바꿨는지, 어떤 스위치가 어떤 기록자를 억제하는지, 누가 넘겨받아야 하는지, 그리고 결과가 재연결을 견디는지 어떻게 확인하는지의 순으로 클라이언트를 바깥으로 따라갑니다. 각 단계는 서로 다른 흔적을 남기고, 그 흔적이 인계가 실제로 일어났는지를 알려줍니다.

연결이 실제로 무엇을 바꿨는지부터 시작하세요

평소 쓰던 명령으로 한 번 연결하고 전후의 해석을 비교하세요. systemd-resolved를 실행하는 Linux 호스트에서 resolvectl status는 링크별 DNS 서버와 검색 도메인을 출력하며, 자체 서버를 지닌 새 tun 또는 ppp 링크는 클라이언트 측 갱신의 지문입니다. macOS에서는 scutil --dns가 응용 프로그램이 참조하는 순서대로 리졸버 구성을 보여줍니다.

그것을 바뀔 것이라고 예상했던 파일과 비교하세요. 링크별 보기의 연결 범위 항목과 다시 쓰인 /etc/resolv.conf는 서로 다른 결과이며, 후자는 전혀 다른 무언가가 관리하는 심볼릭 링크일 수 있습니다. 리졸버 주소, 검색 도메인, 인터페이스 이름을 같은 순간에 기록하고, 그중 하나만 바뀌어도 다른 기록자를 가리킵니다. 그 기준선이 없으면 이후의 모든 수정은 세 구성 요소 중 무엇이 움직였는지에 대한 추측입니다.

두 스위치와 각각이 억제하는 기록자

openfortivpn은 자기가 제어할 수 있는 두 기록자를 모두 끄는 옵션 조각을 문서화하며, 각 스위치에는 매뉴얼이 같은 설정으로 취급하는 완전히 풀어 쓴 등가형이 있습니다.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns는 클라이언트가 게이트웨이에서 배운 DNS 서버를 적용하지 못하게 하고, --pppd-no-peerdns는 pppd가 피어 DNS를 시스템으로 밀어 넣지 못하게 합니다. upstream 매뉴얼 은 PPP를 통한 DNS 갱신이 클라이언트 자체의 DNS 갱신과 경쟁할 수 있다고 경고하며, 그래서 둘 중 하나를 충분하다고 보는 대신 두 스위치를 모두 조각에 넣어야 합니다.

어느 스위치도 대체 리졸버를 지목하지 않고, 네트워크 관리자나 DHCP 클라이언트, 별도의 VPN 통합이 나중에 해석을 기록하는 것을 막지도 않습니다. 두 기록자를 억제하는 것은 영역을 소유하는 것이 아니라 열어 두는 것입니다. 세 번째 구성 요소가 이미 DNS를 관리한다면 조각은 관찰할 수 있는 무엇도 바꾸지 않고, 아무것도 관리하지 않는다면 사설 이름 해석의 유일한 원천을 방금 없앤 것입니다. 그것이 유효한 배치가 되는 것은 대체 소유자를 먼저 고르고 단독으로 시험했을 때뿐입니다.

무엇이든 비활성화하기 전에 소유자를 고르세요

먼저 업무 이름에 대한 질의에 누가 응답할지 정해야 하는데, 그 선택이 이후의 모든 것을 제약하기 때문입니다. 기존 리졸버를 유지한다는 것은 사설 영역이 클라이언트가 있는 곳 어디서든 이미 도달 가능해야 한다는 뜻이고, 사무실 내부의 사설 리졸버에는 터널이 올라와도 살아남는 경로가 필요합니다. 모든 질의를 단일 내부 서비스로 보내는 것은 더 날카로운 실패 방식을 지닌 세 번째 정책이며, 그 서비스에 도달할 수 없을 때 공개 이름이 사설 이름과 함께 실패합니다.

경로 소유권은 의도적으로 분리해 둡니다. 경로 옵션은 DNS를 바꿨기 때문에 필요한 것이 아니며, 대체를 설치하지 않고 경로 설치를 끄면 방금 고른 리졸버에 도달할 수 없게 될 수 있습니다. 라우팅 테이블에서는 우연히 시험한 응용 프로그램 서브넷만이 아니라 리졸버 주소를 구체적으로 확인하세요.

해석은 파일 단위가 아니라 링크 단위로 확인하세요

범위 지정 또는 도메인별 해석이 있는 호스트에서 응용 프로그램이 실제로 무엇을 쓰는지의 목록을 단일 /etc/resolv.conf가 보여 주는 것은 아니므로, 플랫폼이 드러내는 방식으로 리졸버 상태를 읽으세요.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

연결이 올라온 뒤 사설 이름 하나와 공개 이름 하나를 질의하고, 어느 링크가 각각에 응답했는지 적어 두세요. VPN 링크가 도메인별 검색 목록을 지니는 곳에서는 사설 이름이 올바르게 해석되면서도 공개 이름은 여전히 로컬 리졸버로 갈 수 있고, 그 분리는 고장이 아니라 설계가 작동하는 것입니다. 사설 질의가 실패하면 다시 DNS를 건드리기 전에 리졸버로 가는 경로를 살펴보고, 성공하는데도 응용 프로그램이 실패한다면 그 응용 프로그램은 자체 캐시된 또는 별도로 구성된 리졸버를 읽고 있을 수 있습니다.

다시 연결하고 끊긴 상태를 확인하세요

연결을 내리고 두 질의를 반복하세요. 고른 소유자가 설치한 것은 그 소유자가 제거하거나 복원해야 하며, 침묵시킨 클라이언트가 남겨 두어서는 안 됩니다. 터널보다 오래 살아남는 낡은 링크별 항목은 더 이상 도달할 수 없는 주소로 사설 질의를 계속 보냅니다.

그다음 다시 연결해 리졸버 주소, 검색 도메인, 인터페이스라는 같은 세 값을 다시 읽으세요.

그것들이 적어 둔 정책과 맞는다면 인계는 완료되었고 VPN 클라이언트는 더 이상 기록자 중 하나가 아닙니다. 링크가 올라온 뒤 몇 초 후에 값이 되돌아간다면 다른 무언가가 아직 구성을 적용하고 있으며, 다음 단계는 플래그를 하나 더 추가하는 것이 아니라 그 구성 요소를 식별하는 것입니다. 원하는 최종 상태는 소유자 하나, 문서화된 정책 하나, 그리고 터널이 존재하기 전과 똑같이 해석하는 끊긴 호스트라는, 사건이 없는 상태입니다.