Remote access of site-to-site VPN: wat past?

Een reizende medewerker en een bijkantoor hebben verschillende tunnels nodig, en de verkeerde keuze levert een ontwerp op dat in het lab werkt en op de eerste maandag faalt. Remote access verbindt een apparaat met een gateway. Site-to-site verbindt twee gateways die netwerken vertegenwoordigen. De checklist hieronder beslist welke van de twee de eis werkelijk beschrijft.

Wie belt, en wat zit er achter de beller

Bij remote access bouwt software op de laptop of telefoon de tunnel op, en de gateway authenticeert een gebruiker, een apparaat of beide voordat er een adres en routes worden toegewezen. Bij site-to-site bouwen routers, firewalls of cloudgateways de verbinding op, en apparaten daarachter gebruiken gewone routering in plaats van een client. Dat verschil bepaalt wie de beschikbaarheid van de tunnel bezit: het apparaat van een medewerker in het eerste geval, een beheerd apparaat in het tweede. Het bepaalt ook of de authenticatie een persoon of een netwerk beschrijft.

Stop hier als de eis is dat elke machine in het ene kantoor een ander kantoor bereikt zonder configuratie per apparaat. Dat is site-to-site, en een hoop remote-access-aanmeldingen is een slechte vervanging.

Adressering en de terugweg

Plan afzonderlijke lokale en externe bereiken. Twee locaties kunnen hetzelfde privé-subnet gebruiken, en dan heeft het ontwerp vertaling of hernummering nodig voordat routering ondubbelzinnig kan zijn. Een thuisrouter met hetzelfde bereik als het hoofdkantoor veroorzaakt hetzelfde probleem voor één thuiswerker. Overlap komt vaak genoeg voor dat het controleren ervan in het eerste gesprek hoort.

De terugweg is net zo belangrijk als de uitgaande weg. Een server kan een verzoek ontvangen en toch geen route terug naar het clientnetwerk hebben.

Documenteer welke router het externe prefix kent, vooral bij cloudnetwerken en meerdere gateways. Een groen tunnelpictogram kan niet beantwoorden of een bestemming een werkende terugweg heeft, en een ping in één richting ook niet. Bij remote access bezit de gateway meestal de poolroute; bij site-to-site moet elke tussenliggende router die het prefix draagt het eens zijn. Vertaling kan een ontbrekende route verbergen totdat een toepassing die adressen insluit breekt.

Internetuitgang is een aparte beslissing

Privébereikbaarheid vereist niet dat de tunnel openbaar browsen draagt. Of gewoon webverkeer via de gateway naar buiten gaat, is een tweede beslissing, per ontwerp genomen en vastgelegd in het cliëntprofiel of in de configuratie van de locatie.

Volledige tunnel en gesplitste tunnel zijn antwoorden op die vraag, niet op de vraag remote access tegenover site-to-site. Interne namen hebben in beide ontwerpen passende DNS nodig, omdat een openbare resolver geen antwoord heeft voor een naam van een privé-kantoorhost. Een resolver pushen en een standaardroute pushen zijn verwante instellingen, en het ene zonder het andere wijzigen levert storingen op die op DNS-problemen lijken.

Gebruik de topologie om de fout te beperken

Eén rondreizende laptop verliest toegang bij de client, het eigen account of het lokale netwerk. Een heel bijkantoor verliest toegang op gedeelde paden en gateways.

Controleer eerst de tunnelopbouw, dan de routes, dan het toegestane verkeer, dan de naamresolutie, dan de aanmelding bij de toepassing, en stop bij de eerste stap die faalt.ip route get 10.60.8.15 beantwoordt de routeringsvraag voordat u één applicatielog leest. Versleutelingsinstellingen verhelpen geen machtigingsfout op een gedeeld bestand, en een werkende ping bewijst niet dat een toepassing geautoriseerd is. De volgorde vast houden voorkomt de willekeurige configuratiewijzigingen die van één fout drie maken.

Houd ten slotte de definities recht als u leveranciersmateriaal leest: een commerciële internetuitgangsserver is een andere dienst dan de privégateway van een bedrijf en geeft geen toegang tot het netwerk van dat bedrijf.