VPN과 집 LAN이 같은 서브넷을 쓸 때: 먼저 경로를 따라가세요
두 어댑터가 모두 192.168.1.0/24를 주장하고 경로는 하나만 이깁니다. 번호를 다시 매기거나 DNS를 탓하기 전에 어댑터 목록, 이긴 경로, 돌아오는 길을 따라가세요.
사무실 VPN에 접속하면 트레이 아이콘이 초록색이 되고 인트라넷이 열리는데, 두 미터 떨어진 프린터가 응답을 멈춥니다. 아침까지 되던 공유 폴더가 같은 컴퓨터에서 시간 초과가 나고, 어떤 로그에도 프린터 이야기는 없습니다. 반사적으로 DNS를 의심하지만, 이름이 안 풀리는 것은 존재하지 않는 이름처럼 보일 뿐이고 문제는 주소입니다. 두 어댑터가 이제 192.168.1.0/24를 주장하고 그 프리픽스를 가질 수 있는 경로는 하나뿐입니다, 이 순서로 따라가면 무엇을 바꾸기 전에 어느 어댑터가 가져갔는지 보입니다.
증상에서 시작하고 터널에서 시작하지 않기
단서는 범위입니다. 인트라넷이 되고 로컬 장치가 모두 실패하면 터널은 정상이고 로컬 경로가 문제입니다. 로컬 장치가 되고 인트라넷이 실패하면 반대입니다. 호스트 하나만 빼고 모두 되면 양쪽에 존재하는 주소 하나를 보고 있는 것입니다.
설정을 건드리기 전에 로컬 주소 하나와 원격 주소 하나를 적어 두세요. “프린터”는 검증할 수 없지만 192.168.1.40은 검증할 수 있습니다. 그 한 걸음이 이 문제에서 가장 흔히 낭비되는 한 시간, 즉 라우팅 결정 때문에 DNS 설정을 다시 쓰는 일을 막습니다.
1단계: 프리픽스를 주장하는 두 어댑터 보기
네트워크 연결(ncpa.cpl)을 열고 두 어댑터를 나란히 읽으세요. Ethernet 어댑터는 192.168.1.50/24와 게이트웨이 192.168.1.1을 보여 줍니다. VPN 어댑터는 서버가 밀어 준 192.168.1.201/24를 보여 줍니다. 둘 다 정당하고, 둘 다 프리픽스가 on-link라고 믿으며, 스택은 그 프리픽스에 대해 경로 하나만 유지합니다.
Get-NetIPAddress -AddressFamily IPv4는 주소를 나열하고, Get-NetIPInterface | Sort-Object InterfaceMetric은 스택이 그 주소를 사용할 순서를 보여 줍니다. 그 메트릭 열이 바로 지금 읽으려는 결정이므로, 외우려 하지 말고 숫자를 적어 두세요.
DNS 이론을 싸게 반박해 보세요, Resolve-DnsName printer.office.lan은 어제와 같은 주소를 돌려줍니다. 이름은 풀렸고, 패킷이 그다음 잘못된 어댑터로 나갔습니다. 여기서 이 분이 리졸버 설정에서 반나절을 아낍니다.
2단계: 실제로 이긴 경로 읽기
Find-NetRoute -RemoteIPAddress 192.168.1.40은 그 주소에 대해 스택이 쓸 인터페이스, 다음 홉, 원본을 출력합니다. 이 출력을 힌트가 아니라 답으로 다루세요. 어느 항목이 얼마나 졌는지 보려면 route print -4가 전체 표를 보여 줍니다.
구체성이 의도를 이긴다. 밀어 넣은 192.168.0.0/25가 로컬 192.168.0.0/24를 이깁니다. 프리픽스가 더 길기 때문이고, 그래서 192.168.0.0부터 192.168.0.127까지는 터널로 나가고 위쪽 절반은 로컬로 남습니다, 오류 메시지 없이 LAN 절반이 사라지는 것은 그 표에 맞는 정상 동작입니다.
tracert -d 192.168.1.40은 표 밖에서 확인합니다. 첫 홉이 여러분의 라우터가 아니라 터널 주소라면 경로가 전부입니다. Linux에서는 같은 질문이 ip route get 192.168.1.40이고, 원본 주소와 장치를 한 줄로 보여 줍니다, 답이 tun0을 말하면 브라우저를 보는 일을 그만두세요.
3단계: 클라이언트를 탓하기 전에 돌아오는 길 확인
올바른 나가는 경로도 먼 쪽이 답할 수 없으면 실패합니다, 클라이언트 LAN에 터널로 도달하는 경우, 그 LAN의 게이트웨이가 터널 풀이 어디에 있는지 알아야 합니다. 그 라우터에서 ip route add 10.8.0.0/24 via 192.168.1.12를 실행하고, 서버에서 push “route 192.168.1.0 255.255.255.0”을 보내 클라이언트가 돌아오는 길을 알게 하세요.
첫 항목이 없으면 응답은 목적지를 떠나 기본 게이트웨이로 향하고, 그 게이트웨이는 사설 주소를 ISP로 넘겼다가 버립니다, 증상은 단방향이라 잘못 읽기 쉽습니다. 요청은 tun0에 나타나고 응답은 결코 나타나지 않습니다.
VPN 호스트의 masquerade 규칙은 그 정적 경로의 필요를 없앱니다. iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE입니다, 다만 실제 원본 주소도 가리므로 이후의 모든 로그 질문이 어려워집니다. 기본 게이트웨이가 잘못된 대상 호스트도 같은 침묵을 만들며, 최선의 경우 ICMP 리디렉트, 보통은 블랙홀이 되므로 캡처는 양쪽 끝에서 해야 합니다.
4단계: 감당할 수 있는 수리 고르기
여기에는 다섯 가지 수리가 쓰이고, 서로 대체할 수 없습니다. 어떤 명령이 가장 짧은지가 아니라 동시에 무엇이 도달 가능해야 하는지로 고르세요.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
메트릭은 값싼 선택지이고 사람들이 가장 먼저 손을 대는 것입니다. 변경은 인터페이스에 적용되므로 터널이 올라와 있는 동안 작동하고, 잊어버릴 셸이 아니라 클라이언트 옆 스크립트에 들어가야 합니다. 같은 주소에 두 네트워크에서 동시에 접근하게 할 수는 없고, 그 한계가 나머지를 표 아래로 보냅니다.
집 LAN 번호 다시 매기기를 10.10.0.0/24로 하는 것이 깔끔한 해법입니다, DHCP 임대 갱신 한 번에 예전 대역을 언급하는 예약, 프린터 큐, 하드코딩된 주소를 함께 고칩니다. 사무실 쪽 번호를 다시 매기는 것은 보통 여러분의 결정이 아닙니다, IPv6가 양쪽 네트워크에 있으면 충돌이 완전히 사라집니다. 기억하기 쉬운 무언가 대신 fd00::/8의 고유 로컬 프리픽스를 쓰고, 응용 프로그램은 ping이 아니라 TCP로 시험하세요, ICMP가 통해도 서비스가 안 될 수 있습니다.
OpenVPN 자체의 변환 옵션은 최후의 수단이며 서버에서 클라이언트별 디렉터리 항목으로 밀어 넣습니다. 옵션 이름 뒤에 네 개의 매개변수, 즉 방향, 네트워크, 넷마스크, 별칭을 받고 별칭은 선택이 아닙니다, push "route 192.168.2.0 255.255.255.0"과 push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0"입니다. 네트워크와 마스크는 클라이언트가 보는 대역(192.168.2.0/24), 별칭은 서버 쪽 실제 사무실 대역(192.168.1.0/24)이고, 밀어 넣은 경로가 그 보이는 대역을 도달 가능하게 만듭니다. 그러면 사무실이 그 클라이언트에게 192.168.2.x로 보입니다, 매핑을 프로필에 문서화하세요. 아니면 다음 사람이 라우팅 결함으로 디버깅할 것입니다.
서비스 하나만 게시하는 것은 변환의 좁은 버전이고 OpenVPN 옵션이 전혀 필요 없습니다. VPN 호스트의 DNAT 규칙이 포트 하나를 다시 게시하므로 LAN은 주소를 그대로 두고 이미 아는 호스트 주소로 서비스에 도달합니다. 대가는 늘 그렇듯 서비스가 VPN 호스트를 원본으로 보는 것이고, 그래서 클라이언트별 로그와 역방향 조회가 의미를 잃습니다. 이것은 프린터 큐 하나나 관리 페이지 하나를 덮고, 양쪽 호스트가 서로 도달하는 것은 아닙니다.
그래도 안 될 것과 기록할 것
브로드캐스트는 라우팅된 터널을 넘지 않습니다, DLNA, UPnP, NetBIOS 탐색, Wake-on-LAN은 tun 장치가 나르지 않는 브로드캐스트나 멀티캐스트에 의존하므로 경로로 발견 문제를 고칠 수 없습니다. dev tap으로 브리지하면 세그먼트가 늘어나고 DHCP 브로드캐스트, ARP, 다른 발견 패킷도 함께 갑니다. 원격 라우터의 LAN 쪽 주소에는 route 192.168.2.1 255.255.255.255 같은 유니캐스트 호스트 경로를 선호하세요.
같은 경로에서 둘 다 192.168.1.1을 쓰는 두 라우터는 같은 문제 계열입니다. 로컬 주소가 항상 이기므로 한쪽 LAN이 이사할 때까지 먼 라우터의 페이지는 도달할 수 없습니다, 두 번째 어댑터를 추가해도 두 경우 모두 아무것도 바뀌지 않습니다.
무엇이든 편집하기 전에 증거를 기록하세요, ip route get 또는 Find-NetRoute, 문제의 주소로 ping -c 3, traceroute, 클라이언트에서 tcpdump -ni tun0 icmp, 그리고 서버에서 라우팅 표와 NAT 카운터입니다. 한 방향으로는 되고 다른 방향으로는 죽는 ping은 터널이 아니라 돌아오는 길을 가리키고, 그 하나의 구분이 위 수리 중 무엇이 정말 필요한지 결정합니다.