Paano Planuhin ang Isang Pool ng Address ng VPN Client na Angkop

Magsimula sa field ng pool sa server ng VPN, hindi sa spreadsheet. Anumang itina-type mo roon ang nagiging panloob na espasyo ng address para sa bawat kliyenteng kumokonekta pagkatapos, at kailangan itong sumabay sa LAN na naaabot ng mga kliyenteng iyon, sa mga ruta'ng site sa likod nito at sa anumang address na mayroon na ang kliyente sa bahay. Ikonekta ang isang kliyente sa sandaling ma-save ang pool, dahil ang unang koneksiyong iyon ang magsasabi kung gumagana ang halaga sa praktika. Mula roon, lumalabas ang paglalakbay: ang address na natanggap ng kliyente, ang daang tinatahak ng sagot at ang tala na iniiwan mo.

Magsimula sa field ng pool, bago kumonekta ang kahit anong kliyente

Iba-iba ang paglalahad ng bawat produkto, kaya hanapin ang bagay na talagang nagtatalaga ng address. May direktiba ng pool sa panig ng server ang OpenVPN na nagbibigay ng susunod na libreng address, may seksiyon ng pool ang gateway ng IKEv2 na nakatali sa konfigurasyon ng peer, at wala ang WireGuard ng alinman dahil dinadala ng bawat peer ang sarili nitong address sa sarili nitong file ng konfigurasyon. Hindi mapagpapalit ang direktiba ng pool at ang address bawat peer, at ang pag-edit ng mali ay nagsasayang ng natitirang paglalakbay.

Kapag mayroon ka nang field, ilista ang mga saklaw na mayroon na: ang LAN ng opisina, bawat ruta'ng site, ang VPC sa cloud at anumang iba pang pool na gumagana pa. Ang overlap ay pinagpapasyahan ng aritmetika ng prefix, hindi ng kung pamilyar ang mga numero ng host, kaya ihambing ang pinagsama sa bawat isa sa mga saklaw na iyon. Ang dalawang saklaw na parehong mukhang 10.x ay walang pinsala kapag hindi nagsasalubong ang pinagsama ng mga ito at insidente ng suporta kapag nagsalubong.

Pagkatapos, magpasya kung ang address ay function ng kung sino ang kumokonekta o ng kung kailan sila kumokonekta. Ang dinamikong pagtatalaga ay nagbibigay ng kung ano ang libre, habang ang pagtatalaga ayon sa pagkakakilanlan ay nagtatali ng fixed na address sa isang kredensiyal. Isulat ang pinili, dahil binabago nito kung ano ang dapat itsura ng muling pagkonekta sa hinaharap.

Basahin ang address na aktuwal na natanggap ng kliyente

Ikonekta ang isang kliyente at basahin ang iniuulat ng tunnel, hindi ang ipinangako ng pool. Ipinapakita ng kliyente ang panloob na address nito sa estado ng koneksiyon, at sa Linux dinadala ito ng interface nang direkta.

Ihambing ang address na iyon sa saklaw na inilaan mo. Kung wala ito sa saklaw, ibang landas ng pagtatalaga ang nakikita mo kaysa sa in-edit mo. Suriin din ang haba ng prefix, dahil ang kliyenteng may /32 ay walang peer sa link at ipinapadala ang bawat destinasyon sa default na ruta nito.

ip -4 addr show tun0
ip route get 192.168.50.20

Ang kliyenteng kumokonekta mula sa router ng bahay na gumagamit ng parehong saklaw ay makakakonekta at pagkatapos ay halos walang maaabot. Pinapanatili ng kliyente ang lokal na ruta nito para sa prefix na iyon, kaya bumangga ang address ng tunnel sa network sa likod nito at lumalabas ang trapiko sa maling interface. Ang kaso na iyon ay hindi kayang ayusin sa server; ang dokumentadong lunas ay muling pagbilang ng network sa bahay o pagpili ng saklaw ng pool na sapat ang layo upang manatiling bihira ang banggaan. Itala ang kabiguan at ang lunas, dahil muli itong makakaharap ng help desk.

