Hoe om 'n VPN-kliëntadrespoel te beplan wat pas

Begin in die poelveld op die VPN-bediener, nie in 'n sigblad nie. Wat jy daar intik, word die binne-adresruimte vir elke kliënt wat daarna verbind, en dit moet saamleef met die LAN wat daardie kliënte bereik, die geroete terreine daaragter, en watter adres die kliënt reeds by die huis het. Verbind een kliënt sodra die poel gestoor is, want daardie eerste verbinding vertel jou of die waarde in die praktyk werk. Van daar beweeg die deurloop na buite: die adres wat die kliënt ontvang het, die pad wat 'n antwoord volg, en die rekord wat jy agterlaat.

Begin by die poelveld, voordat enige kliënt verbind

Elke produk stel dit anders bloot, so vind die objek wat werklik adresse toeken. OpenVPN het 'n bedienerkant-poelrigting wat die volgende vry adres uitdeel, 'n IKEv2-gateway het 'n poelafdeling wat aan die eweknie-konfigurasie gebind is, en WireGuard het nie een nie omdat elke eweknie sy eie adres in sy konfigurasielêer dra. 'n Poelrigting en 'n per-eweknie-adres is nie uitruilbaar nie, en om die verkeerde een te redigeer mors die res van die deurloop.

Sodra jy die veld het, lys die reekse wat reeds bestaan: die kantoor-LAN, elke geroete terrein, die wolke-VPC, en enige ander poel wat nog in diens is. Oorvleueling word deur voorvoegsel-rekenkunde bepaal, nie deur of die gasheernommers bekend lyk nie, so vergelyk die samevatting met elkeen van daardie reekse. Twee reekse wat albei soos 10.x lyk, is onskadelik wanneer hul samevattings nie kruis nie en 'n ondersteuningsvoorval wanneer hulle wel kruis.

Besluit dan of die adres 'n funksie is van wie verbind of van wanneer hulle verbind. Dinamiese toekenning deel uit wat vry is, terwyl toekenning per identiteit 'n vaste adres aan 'n geloofsbrief bind. Skryf die keuse neer, want dit verander hoe 'n herverbinding later moet lyk.

Lees die adres wat die kliënt werklik ontvang het

Verbind een kliënt en lees wat die tonnel rapporteer, nie wat die poel belowe het nie. Die kliënt wys sy binne-adres in die verbindingstatus, en op Linux dra die koppelvlak dit direk.

Vergelyk daardie adres met die reeks wat jy gestoor het. As dit buite die reeks lê, kyk jy na 'n ander toekenningspad as die een wat jy geredigeer het. Kontroleer ook die voorvoegsellengte, want 'n kliënt met 'n /32 het geen skakel-eweknie nie en stuur elke bestemming deur sy verstekroete.

ip -4 addr show tun0
ip route get 192.168.50.20

In kliënt wat van 'n tuisroeteerder af met dieselfde reeks verbind, sal verbind en dan byna niks bereik. Die kliënt hou sy plaaslike roete vir daardie voorvoegsel, so die tonneladres bots met die netwerk daaragter en verkeer verlaat die verkeerde koppelvlak. Daardie geval kan nie op die bediener herstel word nie; die gedokumenteerde oplossing is om die tuisnetwerk te hernommer of 'n poelreeks te kies wat ver genoeg is dat botsings skaars bly. Teken beide die mislukking en die oplossing aan, want die helpdesk sal dit weer teëkom.

Herverbind dieselfde kliënt en kyk na die adres. 'n Dinamiese poel kan dieselfde waarde of 'n ander een teruggee, en albei is korrek, terwyl 'n poel per identiteit wat die adres verander nie die binding eerbiedig nie. Daardie kontrole neem sekondes en beslis of die modus wat jy in die eerste afdeling aangeteken het, die modus is wat geld.

Volg 'n antwoord terug vanaf die diens

Die poel werk net wanneer antwoorde daarheen kan terugreis. 'n Diens op die LAN antwoord die binne-adres, so sy gateway het 'n roete vir die poel of 'n vertaling voor die diens nodig. Wanneer 'n versoek deur die tonnel aankom en die antwoord verlaat deur 'n ander pad, laat 'n staatvolle firewall of 'n omgekeerde-pad-kontrole dit val, en die kliënt sien 'n diens wat verbind en dan hang. Plaas die poel in die roetebeplanning as een samevatbare blok eerder as om per-gasheer-roetes by te voeg.

Vertaling verander wat die res van die stelsel sien. Wanneer die bron herskryf word, is die adres in die gasheer-firewall en in die toepassinglog die vertaalde een, so 'n reël wat teen die poeladres geskryf is, pas niks, en 'n logreël kan nie na 'n kliënt herlei word nie. Die strongSwan-dokumentasie oor aanstuur dek die bedienerkant-helfte van daardie pad vir 'n IKEv2-gateway. DNS dra dieselfde beperking, want 'n naam wat na 'n adres oplos wat die kliënt nie kan bereik nie, misluk later en op 'n ander plek.

Twee kliënte, dan een herroeping

Verbind twee kliënte op dieselfde tyd en lees albei adresse. Hulle moet onderskeibaar, bruikbaar en binne die poel wees, en elkeen moet die diens bereik wat hy bedoel is om te bereik. 'n Poel wat duplikaatadresse uitdeel, wys gewoonlik hier eerder as in die eerste enkelkliënt-toets.

Herroep een geloofsbrief terwyl die ander kliënt verbind bly, en probeer dan die diens vanaf die oorblywende kliënt. 'n Herroeping wat die ander sessie versteur, dui op gedeelde toestand, meestal een geloofsbrief of een adres wat oor toestelle hergebruik word. Herverbind die herroepte kliënt en bevestig dat dit geweier word eerder as om die vrygemaakte adres te kry.

Eindig met 'n bestemming wat geweier behoort te word. 'n Kliënt wat alles bereik, is gekoppel, nie getoets nie.

Skryf die vier waardes waar die volgende verandering hulle sal vind

Die rekord is kort: die poelreeks en voorvoegsel, die toekenningsmodus, die terugpad of vertaling in gebruik, en die DNS-omvang wat vir daardie bestemmings antwoord. Sit dit langs die bedienerkonfigurasie eerder as in 'n kaartjie, en dateer dit. Enigiemand wat later een van die vier verander, het die ander drie voor hulle nodig, want 'n poelgrootteverandering breek die roete en 'n roeteverandering breek die DNS-antwoord.

Hou die eienaarskapnota daarby: die tonnelreeks behoort aan die VPN-bediener, en 'n bespreking wat in die LAN-DHCP-omvang gemaak is bespreek niks vir 'n kliënt binne die tonnel nie. Daardie enkele reël voorkom die mees algemene herwerk, waar iemand 'n bespreking byvoeg en verwag dat die tonneladres daarop sal volg.