Si të planifikoni një pishinë adresash klientësh VPN që përshtatet

Filloni në fushën e pishinës në serverin VPN, jo në një fletëllogaritëse. Ajo që shkruani atje bëhet hapësira e brendshme e adresave për çdo klient që lidhet më pas, dhe duhet të bashkëjetojë me LAN-in që arrijnë ata klientë, me faqet e rrugëtuara pas tij dhe me çdo adresë që klienti ka tashmë në shtëpi. Lidhni një klient sapo pishina ruhet, sepse ajo lidhja e parë ju tregon nëse vlera funksionon në praktikë. Nga aty shëtitja lëviz nga jashtë: adresa që klienti mori, rruga që ndjek një përgjigje dhe shënimi që lini pas.

Filloni te fusha e pishinës, përpara se të lidhet ndonjë klient

Çdo produkt e ekspozon ndryshe, prandaj gjeni objektin që vërtet cakton adresa. OpenVPN ka një direktivë pishine në anën e serverit që jep adresën tjetër të lirë, një portë IKEv2 ka një seksion pishine të lidhur me konfigurimin e palës, dhe WireGuard nuk ka asnjërën sepse çdo palë mban adresën e vet në skedarin e konfigurimit. Një direktivë pishine dhe një adresë për palë nuk janë të këmbyeshme, dhe redaktimi i asaj të gabuarës harxhon pjesën tjetër të shëtitjes.

Kur ta keni fushën, renditni intervalet që ekzistojnë tashmë: LAN-i i zyrës, çdo faqe e rrugëtuar, VPC-ja e resë dhe çdo pishinë tjetër ende në shërbim. Mbivendosja vendoset nga aritmetika e prefiksit, jo nga fakti se numrat e hosteve duken të njohur, prandaj krahasoni agregatin me secilin prej atyre intervaleve. Dy intervale që të dy duken si 10.x janë të pafajshëm kur agregatet e tyre nuk ndërpriten dhe një incident mbështetjeje kur ndërpriten.

Më pas vendosni nëse adresa është funksion i kush lidhet apo i kur lidhen. Caktimi dinamik jep atë që është e lirë, ndërsa caktimi sipas identitetit lidh një adresë fikse me një kredenciale. Shkruani zgjedhjen, sepse ndryshon si duhet të duket një rilidhje më vonë.

Lexoni adresën që klienti mori në të vërtetë

Lidhni një klient dhe lexoni çfarë raporton tuneli, jo çfarë premtoi pishina. Klienti shfaq adresën e tij të brendshme në statusin e lidhjes, dhe në Linux ndërfaqja e mban atë drejtpërdrejt.

Krahasoni atë adresë me intervalin që ruajtët. Nëse është jashtë intervalit, po shihni një rrugë caktimi të ndryshme nga ajo që redaktuam. Kontrolloni edhe gjatësinë e prefiksit, sepse një klient me /32 nuk ka palë në lidhje dhe dërgon çdo destinacion përmes rrugës së tij të parazgjedhur.

ip -4 addr show tun0
ip route get 192.168.50.20

Një klient që lidhet nga një ruter shtëpiak që përdor të njëjtin interval do të lidhet dhe më pas nuk do të arrijë pothuajse asgjë. Klienti mban rrugën e tij lokale për atë prefiks, kështu që adresa e tunelit përplaset me rrjetin pas saj dhe trafiku del nga ndërfaqja e gabuar. Ai rast nuk mund të riparohet në server; mjekimi i dokumentuar është rinumerimi i rrjetit shtëpiak ose zgjedhja e një intervali pishine mjaft të largët që përplasjet të mbeten të rralla. Shënoni si dështimin ashtu edhe mjekimin, sepse ndihma e shpejtë do ta hasë përsëri.

Rilidhni të njëjtin klient dhe vëzhgoni adresën. Një pishinë dinamike mund të kthejë të njëjtën vlerë ose një tjetër dhe të dyja janë të sakta, ndërsa një pishinë sipas identitetit që ndryshon adresën nuk e respekton lidhjen. Ai kontroll zgjat sekonda dhe vendos nëse modaliteti që shënuat në seksionin e parë është modaliteti në fuqi.

Ndiqni një përgjigje mbrapsht nga shërbimi

Pishina funksionon vetëm kur përgjigjet mund të udhëtojnë mbrapsht drejt saj. Një shërbim në LAN përgjigjet ndaj adresës së brendshme, prandaj porta e tij ka nevojë për një rrugë për pishinën ose një përkthim përpara shërbimit. Kur një kërkesë vjen përmes tunelit dhe përgjigja del nga një rrugë tjetër, një mur zjarri me gjendje ose një kontroll rruge të kundërt e hedh poshtë, dhe klienti sheh një shërbim që lidhet dhe më pas varet. Vendosni pishinën në projektimin e rrugëtimit si një bllok i vetëm i përmbledhshëm në vend që të shtoni rrugë për çdo host.

Përkthimi ndryshon atë që sheh pjesa tjetër e sistemit. Kur burimi rishkruhet, adresa në murin e zjarrit të hostit dhe në regjistrin e aplikacionit është e përkthyera, kështu që një rregull i shkruar kundër adresës së pishinës nuk përputhet me asgjë dhe një rresht regjistri nuk mund të gjurmohet deri te një klient. Dokumentacioni i strongSwan për përcjelljen mbulon gjysmën e anës së serverit të asaj rrugë për një portë IKEv2. DNS mban të njëjtin kufizim, sepse një emër që zgjidhet në një adresë që klienti nuk mund ta arrijë dështon më vonë dhe diku tjetër.

Dy klientë, më pas një revokim

Lidhni dy klientë njëkohësisht dhe lexoni të dyja adresat. Duhet të jenë të dallueshme, të përdorshme dhe brenda pishinës, dhe secili duhet të arrijë shërbimin për të cilin është caktuar. Një pishinë që jep adresa të dyfishta zakonisht shfaqet këtu dhe jo në provën e parë me një klient.

Revokoni një kredenciale ndërsa klienti tjetër mbetet i lidhur, më pas provoni shërbimin nga klienti që mbijetoi. Një revokim që trazon sesionin tjetër tregon gjendje të përbashkët, më shpesh një kredenciale ose një adresë e ripërdorur midis pajisjeve. Rilidhni klientin e revokuar dhe konfirmoni që i refuzohet në vend që t'i jepet adresa e liruar.

Përfundoni me një destinacion që duhet të refuzohet. Një klient që arrin gjithçka është lidhur, jo provuar.

Shkruani katër vlerat atje ku do t'i gjejë ndryshimi i ardhshëm

Regjistri është i shkurtër: intervali dhe prefiksi i pishinës, modaliteti i caktimit, rruga e kthimit ose përkthimi në përdorim dhe shtrirja DNS që përgjigjet për ato destinacione. Vendoseni pranë konfigurimit të serverit dhe jo në një tiketë, dhe datoni atë. Kushdo që më vonë ndryshon njërën nga të katërtat ka nevojë për tre të tjerat përpara, sepse ndryshimi i madhësisë së pishinës thyen rrugën dhe ndryshimi i rrugës thyen përgjigjen DNS.

Mbani me të shënimin e pronësisë: intervali i tunelit i përket serverit VPN, dhe një rezervim i bërë në shtrirjen DHCP të LAN-it nuk rezervon asgjë për një klient brenda tunelit. Ai rresht i vetëm parandalon ripunën më të zakonshme, kur dikush shton një rezervim dhe pret që adresa e tunelit ta ndjekë.