Ikonekta muli ang parehong kliyente at panoorin ang address. Maaaring ibalik ng dinamikong pool ang parehong halaga o iba at pareho ang tama, habang ang pool ayon sa pagkakakilanlan na nagbabago ng address ay hindi gumagalang sa tali. Ang pagsusuring iyon ay tumatagal ng segundo at nagpapasya kung ang mode na initala mo sa unang seksiyon ang mode na umiiral.

Sundan ang sagot pabalik mula sa serbisyo

Gumagana lamang ang pool kapag kayang bumalik ng mga sagot dito. Ang serbisyo sa LAN ay sumasagot sa panloob na address, kaya kailangan ng gateway nito ng ruta para sa pool o pagsasalin sa harap ng serbisyo. Kapag dumarating ang kahilingan sa tunnel at lumalabas ang sagot sa ibang landas, itinatapon ito ng firewall na may estado o ng pagsusuri ng baliktad na landas, at nakikita ng kliyente ang serbisyong kumokonekta at pagkatapos ay bumabitin. Ilagay ang pool sa disenyo ng ruta bilang isang blokeng maisasama sa buod sa halip na magdagdag ng ruta bawat host.

Binabago ng pagsasalin ang nakikita ng natitirang sistema. Kapag muling isinulat ang pinagmulan, ang address sa firewall ng host at sa log ng aplikasyon ay ang isinalin, kaya ang tuntuning isinulat laban sa address ng pool ay hindi tumutugma sa anuman at ang linya ng log ay hindi masusubaybayan pabalik sa isang kliyente. Sinasaklaw ng dokumentasyon ng strongSwan sa pagpapasa ang kalahati sa panig ng server ng landas na iyon para sa gateway ng IKEv2. Dinadala ng DNS ang parehong hadlang, dahil ang pangalang nagsasalin sa address na hindi kayang maabot ng kliyente ay nabibigo mamaya at sa ibang lugar.

Dalawang kliyente, pagkatapos isang pagbawi

Ikonekta ang dalawang kliyente nang sabay at basahin ang parehong address. Dapat silang magkaiba, magagamit at nasa loob ng pool, at bawat isa ay dapat umabot sa serbisyong para sa kanya. Ang pool na nagbibigay ng doble na address ay karaniwang lumilitaw dito at hindi sa unang pagsubok na isang kliyente.

Bawiin ang isang kredensiyal habang nakakonekta pa ang isa pang kliyente, pagkatapos subukan ang serbisyo mula sa natirang kliyente. Ang pagbawing nakakaabala sa isa pang sesiyon ay tumutukoy sa pinagsasaluhang estado, kadalasan isang kredensiyal o isang address na ginagamit muli sa iba't ibang device. Ikonekta muli ang binawing kliyente at tiyakin na tinatanggihan ito sa halip na ibigay ang pinalayang address.

Tapusin sa isang destinasyong dapat tanggihan. Ang kliyenteng umaabot sa lahat ay nakakonekta, hindi nasubukan.

Isulat ang apat na halaga sa lugar kung saan ito matatagpuan ng susunod na pagbabago

Ang tala ay maikli: ang saklaw at prefix ng pool, ang mode ng pagtatalaga, ang pabalik na landas o pagsasaling ginagamit at ang saklaw ng DNS na sumasagot para sa mga destinasyong iyon. Ilagay ito sa tabi ng konfigurasyon ng server sa halip na sa isang ticket, at lagyan ng petsa. Sinumang magbabago ng isa sa apat sa hinaharap ay kailangan ang tatlo pa sa harap niya, dahil ang pagbabago ng laki ng pool ay sumisira sa ruta at ang pagbabago ng ruta ay sumisira sa sagot ng DNS.

Itago ang tala ng pagmamay-ari kasama nito: ang saklaw ng tunnel ay pagmamay-ari ng server ng VPN, at ang reserbang ginawa sa saklaw ng DHCP ng LAN ay walang inilalaan para sa isang kliyente sa loob ng tunnel. Ang nag-iisang linyang iyon ay pumipigil sa pinakakaraniwang muling paggawa, kung saan may nagdaragdag ng reserba at inaasahang susunod dito ang address ng tunnel.