Kako načrtovati nabor naslovov odjemalcev VPN, ki se prilega
Izberite nabor v polju strežnika, nato preberite naslov, ki ga odjemalec dejansko prejme, sledite odgovoru nazaj in zapišite obseg, način, pot ter obseg DNS.
Začnite v polju nabora na strežniku VPN, ne v preglednici. Kar vnesete tam, postane notranji naslovni prostor za vsakega odjemalca, ki se poveže pozneje, in mora sobivati z omrežjem LAN, ki ga ti odjemalci dosežejo, z usmerjenimi lokacijami za njim in s katerim koli naslovom, ki ga odjemalec že ima doma. Povežite enega odjemalca takoj po shranitvi nabora, saj vam ta prva povezava pove, ali vrednost v praksi deluje. Od tam se sprehod premakne navzven: naslov, ki ga je odjemalec prejel, pot, po kateri gre odgovor, in zapis, ki ga pustite za sabo.
Začnite pri polju nabora, preden se poveže kateri koli odjemalec
Vsak izdelek to razkriva drugače, zato poiščite objekt, ki res dodeljuje naslove. OpenVPN ima strežniško direktivo nabora, ki izda naslednji prosti naslov, prehod IKEv2 ima razdelek nabora, vezan na konfiguracijo partnerja, WireGuard pa nima nobenega, ker vsak partner nosi svoj naslov v svoji konfiguracijski datoteki. Direktiva nabora in naslov posameznega partnerja nista zamenljiva, urejanje napačne pa zapravi preostanek sprehoda.
Ko imate polje, naštejte obsege, ki že obstajajo: pisarniško omrežje LAN, vsako usmerjeno lokacijo, oblak VPC in vsak drug nabor, ki je še v uporabi. Prekrivanje odloča aritmetika predpone, ne pa to, ali so številke gostiteljev videti znane, zato primerjajte agregat z vsakim od teh obsegov. Dva obsega, ki oba izgledata kot 10.x, sta neškodljiva, ko se njuna agregata ne sekata, in incident podpore, ko se sekata.
Nato se odločite, ali je naslov funkcija tega, kdo se poveže, ali tega, kdaj se povežejo. Dinamična dodelitev izda tisto, kar je prosto, medtem ko dodelitev po identiteti veže fiksni naslov na poverilnico. Zapišite izbiro, ker spremeni, kako mora biti pozneje videti ponovna povezava.
Preberite naslov, ki ga je odjemalec dejansko prejel
Povežite enega odjemalca in preberite, kar poroča tunel, ne kar je obljubil nabor. Odjemalec prikaže svoj notranji naslov v stanju povezave, v Linuxu pa ga vmesnik nosi neposredno.
Primerjajte ta naslov z obsegom, ki ste ga shranili. Če je zunaj obsega, gledate drugo pot dodelitve kot tisto, ki ste jo urejali. Preverite tudi dolžino predpone, ker odjemalec s /32 nima partnerja na povezavi in vsak cilj pošlje po svoji privzeti poti.
ip -4 addr show tun0
ip route get 192.168.50.20
Odjemalec, ki se poveže iz domačega usmerjevalnika z istim obsegom, se bo povezal in nato dosegel skoraj nič. Odjemalec obdrži svojo lokalno pot za to predpono, zato naslov tunela trči z omrežjem za njim in promet zapusti napačen vmesnik. Tega primera na strežniku ni mogoče popraviti; dokumentirano zdravilo je preštevilčenje domačega omrežja ali izbira dovolj oddaljenega obsega nabora, da trki ostanejo redki. Zapišite tako napako kot zdravilo, ker bo pomoč pri uporabnikih naletela nanjo znova.
Ponovno povežite isti odjemalec in opazujte naslov. Dinamični nabor lahko vrne isto vrednost ali drugo in obe sta pravilni, medtem ko nabor po identiteti, ki spremeni naslov, ne spoštuje vezave. Ta preveritev traja sekunde in odloči, ali je način, ki ste ga zapisali v prvem razdelku, veljavni način.
Sledite odgovoru nazaj od storitve
Nabor deluje le, kadar lahko odgovori potujejo nazaj do njega. Storitev v omrežju LAN odgovori na notranji naslov, zato njen prehod potrebuje pot za nabor ali prevod pred storitvijo. Ko zahteva prispe po tunelu in odgovor odide po drugi poti, ga stanjni požarni zid ali preveritev povratne poti zavrže, odjemalec pa vidi storitev, ki se poveže in nato obvisi. Postavite nabor v načrt usmerjanja kot en zaokrožljiv blok, namesto da dodajate poti za vsakega gostitelja.
Prevod spremeni, kaj vidi preostali sistem. Ko se vir prepiše, je naslov v požarnem zidu gostitelja in v dnevniku aplikacije prevedeni, zato se pravilo, napisano proti naslovu nabora, ne ujema z ničemer, vrstice v dnevniku pa ni mogoče izslediti do odjemalca. Dokumentacija strongSwan o posredovanju pokriva strežniško polovico te poti za prehod IKEv2. DNS nosi isto omejitev, ker ime, ki se razreši na naslov, ki ga odjemalec ne more doseči, odpove pozneje in drugje.
Dva odjemalca, nato en preklic
Povežite dva odjemalca hkrati in preberite oba naslova. Biti morata različna, uporabna in znotraj nabora, vsak pa mora doseči storitev, ki mu je namenjena. Nabor, ki izdaja podvojene naslove, se običajno pokaže tukaj in ne v prvem preskusu z enim odjemalcem.
Prekličite eno poverilnico, medtem ko drugi odjemalec ostane povezan, nato preizkusite storitev s preživelega odjemalca. Preklic, ki moti drugo sejo, kaže na skupno stanje, najpogosteje eno poverilnico ali en naslov, znova uporabljen med napravami. Ponovno povežite preklicanega odjemalca in potrdite, da mu je zavrnjeno, namesto da bi prejel sproščeni naslov.
Končajte s ciljem, ki bi moral biti zavrnjen. Odjemalec, ki doseže vse, je bil povezan, ne preizkušen.
Zapišite te štiri vrednosti tja, kjer jih bo našla naslednja sprememba
Zapis je kratek: obseg in predpona nabora, način dodeljevanja, povratna pot ali prevod v uporabi in obseg DNS, ki odgovarja za te cilje. Postavite ga ob konfiguracijo strežnika, ne v zahtevek, in ga datirajte. Kdor pozneje spremeni eno od štirih, potrebuje druge tri pred sabo, ker sprememba velikosti nabora zlomi pot, sprememba poti pa zlomi odgovor DNS.
Ob tem hranite opombo o lastništvu: obseg tunela pripada strežniku VPN, in rezervacija, narejena v obsegu DHCP v omrežju LAN, ne rezervira ničesar za odjemalca znotraj tunela. Ta ena vrstica prepreči najpogostejše ponovno delo, ko nekdo doda rezervacijo in pričakuje, da ji bo naslov tunela sledil.