Sådan planlægger du en adressepulje til VPN-klienter, der passer
Vælg puljen i serverfeltet, læs derefter den adresse, en klient faktisk modtager, følg svaret tilbage, og noter interval, tilstand, rute og DNS-omfang.
Start i puljefeltet på VPN-serveren, ikke i et regneark. Det, du skriver der, bliver det indre adresserum for hver klient, der forbinder bagefter, og det skal kunne eksistere sammen med det LAN, som disse klienter når, de rutede lokationer bag det og den adresse, klienten allerede har derhjemme. Forbind én klient, så snart puljen er gemt, fordi den første forbindelse fortæller dig, om værdien virker i praksis. Derfra bevæger gennemgangen sig udad: den adresse, klienten modtog, den vej et svar tager, og den registrering, du efterlader.
Start ved puljefeltet, før nogen klient forbinder
Hvert produkt viser dette forskelligt, så find det objekt, der rent faktisk tildeler adresser. OpenVPN har et server-side puljedirektiv, der uddeler den næste ledige adresse, en IKEv2-gateway har en puljesektion bundet til peer-konfigurationen, og WireGuard har ingen af delene, fordi hver peer bærer sin egen adresse i sin konfigurationsfil. Et puljedirektiv og en adresse for hver peer kan ikke udveksles, og redigering af den forkerte spilder resten af gennemgangen.
Når du har feltet, så list de intervaller, der allerede findes: kontorets LAN, hver rutet lokation, cloud-VPC'en og enhver anden pulje, der stadig er i drift. Overlap afgøres af præfiksaritmetik, ikke af om værtsnumrene ser velkendte ud, så sammenlign aggregatet med hvert af disse intervaller. To intervaller, der begge ser ud som 10.x, er harmløse, når deres aggregater ikke skærer hinanden, og en supporthændelse, når de gør.
Beslut derefter, om adressen er en funktion af, hvem der forbinder, eller af, hvornår de forbinder. Dynamisk tildeling uddeler det, der er ledigt, mens tildeling efter identitet binder en fast adresse til en legitimationsoplysning. Skriv valget ned, fordi det ændrer, hvordan en genforbindelse skal se ud senere.
Læs den adresse, klienten faktisk modtog
Forbind én klient, og læs hvad tunnelen rapporterer, ikke hvad puljen lovede. Klienten viser sin indre adresse i forbindelsesstatus, og på Linux bærer grænsefladen den direkte.
Sammenlign den adresse med det interval, du gemte. Hvis den ligger uden for intervallet, ser du på en anden tildelingsvej end den, du redigerede. Kontroller også præfikslængden, fordi en klient med en /32 ikke har nogen on-link-peer og sender hver destination gennem sin standardrute.
ip -4 addr show tun0
ip route get 192.168.50.20
En klient, der forbinder fra en hjemmerouter med samme interval, vil forbinde og derefter nå næsten intet. Klienten beholder sin lokale rute for det præfiks, så tunneladressen kolliderer med netværket bag den, og trafikken forlader den forkerte grænseflade. Det tilfælde kan ikke repareres på serveren; den dokumenterede afhjælpning er at omnummerere hjemmenetværket eller vælge et puljeinterval, der er fjernt nok til, at kollisioner forbliver sjældne. Noter både fejlen og afhjælpningen, fordi helpdesken vil møde den igen.
Genforbind den samme klient, og hold øje med adressen. En dynamisk pulje kan returnere den samme værdi eller en anden, og begge er korrekte, mens en pulje efter identitet, der ændrer adressen, ikke overholder bindingen. Den kontrol tager sekunder og afgør, om den tilstand, du noterede i første afsnit, er den gældende tilstand.
Følg et svar tilbage fra tjenesten
Puljen virker kun, når svar kan rejse tilbage til den. En tjeneste på LAN'et besvarer den indre adresse, så dens gateway har brug for en rute til puljen eller en oversættelse foran tjenesten. Når en anmodning ankommer gennem tunnelen, og svaret forlader ad en anden vej, dropper en stateful firewall eller et reverse-path-tjek det, og klienten ser en tjeneste, der forbinder og derefter hænger. Sæt puljen ind i rutningsdesignet som én blok, der kan opsummeres, i stedet for at tilføje ruter for hver vært.
Oversættelse ændrer, hvad resten af systemet ser. Når kilden omskrives, er adressen i værtsfirewallen og i applikationsloggen den oversatte, så en regel skrevet mod puljeadressen matcher intet, og en loglinje kan ikke spores tilbage til en klient. strongSwan-dokumentationen om videresendelse dækker serverhalvdelen af den vej for en IKEv2-gateway. DNS bærer samme begrænsning, fordi et navn, der opløses til en adresse, klienten ikke kan nå, fejler senere og et andet sted.
To klienter, derefter én tilbagekaldelse
Forbind to klienter samtidig, og læs begge adresser. De skal være forskellige, brugbare og inde i puljen, og hver skal nå den tjeneste, den er beregnet til. En pulje, der uddeler dubletadresser, dukker som regel op her i stedet for i den første test med én klient.
Tilbagekald én legitimationsoplysning, mens den anden klient forbliver forbundet, og prøv derefter tjenesten fra den overlevende klient. En tilbagekaldelse, der forstyrrer den anden session, peger på delt tilstand, oftest én legitimationsoplysning eller én adresse genbrugt på tværs af enheder. Genforbind den tilbagekaldte klient, og bekræft, at den afvises i stedet for at få den frigivne adresse.
Afslut med en destination, der bør afvises. En klient, der når alt, er blevet forbundet, ikke testet.
Skriv de fire værdier, hvor den næste ændring vil finde dem
Registreringen er kort: puljeintervallet og præfikset, tildelingstilstanden, returvejen eller oversættelsen i brug og det DNS-omfang, der svarer for disse destinationer. Læg den ved siden af serverkonfigurationen i stedet for i en sag, og dater den. Enhver, der senere ændrer en af de fire, har brug for de andre tre foran sig, fordi en ændring af puljestørrelsen bryder ruten, og en ruteændring bryder DNS-svaret.
Hold ejerskabsnoten sammen med den: tunnelintervallet tilhører VPN-serveren, og en reservation foretaget i LAN'ets DHCP-område reserverer intet for en klient inde i tunnelen. Den ene linje forhindrer det mest almindelige omarbejde, hvor nogen tilføjer en reservation og forventer, at tunneladressen følger den.