멀티 라우터 Pi VPN: 결정하는 기기에 각 경로를 두세요

Pi 뒤에 Wi-Fi 박스를 두면 하나의 라우팅 결정이 네 개로 늘어나고, 네 가지를 모두 한 기기에서 내리면 계획이 깨집니다. 첫 질문은 어떤 경로를 추가할지가 아닙니다. 새 박스가 브리지인지 라우팅인지이며, 그 답이 서브넷이 몇 개인지와 어떤 기기가 그것을 배워야 하는지를 정합니다. 먼저 연결 모델을 고르세요, 모든 경로는 그로부터 나오기 때문입니다.

브리지냐 라우팅이냐: 개수를 정하는 선택

브리지는 새 클라이언트를 Pi가 이미 제공하는 같은 서브넷에 둡니다. 하나의 서브넷, 하나의 DHCP 권한, 그리고 라우팅으로 넘길 인계가 없습니다. 더 단순한 구성이며 별도의 클라이언트 네트워크가 요구 사항이 아니었을 때 옳은 선택입니다. 라우팅 연결은 다른 설계이며, 박스는 자기 서브넷을 유지하고, 그 프리픽스는 트래픽이 가는 모든 곳으로 옮겨져야 합니다.

이 계획의 나머지는 다운스트림 라우터를 유지하고 클라이언트 출발지 주소를 보존합니다. 목표는 하나의 사설 VPN 네트워크이며 완전한 인터넷 출구가 아닙니다. 주소보다 먼저 모델을 적어 두세요, 아래 목록은 라우팅 연결의 한 예일 뿐이니까요.

client subnet       10.41.0.0/24
client gateway      10.41.0.1
router-to-Pi link   192.168.71.2
Pi on that link     192.168.71.1
private target      10.72.9.0/24

누가 무엇을 결정하는가

각 기기는 하나의 결정을 내리고, 어느 것도 다른 기기의 결정을 대신 내릴 수 없습니다. Pi에는 하나가 아니라 두 개의 항목이 필요하며, 사람들이 잊는 것은 돌아오는 경로입니다. 전달된 트래픽은 사설 네트워크에 올바로 도달한 뒤, Pi가 10.41.0.0/24의 위치를 전혀 모르기 때문에 돌아오는 길에서 죽습니다. 그것은 방화벽 문제처럼 보이지만 실제로는 빠진 경로입니다.

먼 쪽에도 자기 경로가 필요합니다. 먼 끝의 서비스가 10.41.0.0/24에 당신의 터널로 도달할 수 있다는 것을 모르면, 응답은 답이 없는 첫 홉에서 멈춥니다. 패킷 필터를 읽기 전에 양방향을 모두 추가하세요.

다음 홉은 연결에서 나옵니다

다음 홉은 기기가 실제로 도달할 수 있는 네트워크의 주소여야 합니다. VPN 피어의 공인 주소는 사설 서브넷의 다음 홉이 아니며, 먼 서비스 네트워크는 다음 홉이 전혀 아닙니다. 도달할 수 없는 게이트웨이로 가는 경로는 목록에서 올바르게 보이고 모든 패킷을 버립니다. 목적지를 탓하기 전에 게이트웨이가 응답하는지 확인하세요.

Pi의 외부 VPN 피어를 자체 언더레이 경로로 도달 가능하게 유지하세요. 그 항목은 페이로드 경로와 별개이며, 둘을 섞으면 경로가 바뀐 뒤 다시 세울 수 없는 터널이 됩니다.

정적 경로 문서는 모든 플랫폼이 메뉴 이름을 다르게 붙여도 목적지와 게이트웨이의 구분을 분명히 합니다. 다른 공급업체의 화면을 복사하지 말고 눈앞의 기기 문서를 읽으세요. 아래 명령은 Linux에서 항목의 모양을 보여 줍니다.

# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1

변환이 출발지에 하는 일

다운스트림 라우터가 이미 클라이언트를 통과 주소로 변환한다면, Pi는 각 클라이언트의 고유 주소 대신 변환된 출발지 하나를 봅니다. 이것은 위의 출발지 보존 설계와 다른 설계입니다. 출발지 기반 정책, 기록, 어느 쪽이 연결을 시작할 수 있는지가 바뀝니다. 두 설계 모두 동작합니다, 서로 다른 질문에 답하기 때문입니다.

업스트림 VPN 서비스가 클라이언트 프리픽스를 되돌려 라우팅하기를 거부할 때, Pi 터널 출구에서의 좁은 변환은 정당한 임시 우회책이 될 수 있습니다. 그것은 빠진 경로가 불필요했다는 증거가 아닙니다. 먼 네트워크가 실제로 어느 주소를 보는지와 어떤 귀환 경로가 생기는지 기록하세요.

경로 선택, 전달 허가, 출발지 변환은 세 가지 별개의 일로 남습니다. 유선 클라이언트 하나가 동작한다고 공유 NAT 체인을 비우거나 모든 인터페이스를 허용하는 것은 동작하는 시험을 열린 포워더로 만드는 방법입니다.

클라이언트 머신에서 증명하기

다운스트림 LAN의 머신에서 요청을 보내고, 그 출발지를 밖으로 그리고 돌아오는 길까지 따라가세요. Pi가 보내는 ping은 다운스트림 귀환 경로를 결코 거치지 않으므로, 성공한 ping은 보이는 것보다 적게 증명합니다. Pi 자체 LAN의 유선 클라이언트에서 두 번째 시험을 추가해 두 경로를 비교할 수 있게 하세요. 어느 기기든 재부팅한 뒤 둘 다 반복하세요.

손으로 추가한 경로와 저장된 적 없는 변환은 함께 사라집니다. 그러면 그 짝은 미완성 작업이 아니라 새 결함처럼 보입니다.

연결 모델을 경로, 허용된 사설 서비스, 모든 변환과 함께 한 메모에 저장하세요. 그 메모가 다음 사람이 무선 배치를 라우팅 정책 문제로 다루지 않게 막습니다.