Un empregado de viaxe e unha oficina sucursal necesitan túneles distintos, e escoller o incorrecto produce un deseño que funciona no laboratorio e falla o primeiro luns. O acceso remoto une un dispositivo cunha pasarela. O de sitio a sitio une dúas pasarelas que representan redes. A lista de comprobación de abaixo resolve cal dos dous describe realmente o requisito.

Quen marca e que hai detrás de quen marca

No acceso remoto, o software do portátil ou do teléfono establece o túnel, e a pasarela autentica un usuario, un dispositivo ou ambos antes de asignar un enderezo e rutas. No sitio a sitio, os enrutadores, as devasas ou as pasarelas de nube establecen a conexión, e os dispositivos que hai detrás usan o enrutamento ordinario en lugar de executar un cliente. Esa diferenza decide quen é responsable da dispoñibilidade do túnel: o dispositivo dun empregado no primeiro caso, un equipo xestionado no segundo. Tamén decide se a autenticación describe unha persoa ou unha rede.

Detéñase aquí se o requisito é que cada máquina dunha oficina chegue a outra oficina sen configuración por dispositivo. Iso é sitio a sitio, e un montón de inicios de sesión de acceso remoto é un substituto pobre.

Enderezamento e a ruta de volta

Planifique rangos locais e remotos distintos. Dúas sedes poden usar a mesma subrede privada, e entón o deseño necesita tradución ou renumeración antes de que o enrutamento sexa inequívoco. Un enrutador doméstico que usa o mesmo rango que a central crea o mesmo problema para un traballador remoto. A superposición é abondo común como para que comprobalo pertenza á primeira conversa.

A ruta de volta importa tanto como a de saída. Un servidor pode recibir unha petición e aínda así non ter ruta de volta á rede do cliente.

Documente que enrutador coñece o prefixo remoto, sobre todo con redes de nube e varias pasarelas. Unha icona verde de túnel non pode responder se un destino ten unha ruta de volta operativa, e un ping nun só sentido tampouco. No acceso remoto a pasarela adoita posuír a ruta do grupo; no sitio a sitio, cada enrutador intermedio que transporta o prefixo debe coincidir. A tradución pode ocultar unha ruta ausente ata que se rompe unha aplicación que incorpora enderezos.

A saída a internet é unha decisión aparte

A accesibilidade privada non esixe que o túnel transporte a navegación pública. Se o tráfico web ordinario sae pola pasarela é unha segunda decisión, tomada por deseño e rexistrada no perfil do cliente ou na configuración da sede.

O túnel completo e o túnel dividido son respostas a esa pregunta, non á pregunta de acceso remoto fronte a sitio a sitio. Os nomes internos necesitan un DNS axeitado en ambos os deseños, porque un resolvedor público non ten resposta para un nome de host de oficina privada. Enviar un resolvedor e enviar unha ruta predeterminada son axustes relacionados, e cambiar un sen o outro produce fallos que parecen problemas de DNS.

Use a topoloxía para acoutar o fallo

Un portátil que se despraza perde o acceso no cliente, na súa conta ou na súa rede local. Unha sucursal enteira perde o acceso en rutas e pasarelas compartidas.

Comprobe primeiro o establecemento do túnel, logo as rutas, logo o tráfico permitido, logo a resolución de nomes, logo o inicio de sesión da aplicación, e detéñase no primeiro paso que falle.ip route get 10.60.8.15 responde á pregunta de enrutamento antes de que lea un só rexistro de aplicación. Os axustes de cifrado non arranxan un erro de permisos dun recurso compartido, e un ping que funciona non demostra que unha aplicación estea autorizada. Manter a orde fixa evita os cambios de configuración aleatorios que converten un fallo en tres.

Por último, manteña as definicións claras ao ler material de provedores: un servidor comercial de saída a internet é un servizo distinto da pasarela privada dunha empresa e non concede ningún acceso á rede desa empresa.

Artigos relacionados