저는 Arch Linux를 실행하는 SBC를 VPN 서버(ISP NAT에서 처리하지 않고 전역적으로 액세스할 수 있는 IP 주소를 가진 유일한 장치이기 때문에)로 사용하여 세 가지 다른 네트워크를 연결합니다. Wireguard VPN 10.11.12.0/24에 연결된 192.168.0.0/24, 192.168.2.0/24 및 192.168.10.0/24입니다. 각 192.168.. 네트워크는 192.168..10 LAN 주소를 사용하여 VPN에 대한 단일 VPN "게이트웨이"(실제로 IP 전달이 "켜짐"으로 설정된 피어, 하나는 Windows 10 Home을 실행하고 다른 두 개는 Linux를 실행)를 통해 연결됩니다. 10.11.12.2-4 VPN 주소 및 해당하는 각 WAN/LAN 라우터(192.168..1)는 10.11.12.0/24 주소를 로컬 VPN "게이트웨이" 피어(192.168 ..)에 대한 고정 경로로 라우팅하도록 설정됩니다. 10)경로. 서버의 VPN 주소는 10.11.12.1입니다. 로컬 IP를 사용하여 모든 네트워크의 모든 장치에 원활하게 연결할 수 있지만, 외부 네트워크의 대부분의 시간 패킷은 공용 웹 인터페이스(프린터, 로컬 웹 서버 등)가 있는 장치를 제외한 모든 장치에서 삭제됩니다.
"형제" 네트워크의 패킷이 외부 패킷으로 삭제되지 않도록 각 VPN 게이트웨이 장치에 NAT를 설정해야 한다는 것을 이해합니다. 어떻게 하면 올바른 방법으로 이를 수행할 수 있습니까?
고쳐 쓰다:설명을 위해 이미지가 추가되었습니다. 주황색 개체는 VPN 통신, 파란색 개체(LAN 또는 WAN 통신)를 시각화합니다.
내가 192.168.0.20 시스템에 있고 192.168.10.20 장치(VPN을 통해 "형제" 네트워크 장치)에 액세스하려고 한다고 가정해 보겠습니다. 트래픽은 다음과 같습니다: 192.168.0.20 -> 192.168.0.10/10.11.12.2(LAN VPN 게이트웨이) -> 10.11.12.1(VPN 서버) -> 192.168.10.10/10.11.12.4(동위 LAN VPN 게이트웨이) -> 192.168 .10.20(목적지). 문제는 패킷의 소스 IP가 여전히 대상 네트워크 외부에 있으므로 피어 네트워크의 많은 서비스(원격 액세스가 제한된 라우터 WebUI, 시스템의 SSH 등)가 이러한 패킷을 삭제한다는 것입니다.
답변1
방법: 패킷을 따르세요
OP에서 제공한 연결 예를 사용하여 패킷의 경로를 추적하고 해당 패킷이 올바른 대상으로 계속 이동하는 데 필요한 구성 변경 사항을 추가하여 수행해야 하는 작업을 설명하겠습니다. 라우팅 및 WireGuard 구성에 대한 이러한 변경 사항은 3개 LAN 각각에서 다른 2개 LAN 및 중앙 VPN 서버로의 도달을 고려하여 동일하게 여러 번 복제되어야 합니다(총 2개 원격 LAN x 3개 LAN = 6). 연결된 3개의 LAN에서 3회(미주에 언급된 것처럼 일부 단순화가 있을 수 있음)
별도로 명시하지 않는 한 OP(VPN)에 의해 완전히 제어되는 네트워크에서는 NAT를 사용할 필요가 없습니다. 이는 연결을 방해할 수 있습니다.
모든 단계에서 패킷이 다음 홉에 도달하는지 확인하세요.
원산지 란
192.168.0.20의 시스템이 VPN을 통해 192.168.10.20에 액세스하려고 시도합니다.
- 192.168.0.10을 통해 경로를 설정하고 이 게이트웨이를 통해 패킷을 보내세요.
- 아니면 경로가 없어서 192.168.0.1로 보내거나,
- 192.168.0.10에서 192.168.10.20까지의 경로를 갖고 192.168.0.20으로 ICMP 리디렉션을 보내 해당 대상에 대해 올바른 게이트웨이를 사용하고 캐시하도록 지시하면서 수신된 첫 번째 패킷을 계속 전달하고 계속 전달합니다.
- 아니면 패킷이 ISP로 라우팅되고 조만간 인터넷 어딘가에서 삭제되거나 손실됩니다.아무것도 변하지 않으면 이렇게 된다.
OP가 쓴 것처럼, 이 작업을 수행하는 10.11.12.0/24용 라우터에 정의된 고정 경로가 이미 추가되어 있습니다. OP는 라우터에 고정 경로를 다시 추가할 수 있고 추가해야 합니다.
192.168.0.10을 게이트웨이로 사용하여 라우터의 192.168.10.0/24에 경로를 추가합니다.
리눅스 명령은 다음과 같습니다
ip route add 192.168.10.0/24 via 192.168.0.10 dev eth0선택 사항이지만 가능하면 LAN의 모든 시스템에 동일한 경로를 추가하는 것이 좋습니다(최적화되지 않은 ICMP 리디렉션을 방지하기 위해).
- 각 시스템에서 수동으로
- 또는 라우터의 DHCP를 구성하여DHCP 옵션 121+ (비표준이지만 Microsoft입니다...)DHCP 옵션 249. 이 기능을 제공하려면 일반 기성 홈 라우터보다 더 나은 것이 필요합니다.
이제 192.168.0.10에 경로를 추가하여 패킷을 중앙 VPN 서버로 라우팅할 수 있습니다.
ip route add 192.168.10.0/24 dev wg
via 10.11.12.1레이어 3 장치에서는 유용하지 않습니다. 하지만 어쨌든WireGuard에는 피어 선택을 강제하는 자체 방법도 있습니다.): 성공하려면 AllowedIPs관련(및 단일) 피어의 매개변수를 일반적으로 다음과 같이 변경해야 합니다.
AllowedIPs = 10.11.12.0/24
도착하다:
AllowedIPs = 10.11.12.0/24, 192.168.10.0/24
또는단 하나뿐이니까하나의WireGuard 피어인터페이스 에서 wg이는 대상(피어에 전송) 또는 소스(피어로부터 수신)에 관계없이 트래픽이 항상 해당 피어와 관련되어야 함을 의미합니다.
AllowedIPs = 0.0.0.0/0
이는 나중에 추가 변경 없이 관련되지 않은 세 번째 LAN(192.168.2.0/24)에서도 작동합니다.
중앙 VPN 서버(SBC Arch Linux)
패킷은 중앙 VPN 서버의 wg인터페이스에 도착합니다(보다 정확하게는 먼저 WireGuard가 터널링 프로토콜을 수신하는 UDP 포트의 UDP 패킷으로, 그 다음에 나타날 기회가 있습니다 wg).
중앙 VPN 서버는 AllowedIPs관련 피어가 이를 통해 도달하는 소스 IP 주소와 연결되도록 WireGuard 구성, 특히 매개변수를 변경해야 합니다.
일반적으로 피어 항목을 다음으로 바꿉니다.
AllowedIPs = 10.11.12.2
그리고:
AllowedIPs = 10.11.12.2, 192.168.0.0/24
경로를 변경하지 않으면 패킷은 기본 경로를 사용하여 인터넷으로 추가 라우팅됩니다.rp_filter=1비슷한 이유로 설정됨). 여전히 중앙 VPN 서버에서 인터페이스를 통해 192.168.10.0/24에 대한 경로를 추가합니다 wg.
ip route add 192.168.10.0/24 dev wg
또한 앞서 언급한 대로 AllowedIPs올바른 WireGuard 대상 피어를 결정하는 데에도 사용됩니다 . 또한 관련 송신 피어의 항목을 바꿉니다.
AllowedIPs = 10.11.12.4
도착하다:
AllowedIPs = 10.11.12.4, 192.168.10.0/24
이제 패킷이 대상 LAN으로 라우팅됩니다.
대상 LAN
대상 LAN의 VPN 게이트웨이 10.11.12.4에서 패킷이 수신되지만 wgWireGuard 구성이 변경되지 않으면 패킷이 삭제됩니다. 노드는 이전과 같이 단일 피어가 있는 WireGuard 노드이므로 간단히 다음과 같이 말하는 것이 안전합니다.
AllowedIPs = 0.0.0.0/0
이제 패킷은 eth0에서 패킷을 수신하는 최종 노드 192.168.10.20으로 라우팅됩니다. 예를 들어 ICMP 에코 요청인 경우 노드는 이제 ICMP 에코 응답으로 응답합니다... 그리고 정확히 동일한 설명이 반전된 값으로 반복됩니다.
주소가 192.168.10.20인 시스템이 VPN을 통해 192.168.0.20에 액세스하려고 시도하는 경우:
- 192.168.10.10을 통한 경로를 갖고 이 게이트웨이를 통해 패킷을 보내십시오.
- 아니면 경로가 없어서 192.168.10.1로 보내거나,
- 192.168.10.10을 통해 192.168.0.20으로 경로를 지정하고 192.168.10.20으로 ICMP 리디렉션을 보내 해당 대상에 대해 올바른 게이트웨이를 사용하고 캐시하도록 지시하면서 수신된 첫 번째 패킷을 계속 전달하고 계속 전달합니다.
- 아니면 패킷이 ISP로 라우팅되고 조만간 인터넷 어딘가에서 삭제되거나 손실됩니다.아무것도 변하지 않으면 이렇게 된다.
[...]
이전 두 부분에서와 같이 필요한 경우 체계적으로 설정을 변경하여 이제 192.168.0.0/24와 192.168.10.0/24 사이에 연결이 설정되었습니다.NAT가 필요하지 않습니다.
마지막 LAN
LAN이 LAN0, LAN2 및 LAN10이라고 불리는 경우 LAN0에서 LAN2로, LAN10에서 LAN2로 앞뒤로 패킷을 추적하는 프로세스를 반복하면 관련된 모든 시스템(최소 4개의 VPN 서버 및 3개의 라우터)에서 모든 구성이 완료됩니다. ).
노트
3개의 LAN VPN WireGuard 서버 모두 충분한
PersistentKeepalive옵션이 필요합니다.(ISP) NAT로 인해. 이렇게 하면 그들은 언제나받다운송. 이것이 없으면 중앙 VPN 서버에 대한 터널은 다음과 같은 경우에만 실제로 설정됩니다.보내다트래픽이 없고 라우터나 ISP의 라우터가 UDP 흐름을 잊어버리면 패킷이 사라집니다. 대상 LAN 자체가 자체 터널을 설정하지 않았기 때문에 이러한 패킷은 대상 LAN에 도달하지 못할 수 있습니다. 일반적으로 에서 제안한 대로 25개 이상
man wg이며 일부 검증 테스트 후에는 그 이상입니다.PersistentKeepalive = 25중앙 VPN 서버에는 필요하지 않습니다.
단순화하다
각 사이트에서 두 개의 192.168.x.0/24 경로 대신 단일 추가 경로 192.168.0.0/16을 사용하면 잘 작동합니다. LAN의 /24는 여전히 더 일반적인 /16 경로보다 우선합니다.
중앙 VPN 서버의 경우에도 마찬가지입니다. 단일 192.168.0.0/16 경로는 3개의 /24 경로를 대체하여 인터페이스를 통해 해당 경로를 라우팅할 수 있습니다
wg. 물론 그 자체는AllowedIPs단순화할 수 없으며 각 피어에 대한 정확한 정보를 유지해야 합니다.ICMP는 노드의 로컬 방화벽에 의해 삭제되어서는 안 됩니다.
이 경우 엔드포인트가 해당 구성에서 또는 DHCP를 통해 추가 경로를 수신하지 않으면 올바른 라우팅을 위해 ICMP 리디렉션이 필요합니다.
ICMP 필수 시간이 초과되었습니다.경로 MTU 검색, VPN이 MTU를 1420으로 줄여서 TCP MSS를 줄이기 때문입니다. 그렇지 않으면 TCP 연결이 중단될 수 있습니다.
mtu 1420PMTUD 및 관련 ICMP는 이전에 표시된 다양한 경로 에 추가된 것처럼 적절한 위치(WireGuard 서버에는 필요하지 않지만 거기에도 설정할 수 있는 엔드포인트 및 라우터)에서 MTU가 1420인 경로를 지정하여 제거할 수 있습니다. 고려할 가치가 없으며 모든 경우를 다루지는 않으며(ISP가 WG의 1420 MTU를 추가로 제한하는 자체 VPN을 가지고 있다면 어떻게 될까요?) DHCP의 클래스 없는 라우팅 옵션 121은 그러한 MTU 정보를 제공하지 않는 것 같습니다.
라우터와 함께 제공되는 방화벽(있는 경우)은 너무 열정적이어서는 안 됩니다.
일부 패킷은 ICMP 리디렉션이 시작되기 전에 비대칭 라우팅을 따르고 이후에 관련 캐시가 만료되어 라우터가 단일 방향의 트래픽 부분만 볼 수 있게 하며 이는 상태 저장 방화벽에 의해 삭제될 수 있습니다(예: Linux 라우터/방화벽이 이 작업을 수행할 수 있음) TCP는 방화벽 규칙 및 설정에 따라 달라집니다.
net.netfilter.nf_conntrack_tcp_be_liberal또는net.netfilter.nf_conntrack_tcp_loose).이 시나리오에서는 향후 IP 네트워크 추가가 기존 네트워크와 충돌하지 않을 것이라고 가정합니다.
앞으로 이런 충돌이 발생한다면 NAT는 불가피할 것입니다. 1:1 NAT 사용(예: Linuxiptables'
NETMAP) 일반적으로 충돌하는 LAN은 여전히 각 원격 LAN의 노드에 대한 별도의 액세스를 허용합니다. 자세한 내용을 알아보려면 자체 Q&A가 필요합니다.