Slik planlegger du en adressepool for VPN-klienter som passer

Start i poolfeltet på VPN-serveren, ikke i et regneark. Det du skriver der, blir det indre adresserommet for hver klient som kobler til etterpå, og det må kunne sameksistere med LAN-et disse klientene når, de rutede stedene bak det og den adressen klienten allerede har hjemme. Koble til én klient så snart poolen er lagret, fordi den første forbindelsen forteller deg om verdien fungerer i praksis. Derfra beveger gjennomgangen seg utover: adressen klienten fikk, veien et svar tar, og registreringen du etterlater deg.

Start ved poolfeltet, før noen klient kobler til

Hvert produkt viser dette ulikt, så finn objektet som faktisk tildeler adresser. OpenVPN har et pool-direktiv på serversiden som deler ut neste ledige adresse, en IKEv2-gateway har en poolseksjon bundet til peer-konfigurasjonen, og WireGuard har ingen av delene fordi hver peer bærer sin egen adresse i konfigurasjonsfilen sin. Et pool-direktiv og en adresse per peer kan ikke byttes om, og å redigere feil en sløser bort resten av gjennomgangen.

Når du har feltet, list opp områdene som allerede finnes: kontor-LAN-et, hvert rutede sted, sky-VPC-en og enhver annen pool som fortsatt er i drift. Overlapp avgjøres av prefiksaritmetikk, ikke av om vertsnumrene virker kjente, så sammenlign aggregatet med hvert av disse områdene. To områder som begge ser ut som 10.x, er harmløse når aggregatene deres ikke overlapper og en støttesak når de gjør det.

Avgjør deretter om adressen er en funksjon av hvem som kobler til eller av når de kobler til. Dynamisk tildeling deler ut det som er ledig, mens tildeling per identitet binder en fast adresse til en legitimasjon. Skriv ned valget, fordi det endrer hvordan en gjenoppkobling skal se ut senere.

Les adressen klienten faktisk mottok

Koble til én klient og les det tunnelen rapporterer, ikke det poolen lovet. Klienten viser sin indre adresse i tilkoblingsstatusen, og på Linux bærer grensesnittet den direkte.

Sammenlign den adressen med området du lagret. Hvis den ligger utenfor området, ser du på en annen tildelingsvei enn den du redigerte. Kontroller også prefikslengden, fordi en klient med en /32 ikke har noen on-link-peer og sender hver destinasjon gjennom standardruten sin.

ip -4 addr show tun0
ip route get 192.168.50.20

En klient som kobler til fra en hjemmeruter med samme område, vil koble til og deretter nå nesten ingenting. Klienten beholder sin lokale rute for det prefikset, slik at tunneladressen kolliderer med nettet bak den og trafikken går ut gjennom feil grensesnitt. Det tilfellet kan ikke repareres på serveren; den dokumenterte løsningen er å omnummerere hjemmenettet eller velge et poolområde som er fjernt nok til at kollisjoner forblir sjeldne. Noter både feilen og løsningen, fordi brukerstøtten vil møte den igjen.

Koble til den samme klienten på nytt og følg med på adressen. En dynamisk pool kan returnere samme verdi eller en annen, og begge er riktige, mens en pool per identitet som endrer adressen ikke respekterer bindingen. Den kontrollen tar sekunder og avgjør om modusen du noterte i første del, er modusen som gjelder.

Følg et svar tilbake fra tjenesten

Poolen virker bare når svar kan reise tilbake til den. En tjeneste på LAN-et svarer på den indre adressen, så gatewayen dens trenger en rute for poolen eller en oversettelse foran tjenesten. Når en forespørsel kommer gjennom tunnelen og svaret forlater via en annen vei, slipper en tilstandsbasert brannmur eller en omvendt rutesjekk det, og klienten ser en tjeneste som kobler til og deretter henger. Sett poolen inn i rutingsdesignet som én blokk som kan oppsummeres, i stedet for å legge til ruter per vert.

Oversettelse endrer det resten av systemet ser. Når kilden skrives om, er adressen i vertsbrannmuren og i applikasjonsloggen den oversatte, slik at en regel skrevet mot pooladressen ikke treffer noe, og en logglinje ikke kan spores tilbake til en klient. strongSwan-dokumentasjonen om videresending dekker serverhalvdelen av den veien for en IKEv2-gateway. DNS bærer samme begrensning, fordi et navn som løses til en adresse klienten ikke kan nå, feiler senere og et annet sted.

To klienter, deretter én tilbakekalling

Koble til to klienter samtidig og les begge adressene. De må være forskjellige, brukbare og inne i poolen, og hver må nå tjenesten den er ment for. En pool som deler ut duplikatadresser, viser seg vanligvis her og ikke i den første testen med én klient.

Tilbakekall én legitimasjon mens den andre klienten forblir tilkoblet, og prøv deretter tjenesten fra klienten som overlevde. En tilbakekalling som forstyrrer den andre økten, peker på delt tilstand, oftest én legitimasjon eller én adresse gjenbrukt på tvers av enheter. Koble til den tilbakekalte klienten på nytt og bekreft at den avvises i stedet for å få den frigitte adressen.

Avslutt med en destinasjon som bør avvises. En klient som når alt, er koblet til, ikke testet.

Skriv de fire verdiene der den neste endringen vil finne dem

Registreringen er kort: poolområdet og prefikset, tildelingsmodusen, returveien eller oversettelsen i bruk og DNS-omfanget som svarer for disse destinasjonene. Legg den ved siden av serverkonfigurasjonen i stedet for i en sak, og dater den. Den som senere endrer én av de fire, trenger de andre tre foran seg, fordi en endring av poolstørrelsen bryter ruten og en ruteendring bryter DNS-svaret.

Hold eierskapsnotatet sammen med den: tunnelområdet tilhører VPN-serveren, og en reservasjon gjort i LAN-ets DHCP-område reserverer ingenting for en klient inne i tunnelen. Den ene linjen forhindrer det vanligste omarbeidet, der noen legger til en reservasjon og forventer at tunneladressen følger den.