VPN Pi con varios encamiñadores: pon cada ruta no dispositivo que decide
Un encamiñador descendente engade unha segunda subrede de clientes, e cada un dos catro dispositivos posúe unha decisión. Pon as rutas, comproba a orixe e despois proba desde un cliente real.
Pór unha caixa Wi-Fi detrás do Pi converte unha decisión de encamiñamento en catro, e o plan rompe cando as catro se toman nun só dispositivo. A primeira pregunta non é que ruta engadir. É se a caixa nova fai ponte ou encamiña, porque esa resposta decide cantas subredes existen e que dispositivos deben aprender sobre elas. Escolle primeiro o modelo de conexión; cada ruta derívase del.
Ponte ou encamiñamento: a escolla que fixa o reconto
Unha ponte pon os clientes novos na mesma subrede que o Pi xa serve. Unha subrede, unha autoridade DHCP e ningún traspaso que encamiñar. Esta é a disposición máis simple e a correcta cando unha rede de clientes separada nunca foi un requisito. Unha ligazón encamiñada é un deseño distinto: a caixa conserva a súa propia subrede, e ese prefixo debe levarse a todas partes onde vai o tráfico.
O resto deste plan conserva o encamiñador descendente e preserva os enderezos de orixe dos clientes. O obxectivo é unha rede VPN privada, non unha saída completa a internet. Escribe o modelo antes dos enderezos, porque a lista de abaixo só é un exemplo de conexión encamiñada.
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/24Quen decide que
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Cada dispositivo toma unha decisión, e ningún pode tomar a doutro por el. O Pi necesita dúas entradas, non unha, e o camiño de volta é o que a xente esquece. O tráfico reenviado chega correctamente á rede privada e despois morre á volta, porque o Pi non ten nin idea de onde vive 10.41.0.0/24. Iso parece un problema de cortafogos e en realidade é unha ruta que falta.
O lado remoto tamén necesita a súa propia ruta. Se o servizo do extremo afastado non sabe que se pode chegar a 10.41.0.0/24 pola túa túnel, as respostas detéñense no primeiro salto que non ten resposta. Engade ambas as direccións antes de ler filtros de paquetes.
Os seguintes saltos veñen da conexión
O seguinte salto debe ser un enderezo nunha rede á que o dispositivo poida chegar de verdade. O enderezo público do par VPN non é o seguinte salto para unha subrede privada, e a rede de servizo remota non é un seguinte salto en absoluto. Unha ruta cara a unha porta de enlace inalcanzable parece correcta nunha listaxe e descarta cada paquete. Comproba que a porta de enlace responde antes de culpar o destino.
Mantén o par VPN exterior do Pi accesible a través da súa propia ruta de capa inferior. Esa entrada está separada das rutas de carga útil, e mesturalas dá un túnel que non se pode restablecer tras un cambio de camiño.
A documentación de rutas estáticas aclara a distinción entre destino e porta de enlace, aínda que cada plataforma nomea os seus menús de forma distinta. Le a documentación do dispositivo que tes diante en lugar de copiar a pantalla doutro fabricante. Os comandos de abaixo mostran a forma das entradas en 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.1Que fai a tradución á orixe
Se o encamiñador descendente xa traduce os seus clientes ao enderezo de tránsito, o Pi ve unha soa orixe traducida en lugar do enderezo propio de cada cliente. Ese é un deseño distinto do que preserva a orixe de arriba. Cambia a política baseada na orixe, o rexistro e que lado pode iniciar conexións. Ambos os deseños funcionan; responden a preguntas distintas.
Cando un servizo VPN augas arriba se nega a encamiñar de volta o prefixo de cliente, unha tradución estreita na saída do túnel do Pi pode ser unha solución legítima. Non é proba de que a ruta que falta fose innecesaria. Anota que enderezo ve realmente a rede remota e que camiño de volta resulta.
A selección de ruta, o permiso de reenvío e a tradución de orixe seguen sendo tres traballos separados. Baleirar unha cadea NAT compartida ou permitir cada interface porque un cliente por cable funciona é como unha proba que funciona se converte nun reenviador aberto.
Probalo desde unha máquina cliente
Envía unha petición desde unha máquina na LAN descendente e despois segue a súa orixe cara a fóra e de volta. Un ping lanzado polo Pi nunca exercita a ruta de volta descendente, por iso un ping correcto proba menos do que parece. Engade unha segunda proba desde un cliente por cable na propia LAN do Pi para que se poidan comparar os dous camiños. Repite ambas tras reiniciar calquera dos dispositivos.
As rutas engadidas a man e as traducións que nunca se gardaron desaparecen xuntas. Entón a parella parece unha avaría nova en lugar dun traballo inacabado.
Garda o modelo de conexión xunto coas rutas, o servizo privado permitido e calquera tradución nunha soa nota. Esa nota é a que impide que a seguinte persoa trate a ubicación sen fíos como unha cuestión de política de encamiñamento.