Fjernadgang eller site-til-site-VPN: hva passer?

En reisende ansatt og et filialkontor trenger ulike tunneler, og feil valg gir et design som virker i et laboratorium og feiler den første mandagen. Fjernadgang kobler en enhet til en gateway. Site-til-site kobler to gateways som representerer nettverk. Sjekklisten nedenfor avgjør hvilken av dem kravet faktisk beskriver.

Hvem ringer, og hva står bak den som ringer

Ved fjernadgang bygger programvare på den bærbare maskinen eller telefonen tunnelen, og gatewayen autentiserer en bruker, en enhet eller begge før den tildeler en adresse og ruter. Ved site-til-site bygger rutere, brannmurer eller skygatewayer forbindelsen, og enhetene bak dem bruker vanlig ruting i stedet for å kjøre en klient. Den forskjellen avgjør hvem som eier oppetiden til tunnelen: en ansatts enhet i det første tilfellet, en administrert enhet i det andre. Den avgjør også om autentiseringen beskriver en person eller et nettverk.

Stopp her hvis kravet er at hver maskin på ett kontor når et annet kontor uten oppsett per enhet. Det er site-til-site, og en haug med fjernadgangsinnlogginger er en dårlig erstatning.

Adressering og returveien

Planlegg atskilte lokale og eksterne områder. To steder kan bruke samme private subnett, og designet trenger da oversettelse eller omnummerering før ruting kan være entydig. En hjemmeruter med samme område som hovedkontoret skaper det samme problemet for én ekstern arbeidstaker. Overlapp er vanlig nok til at kontroll av det hører til den første samtalen.

Returveien betyr like mye som den utgående veien. En server kan motta en forespørsel og likevel ikke ha noen rute tilbake til klientnettet.

Dokumenter hvilken ruter som kjenner det eksterne prefikset, spesielt med skynettverk og flere gatewayer. Et grønt tunnelikon kan ikke svare på om en destinasjon har en fungerende returvei, og en ping i én retning kan heller ikke. Ved fjernadgang eier gatewayen vanligvis pool-ruten; ved site-til-site må hver mellomliggende ruter som bærer prefikset, være enig. Oversettelse kan skjule en manglende rute til en applikasjon som bygger inn adresser, bryter sammen.

Internett-utgang er en egen beslutning

Privat tilgjengelighet krever ikke at tunnelen bærer offentlig surfing. Om vanlig webtrafikk går ut gjennom gatewayen, er en andre beslutning, tatt per design og registrert i klientprofilen eller i konfigurasjonen for stedet.

Full tunnel og delt tunnel er svar på det spørsmålet, ikke på spørsmålet fjernadgang kontra site-til-site. Interne navn trenger passende DNS i begge design, fordi en offentlig resolver ikke har noe svar på et privat kontorvertsnavn. Å skyve en resolver og å skyve en standardrute er beslektede innstillinger, og å endre den ene uten den andre gir feil som ser ut som DNS-problemer.

Bruk topologien til å snevre inn feilen

Én bærbar maskin på farten mister tilgang hos klienten, i sin egen konto eller i sitt lokale nettverk. En hel filial mister tilgang på delte stier og gatewayer.

Kontroller først tunnelopprettelsen, deretter ruter, deretter tillatt trafikk, deretter navneoppslag, deretter innlogging i applikasjonen, og stopp ved det første trinnet som feiler.ip route get 10.60.8.15 svarer på rutingsspørsmålet før du leser én eneste applikasjonslogg. Krypteringsinnstillinger retter ikke en tillatelsesfeil på en delt fil, og en fungerende ping beviser ikke at en applikasjon er autorisert. Å holde rekkefølgen fast hindrer de tilfeldige konfigurasjonsendringene som gjør én feil til tre.

Til slutt, hold definisjonene rette når du leser leverandørmateriell: en kommersiell internett-utgangsserver er en annen tjeneste enn en bedrifts private gateway og gir ingen tilgang til den bedriftens nettverk.