En rejsende medarbejder og et filialkontor har brug for forskellige tunneler, og det forkerte valg giver et design, der virker i et laboratorium og fejler den første mandag. Fjernadgang forbinder en enhed med en gateway. Site-to-site forbinder to gateways, der repræsenterer netværk. Tjeklisten nedenfor afgør, hvilken af dem kravet faktisk beskriver.

Hvem ringer op, og hvad står bag opkalderen

Ved fjernadgang opretter software på bærbaren eller telefonen tunnelen, og gatewayen godkender en bruger, en enhed eller begge, før den tildeler en adresse og ruter. Ved site-to-site opretter routere, firewalls eller cloud-gateways forbindelsen, og enhederne bag dem bruger almindelig routing i stedet for at køre en klient. Den forskel afgør, hvem der ejer tunnelens oppetid: en medarbejders enhed i det første tilfælde, en administreret enhed i det andet. Den afgør også, om godkendelsen beskriver en person eller et netværk.

Stop her, hvis kravet er, at hver maskine på et kontor kan nå et andet kontor uden opsætning for hver enhed. Det er site-to-site, og en bunke fjernadgangslogins er en dårlig erstatning.

Adressering og returvejen

Planlæg forskellige lokale og eksterne områder. To lokationer kan bruge samme private undernet, og designet kræver så oversættelse eller omnummerering, før routing kan være entydig. En hjemmerouter med samme område som hovedkontoret skaber det samme problem for én fjernmedarbejder. Overlap er almindeligt nok til, at kontrol af det hører til den første samtale.

Returvejen betyder lige så meget som den udgående vej. En server kan modtage en anmodning og stadig ikke have nogen rute tilbage til klientnetværket.

Dokumentér, hvilken router der kender det eksterne præfiks, især med cloud-netværk og flere gateways. Et grønt tunnelikon kan ikke svare på, om en destination har en fungerende returrute, og en ping i én retning kan heller ikke. Ved fjernadgang ejer gatewayen normalt pool-ruten; ved site-to-site skal hver mellemliggende router, der bærer præfikset, være enig. Oversættelse kan skjule en manglende rute, indtil et program, der indlejrer adresser, bryder sammen.

Internetudgang er en separat beslutning

Privat tilgængelighed kræver ikke, at tunnelen bærer offentlig browsing. Om almindelig webtrafik forlader gennem gatewayen, er en anden beslutning, truffet for hvert design og registreret i klientprofilen eller i lokationens konfiguration.

Fuld tunnel og delt tunnel er svar på det spørgsmål, ikke på spørgsmålet fjernadgang kontra site-to-site. Interne navne kræver passende DNS i begge designs, fordi en offentlig resolver ikke har noget svar på et privat kontorværtsnavn. At skubbe en resolver og at skubbe en standardrute er beslægtede indstillinger, og at ændre den ene uden den anden giver fejl, der ligner DNS-problemer.

Brug topologien til at indkredse fejlen

Én bærbar computer på farten mister adgang hos klienten, sin konto eller sit lokale netværk. En hel filial mister adgang på delte stier og gateways.

Kontrollér først tunneloprettelse, derefter ruter, derefter tilladt trafik, derefter navneopløsning, derefter programlogin, og stop ved det første trin, der fejler.ip route get 10.60.8.15 besvarer routing-spørgsmålet, før du læser en enkelt programlog. Krypteringsindstillinger retter ikke en tilladelsesfejl på en delt fil, og en fungerende ping beviser ikke, at et program er autoriseret. At holde rækkefølgen fast forhindrer de tilfældige konfigurationsændringer, der gør én fejl til tre.

Endelig skal du holde definitionerne klare, når du læser leverandørmateriale: en kommerciel internetudgangsserver er en anden tjeneste end en virksomheds private gateway og giver ingen adgang til den virksomheds netværk.

Relaterede artikler