Como planificar un conxunto de enderezos de clientes VPN que encaixe

Empece no campo do conxunto no servidor VPN, non nunha folla de cálculo. O que escriba alí convértese no espazo de enderezos interno para cada cliente que se conecte despois, e debe convivir coa LAN á que chegan eses clientes, os sitios encamiñados detrás dela e calquera enderezo que o cliente xa teña na casa. Conecte un cliente en canto se garde o conxunto, porque esa primeira conexión dille se o valor funciona na práctica. Desde alí o percorrido avanza cara a fóra: o enderezo que recibiu o cliente, o camiño que segue unha resposta e o rexistro que deixa atrás.

Empece no campo do conxunto, antes de que se conecte ningún cliente

Cada produto expón isto de forma distinta, así que atope o obxecto que realmente asigna enderezos. OpenVPN ten unha directiva de conxunto do lado do servidor que reparte o seguinte enderezo libre, unha pasarela IKEv2 ten unha sección de conxunto ligada á configuración do par, e WireGuard non ten ningunha porque cada par leva o seu propio enderezo no seu ficheiro de configuración. Unha directiva de conxunto e un enderezo por par non son intercambiables, e editar a incorrecta desperdicia o resto do percorrido.

Unha vez teña o campo, enumere os rangos que xa existen: a LAN da oficina, cada sitio encamiñado, a VPC da nube e calquera outro conxunto que siga en servizo. O solapamento decídese por aritmética de prefixo, non por se os números de host parecen familiares, así que compare o agregado con cada un deses rangos. Dous rangos que ambos parecen 10.x son inofensivos cando os seus agregados non se cortan e un incidente de soporte cando se cortan.

Despois decida se o enderezo é función de quen se conecta ou de cando se conecta. A asignación dinámica reparte o que está libre, mentres que a asignación por identidade liga un enderezo fixo a unha credencial. Anote a elección, porque cambia como debe verse unha reconexión máis adiante.

Lea o enderezo que o cliente recibiu realmente

Conecte un cliente e lea o que informa o túnel, non o que prometeu o conxunto. O cliente mostra o seu enderezo interno no estado da conexión, e en Linux a interface lévao directamente.

Compare ese enderezo co rango que gardou. Se está fóra do rango, está a ver unha ruta de asignación distinta da que editou. Comprobe tamén a lonxitude do prefixo, xa que un cliente cun /32 non ten par na ligazón e envía cada destino pola súa ruta predeterminada.

ip -4 addr show tun0
ip route get 192.168.50.20

Un cliente que se conecta desde un router doméstico que usa o mesmo rango conectarase e logo non chegará a case nada. O cliente conserva a súa ruta local para ese prefixo, así que o enderezo do túnel choca coa rede detrás del e o tráfico sae pola interface incorrecta. Ese caso non se pode reparar no servidor; o remedio documentado é renumerar a rede doméstica ou escoller un rango de conxunto o bastante remoto para que as colisións sigan a ser raras. Rexitre tanto a falla como o remedio, porque o servizo de axuda volverá atopalo.

Reconecte o mesmo cliente e observe o enderezo. Un conxunto dinámico pode devolver o mesmo valor ou un distinto e ambos son correctos, mentres que un conxunto por identidade que cambia o enderezo non está a respectar a ligazón. Ese comprobación leva segundos e resolve se o modo que anotou na primeira sección é o modo vixente.

Siga unha resposta de volta desde o servizo

O conxunto só funciona cando as respostas poden viaxar de volta cara a el. Un servizo na LAN responde ao enderezo interno, así que a súa pasarela necesita unha ruta para o conxunto ou unha tradución diante do servizo. Cando unha petición chega polo túnel e a resposta sae por un camiño distinto, unha devasa con estado ou unha comprobación de ruta inversa descártaa, e o cliente ve un servizo que se conecta e logo se colga. Poña o conxunto no deseño de encamiñamento como un único bloque resumible en lugar de engadir rutas por host.

A tradución cambia o que ve o resto do sistema. Cando se reescribe a orixe, o enderezo na devasa do host e no rexistro da aplicación é o traducido, así que unha regra escrita contra o enderezo do conxunto non coincide con nada e unha liña de rexistro non se pode rastrexar ata un cliente. A documentación de reenvío de strongSwan cobre a metade do lado do servidor dese camiño para unha pasarela IKEv2. O DNS leva a mesma restrición, porque un nome que se resolve a un enderezo que o cliente non pode alcanzar falla máis tarde e noutro lugar.

Dous clientes, logo unha revogación

Conecte dous clientes á vez e lea ambos os enderezos. Deben ser distintos, utilizables e dentro do conxunto, e cada un debe alcanzar o servizo ao que está destinado. Un conxunto que reparte enderezos duplicados adoita mostrarse aquí e non na primeira proba cun só cliente.

Revoque unha credencial mentres o outro cliente segue conectado, logo probe o servizo desde o cliente supervivente. Unha revogación que perturba a outra sesión apunta a estado compartido, moi a miúdo unha credencial ou un enderezo reutilizado entre dispositivos. Reconecte o cliente revogado e confirme que se lle denega en lugar de entregarlle o enderezo liberado.

Termine cun destino que debería ser denegado. Un cliente que alcanza todo foi conectado, non probado.

Escriba os catro valores onde os atopará o próximo cambio

O rexistro é curto: o rango e o prefixo do conxunto, o modo de asignación, o camiño de volta ou a tradución en uso e o alcance de DNS que responde por eses destinos. Póñao xunto á configuración do servidor en lugar dun tícket, e dateo. Quen cambie un dos catro máis adiante necesita os outros tres diante, porque un cambio de tamaño do conxunto rompe a ruta e un cambio de ruta rompe a resposta DNS.

Garde xunto a el a nota de propiedade: o rango do túnel pertence ao servidor VPN, e unha reserva feita no alcance DHCP da LAN non reserva nada para un cliente dentro do túnel. Esa única liña evita o retraballe máis común, no que alguén engade unha reserva e espera que o enderezo do túnel a siga.