LAN의 모든 기기와 VPN 연결 하나를 공유하기

노트북 한 대가 터널을 들고 있고, 집의 나머지는 같은 접근을 원하며, 첫 시도는 모든 것을 연결된 기기로 향하게 하는 것이지만, 이는 VPN과 아무 관련이 없는 이유로 실패합니다. 받는 호스트가 패킷을 전달하고, 출발지를 다시 쓰고, 응답이 돌아갈 길을 찾도록 해야 합니다. 세 가지 중 하나라도 빠지면 연결된 노트북은 계속 동작하지만 다른 모든 기기는 응답을 받지 못합니다. 해결책은 라우팅 설계이지 클라이언트 설정이 아닙니다.

기기를 호스트로 향하게 하면 실패하는 이유

원격 네트워크로 향한 패킷을 받는 호스트는 누군가 그렇게 구성했든 아니든 그 순간 라우터가 됩니다. 전달은 리눅스와 윈도우에서 기본적으로 꺼져 있으며, 어떤 기능이 켜지지 않는 한 그대로입니다. 주소 변환이 중요한 이유는 원격 쪽이 응답을 어디로 보낼지 알아야 하고, 사설 LAN 주소는 원격 쪽에 아무 의미가 없기 때문입니다. 되돌아오는 경로가 세 번째 조각이며, 첫 핑이 성공한 것처럼 보일 때 사람들이 잊는 것이 바로 이것입니다.

설정을 무작위로 켰다 껐다 하지 말고 그 순서대로 진단하십시오. 빠진 조각마다 증상이 조금씩 다릅니다.

호스트에서 전달과 주소 변환 켜기

연결된 호스트에서 IPv4 전달을 켜고 LAN 트래픽을 터널 인터페이스로 변환하는 두 가지 변경이 처음 두 조각을 해결합니다.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

sysctl 값을 /etc/sysctl.d 아래 파일에 저장하고, 방화벽 프런트엔드가 사용자 지정 체인을 비울 수 있으므로 재부팅 후 masquerade 규칙을 다시 확인하십시오. 윈도우에서는 공유 기능이 두 단계를 모두 수행하지만, LAN 어댑터를 고정 서브넷으로 다시 주소 지정하고 게이트웨이를 지우기 때문에 정적 주소 지정과 포트 전달이 깨집니다. 공유가 실패했다고 결론 내리기 전에 새 주소에 있는 호스트로 가는 라우터의 경로를 복원하십시오. 그다음 두 번째 기기가 트래픽을 보내는 동안 규칙 카운터가 늘어나는지 지켜보십시오.

LAN에 재부팅을 견디는 경로를 주기

다른 기기에는 원격 프리픽스로 가는 경로가 필요하며, 이를 제공하는 두 방법은 영향 범위가 다릅니다.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

클라이언트의 기본 게이트웨이를 호스트로 향하게 하면 로컬 인쇄와 파일 공유를 포함한 모든 트래픽이 호스트를 거치므로, 호스트가 잠들면 무관한 것까지 멈춥니다. 라우터에 원격 프리픽스로 가는 특정 경로를 추가하는 편이 범위가 좁아, 터널 뒤의 목적지만 연결된 기기로 가고 LAN의 나머지는 계속 동작합니다. 위의 서브넷은 예시이므로 자신의 LAN과 터널 범위로 바꾸십시오. 어느 쪽이든, 터널을 켠 상태와 끈 상태에서 두 번째 기기로 시험하십시오.

터널을 탓하기 전에 MTU 확인하기

터널은 사용 가능한 패킷 크기를 줄이지만 두 번째 기기는 그 사실을 모릅니다. 큰 전송과 TLS 핸드셰이크가 멈추는 반면 작은 요청은 성공합니다.

ping -M do -s 1400 10.8.0.5

응답이 있다는 것은 그 크기가 단편화 없이 경로를 지난다는 뜻이고, 시간 초과는 캡슐화 오버헤드가 패킷을 터널의 MTU 밖으로 밀어냈다는 뜻입니다. 공유 인터페이스의 MTU를 낮추거나 전달하는 기기에서 최대 세그먼트 크기를 제한한 뒤 같은 시험을 반복하십시오. 로컬 실패는 터널이 아니라 LAN을 가리키므로 먼저 LAN 쪽에서 같은 크기를 시험하십시오. 나중에 공급자나 터널을 바꾸면 달라질 수 있으므로 동작하는 크기를 기록해 두십시오.

기기가 하나 더 있다면 호스트에서 공유하는 것으로 충분합니다. 집 전체라면 경로를 라우터에 두십시오. 노트북이 당신과 함께 떠난 뒤에도 접근이 유지되어야 한다면 터널 자체를 전용 게이트웨이에 두어야 합니다.