Kaip suplanuoti tinkamą VPN klientų adresų baseiną

Pradėkite nuo baseino lauko VPN serveryje, o ne skaičiuoklėje. Tai, ką ten įvesite, tampa vidiniu adresų erdve kiekvienam klientui, kuris prisijungs vėliau, ir ji turi sugyventi su LAN, kurią pasiekia tie klientai, už jos esančiomis maršrutizuotomis svetainėmis ir bet kokiu adresu, kurį klientas jau turi namuose. Prijunkite vieną klientą vos tik baseinas išsaugomas, nes tas pirmasis ryšys pasako, ar reikšmė veikia praktiškai. Iš ten apžvalga juda į išorę: adresas, kurį klientas gavo, kelias, kuriuo eina atsakymas, ir įrašas, kurį paliekate.

Pradėkite nuo baseino lauko, prieš prisijungiant bet kuriam klientui

Kiekvienas produktas tai atskleidžia skirtingai, todėl raskite objektą, kuris iš tikrųjų skiria adresus. OpenVPN turi serverio pusės baseino direktyvą, kuri išduoda kitą laisvą adresą, IKEv2 šliuzas turi baseino sekciją, susietą su partnerio konfigūracija, o WireGuard neturi nė vienos, nes kiekvienas partneris savo adresą neša savo konfigūracijos faile. Baseino direktyva ir vieno partnerio adresas nėra keičiami, o neteisingo redagavimas iššvaisto likusią apžvalgą.

Gavę lauką, išvardykite diapazonus, kurie jau egzistuoja: biuro LAN, kiekvieną maršrutizuotą svetainę, debesijos VPC ir bet kurį kitą baseiną, kuris dar naudojamas. Persidengimą lemia prefikso aritmetika, o ne tai, ar prieglobos numeriai atrodo pažįstami, todėl palyginkite agregatą su kiekvienu iš tų diapazonų. Du diapazonai, kurie abu atrodo kaip 10.x, yra nekenksmingi, kai jų agregatai nesikerta, ir palaikymo incidentas, kai kertasi.

Tada nuspręskite, ar adresas yra funkcija to, kas prisijungia, ar to, kada jie prisijungia. Dinaminis priskyrimas išduoda tai, kas laisva, o priskyrimas pagal tapatybę pririša fiksuotą adresą prie kredencialų. Užsirašykite pasirinkimą, nes jis keičia, kaip vėliau turi atrodyti prisijungimas iš naujo.

Perskaitykite adresą, kurį klientas iš tikrųjų gavo

Prijunkite vieną klientą ir skaitykite, ką praneša tunelis, o ne ką žadėjo baseinas. Klientas rodo savo vidinį adresą ryšio būsenoje, o Linux sistemoje sąsaja jį neša tiesiogiai.

Palyginkite tą adresą su diapazonu, kurį išsaugojote. Jei jis už diapazono ribų, matote kitą priskyrimo kelią nei tą, kurį redagavote. Patikrinkite ir prefikso ilgį, nes klientas su /32 neturi partnerio jungtyje ir kiekvieną paskirties vietą siunčia savo numatytuoju maršrutu.

ip -4 addr show tun0
ip route get 192.168.50.20

Klientas, prisijungiantis iš namų maršrutizatoriaus, naudojančio tą patį diapazoną, prisijungs ir tada pasieks beveik nieko. Klientas išlaiko savo vietinį maršrutą tam prefiksui, todėl tunelio adresas susiduria su už jo esančiu tinklu ir srautas išeina per neteisingą sąsają. To atvejo serveryje sutaisyti negalima; dokumentuota priemonė yra pernumeruoti namų tinklą arba pasirinkti pakankamai tolimą baseino diapazoną, kad susidūrimai liktų reti. Užrašykite ir gedimą, ir priemonę, nes pagalbos tarnyba su tuo susidurs dar kartą.

Prijunkite tą patį klientą iš naujo ir stebėkite adresą. Dinaminis baseinas gali grąžinti tą pačią arba kitą reikšmę, ir abi yra teisingos, o baseinas pagal tapatybę, kuris keičia adresą, nepaiso susiejimo. Ta patikra trunka sekundes ir nusprendžia, ar režimas, kurį užrašėte pirmame skyriuje, yra galiojantis režimas.

Atsekite atsakymą atgal nuo paslaugos

Baseinas veikia tik tada, kai atsakymai gali keliauti atgal į jį. Paslauga LAN tinkle atsako į vidinį adresą, todėl jos šliuzui reikia maršruto baseinui arba vertimo prieš paslaugą. Kai užklausa ateina per tunelį, o atsakymas išeina kitu keliu, būsenos ugniasienė arba atvirkštinio kelio patikra jį numeta, ir klientas mato paslaugą, kuri prisijungia ir tada pakimba. Įtraukite baseiną į maršrutizavimo projektą kaip vieną apibendrinamą bloką, o ne pridėkite maršrutus kiekvienam prieglobai.

Vertimas keičia tai, ką mato likusi sistemos dalis. Kai šaltinis perrašomas, adresas prieglobos ugniasienėje ir programos žurnale yra išverstasis, todėl taisyklė, parašyta pagal baseino adresą, nieko neatitinka, o žurnalo eilutės negalima atsekti iki kliento. strongSwan persiuntimo dokumentacija apima serverio pusės pusę to kelio IKEv2 šliuzui. DNS turi tą patį apribojimą, nes vardas, kuris išsprendžiamas į adresą, kurio klientas negali pasiekti, nepavyksta vėliau ir kitur.

Du klientai, tada vienas atšaukimas

Prijunkite du klientus vienu metu ir perskaitykite abu adresus. Jie turi būti skirtingi, naudojami ir baseino viduje, ir kiekvienas turi pasiekti paslaugą, kuriai skirtas. Baseinas, kuris išduoda pasikartojančius adresus, paprastai pasirodo čia, o ne pirmame vieno kliento teste.

Atšaukite vienus kredencialus, kol kitas klientas lieka prisijungęs, tada išbandykite paslaugą iš išlikusio kliento. Atšaukimas, kuris trikdo kitą sesiją, rodo bendrą būseną, dažniausiai vienus kredencialus arba vieną adresą, pakartotinai naudojamą tarp įrenginių. Prijunkite atšauktą klientą iš naujo ir patvirtinkite, kad jam atsisakoma, o ne suteikiamas atlaisvintas adresas.

Užbaikite paskirties vieta, kurios turėtų būti atsisakyta. Klientas, pasiekiantis viską, buvo prijungtas, o ne išbandytas.

Užrašykite tas keturias reikšmes ten, kur jas ras kitas pakeitimas

Įrašas trumpas: baseino diapazonas ir prefiksas, priskyrimo režimas, grįžimo kelias arba naudojamas vertimas ir DNS aprėptis, kuri atsako už tas paskirties vietas. Padėkite jį šalia serverio konfigūracijos, o ne biliete, ir datuokite. Kas vėliau pakeis vieną iš keturių, tam reikės kitų trijų prieš akis, nes baseino dydžio pakeitimas sugadina maršrutą, o maršruto pakeitimas sugadina DNS atsakymą.

Laikykite šalia nuosavybės pastabą: tunelio diapazonas priklauso VPN serveriui, o rezervacija, padaryta LAN DHCP aprėptyje nieko nerezervuoja klientui tunelio viduje. Ta viena eilutė užkerta kelią dažniausiam perdarymui, kai kas nors prideda rezervaciją ir tikisi, kad tunelio adresas ją seks.