Korleis planleggje ein adressepool for VPN-klientar som passar

Start i poolfeltet på VPN-tenaren, ikkje i eit rekneark. Det du skriv der, vert det indre adresserommet for kvar klient som koplar til etterpå, og det må kunne sameksistere med LAN-et desse klientane når, dei ruta stadene bak det og den adressa klienten alt har heime. Kopla til éin klient så snart poolen er lagra, fordi den første tilkoplinga fortel deg om verdien fungerer i praksis. Derfrå flyttar gjennomgangen seg utover: adressa klienten fekk, vegen eit svar tek, og registreringa du lèt att etter deg.

Start ved poolfeltet, før nokon klient koplar til

Kvart produkt viser dette ulikt, så finn objektet som faktisk tildeler adresser. OpenVPN har eit pool-direktiv på tenarsida som deler ut neste ledige adresse, ein IKEv2-gateway har ein poolseksjon bunden til peer-konfigurasjonen, og WireGuard har ingen av delane fordi kvar peer ber si eiga adresse i konfigurasjonsfila si. Eit pool-direktiv og ei adresse per peer kan ikkje bytast om, og å redigere feil ein sløser bort resten av gjennomgangen.

Når du har feltet, list opp områda som alt finst: kontor-LAN-et, kvar ruta stad, sky-VPC-en og ein kvar annan pool som framleis er i drift. Overlapp vert avgjort av prefiksaritmetikk, ikkje av om vertstala verkar kjende, så samanlikn aggregatet med kvart av desse områda. To område som begge ser ut som 10.x, er harmlause når aggregata deira ikkje overlappar og ei støttesak når dei gjer det.

Avgjer deretter om adressa er ein funksjon av kven som koplar til eller av når dei koplar til. Dynamisk tildeling deler ut det som er ledig, medan tildeling per identitet bind ei fast adresse til ein legitimasjon. Skriv ned valet, fordi det endrar korleis ei gjenoppkopling skal sjå ut seinare.

Les adressa klienten faktisk fekk

Kopla til éin klient og les det tunnelen rapporterer, ikkje det poolen lova. Klienten viser si indre adresse i tilkoplingsstatusen, og på Linux ber grensesnittet ho direkte.

Samanlikn den adressa med området du lagra. Viss ho ligg utanfor området, ser du på ein annan tildelingsveg enn den du redigerte. Kontroller òg prefikslengda, fordi ein klient med ein /32 har ingen on-link-peer og sender kvar destinasjon gjennom standardruta si.

ip -4 addr show tun0
ip route get 192.168.50.20

Ein klient som koplar til frå ein heimeruttar med same område, vil kopla til og deretter nå nesten ingenting. Klienten held på si lokale rute for det prefikset, slik at tunneladressa kolliderer med nettet bak ho og trafikken går ut gjennom feil grensesnitt. Det tilfellet kan ikkje reparerast på tenaren; den dokumenterte løysinga er å omnummerere heimenettet eller velje eit poolområde som er fjernt nok til at kollisjonar held seg sjeldne. Noter både feilen og løysinga, fordi brukarstøtta vil møte henne igjen.

Kopla til den same klienten på nytt og følg med på adressa. Ein dynamisk pool kan returnere same verdi eller ein annan, og begge er riktige, medan ein pool per identitet som endrar adressa ikkje respekterer bindinga. Den kontrollen tek sekund og avgjer om modusen du noterte i første del, er modusen som gjeld.

Følg eit svar tilbake frå tenesta

Poolen verkar berre når svar kan reise tilbake til han. Ei teneste på LAN-et svarar på den indre adressa, så gatewayen hennar treng ei rute for poolen eller ei omsetjing framfor tenesta. Når ein førespurnad kjem gjennom tunnelen og svaret forlèt via ein annan veg, slepp ein tilstandsbasert brannmur eller ein omvend rutesjekk det, og klienten ser ei teneste som koplar til og deretter heng. Set poolen inn i rutingsdesignet som éin blokk som kan oppsummerast, i staden for å leggje til ruter per vert.

Omsetjing endrar det resten av systemet ser. Når kjelda vert skriven om, er adressa i vertsbrannmuren og i applikasjonsloggen den omsette, slik at ei regel skriven mot pooladressa ikkje treff noko, og ei logglinje kan ikkje sporast tilbake til ein klient. strongSwan-dokumentasjonen om videresending dekkjer tenarsida av den vegen for ein IKEv2-gateway. DNS ber same avgrensing, fordi eit namn som løysest til ei adresse klienten ikkje kan nå, feilar seinare og ein annan stad.

To klientar, deretter éin tilbakekalling

Kopla til to klientar samstundes og les begge adressene. Dei må vere ulike, brukbare og inne i poolen, og kvar må nå tenesta ho er meint for. Ein pool som deler ut duplikatadresser, viser seg vanlegvis her og ikkje i den første testen med éin klient.

Tilbakekall éin legitimasjon medan den andre klienten er framleis tilkopla, og prøv deretter tenesta frå klienten som overlevde. Ei tilbakekalling som forstyrrar den andre økta, peikar på delt tilstand, oftast éin legitimasjon eller éi adresse gjenbrukt på tvers av einingar. Kopla til den tilbakekalla klienten på nytt og stadfest at han vert avvist i staden for å få den frigitte adressa.

Avslutt med ein destinasjon som bør avvisast. Ein klient som når alt, er kopla til, ikkje testa.

Skriv dei fire verdiane der den neste endringa vil finne dei

Registreringa er kort: poolområdet og prefikset, tildelingsmodusen, returvegen eller omsetjinga i bruk og DNS-omfanget som svarar for desse destinasjonane. Legg ho ved sida av tenarkonfigurasjonen i staden for i ei sak, og dater ho. Den som seinare endrar éin av dei fire, treng dei andre tre framom seg, fordi ei endring av poolstorleiken bryt ruta og ei ruteendring bryt DNS-svaret.

Hald eigarskapsnotatet saman med ho: tunnelområdet høyrer til VPN-tenaren, og ein reservasjon gjord i DHCP-området til LAN-et reserverer ingenting for ein klient inne i tunnelen. Den eine linja hindrar det vanlegaste omarbeidet, der nokon legg til ein reservasjon og ventar at tunneladressa følgjer han.