Kiel plani taŭgan adresaron por VPN-klientoj

Komencu en la adresara kampo de la VPN-servilo, ne en kalkultabelo. Kion vi tajpas tie, fariĝas la interna adresspaco por ĉiu kliento, kiu poste konektiĝas, kaj ĝi devas kunekzisti kun la LAN, kiun tiuj klientoj atingas, la enkursigitaj retejoj malantaŭ ĝi, kaj ajna adreso, kiun la kliento jam havas hejme. Konektu unu klienton tuj post kiam la adresaro estas konservita, ĉar tiu unua konekto diras al vi, ĉu la valoro funkcias en praktiko. De tie la trairo moviĝas eksteren: la adreso, kiun la kliento ricevis, la vojo, kiun respondo sekvas, kaj la noto, kiun vi lasas malantaŭ vi.

Komencu ĉe la adresara kampo, antaŭ ol konektiĝos ajna kliento

Ĉiu produkto elmontras tion malsame, do trovu la objekton, kiu efektive atribuas adresojn. OpenVPN havas servilflankan adresaran direktivon, kiu disdonas la sekvan liberan adreson, IKEv2-pordego havas adresaran sekcion ligitan al la samtavola agordo, kaj WireGuard havas neniun, ĉar ĉiu samtavolo portas sian propran adreson en sia agorda dosiero. Adresara direktivo kaj adreso po samtavolo ne estas interŝanĝeblaj, kaj redakti la malĝustan malŝparas la ceteron de la trairo.

Kiam vi havas la kampon, listigu la gamojn, kiuj jam ekzistas: la oficejan LAN, ĉiun enkursigitan retejon, la nuban VPC, kaj ajnan alian adresaron ankoraŭ en uzo. Interkovro decidiĝas per prefiksa aritmetiko, ne per tio, ĉu la gastigantaj numeroj aspektas konataj, do komparu la agregaton kun ĉiu el tiuj gamoj. Du gamoj, kiuj ambaŭ aspektas kiel 10.x, estas sendanĝeraj kiam iliaj agregatoj ne intersekcas, kaj subtena okazo kiam ili intersekcas.

Poste decidu, ĉu la adreso estas funkcio de kiu konektiĝas aŭ de kiam ili konektiĝas. Dinamika atribuo disdonas tion, kio estas libera, dum atribuo laŭ identeco ligas fiksan adreson al akreditaĵo. Skribu la elekton, ĉar ĝi ŝanĝas, kiel rekonekto devus aspekti poste.

Legu la adreson, kiun la kliento efektive ricevis

Konektu unu klienton kaj legu, kion raportas la tunelo, ne kion promesis la adresaro. La kliento montras sian internan adreson en la konekta stato, kaj ĉe Linux la interfaco portas ĝin rekte.

Komparu tiun adreson kun la gamo, kiun vi konservis. Se ĝi estas ekster la gamo, vi rigardas alian atribuan vojon ol tiu, kiun vi redaktis. Kontrolu ankaŭ la prefiksan longon, ĉar kliento tenanta /32 havas neniun surligan samtavolon kaj sendas ĉiun celon tra sia implicita itinero.

ip -4 addr show tun0
ip route get 192.168.50.20

Kliento, kiu konektiĝas el hejma enkursigilo uzanta la saman gamon, konektiĝos kaj poste atingos preskaŭ nenion. La kliento konservas sian lokan itineron por tiu prefikso, do la tunela adreso kolizias kun la reto malantaŭ ĝi kaj trafiko eliras per la malĝusta interfaco. Tiu okazo ne ripareblas sur la servilo; la dokumentita rimedo estas renumerigi la hejman reton aŭ elekti adresaran gamon sufiĉe malproksiman, ke kolizioj restu maloftaj. Notu kaj la malsukceson kaj la rimedon, ĉar la helpdesko renkontos ĝin denove.

Rekonektu la saman klienton kaj observu la adreson. Dinamika adresaro povas redoni la saman valoron aŭ alian, kaj ambaŭ pravas, dum adresaro laŭ identeco, kiu ŝanĝas la adreson, ne plenumas la ligon. Tiu kontrolo daŭras sekundojn kaj decidas, ĉu la reĝimo, kiun vi notis en la unua sekcio, estas la reĝimo en efiko.

Sekvu respondon reen de la servo

La adresaro funkcias nur kiam respondoj povas vojaĝi reen al ĝi. Servo en la LAN respondas al la interna adreso, do ĝia pordego bezonas itineron por la adresaro aŭ tradukon antaŭ la servo. Kiam peto alvenas tra la tunelo kaj la respondo eliras per alia vojo, stateca fajroŝirmilo aŭ kontrolo de inversa vojo forĵetas ĝin, kaj la kliento vidas servon, kiu konektiĝas kaj poste pendas. Metu la adresaron en la itineran planon kiel unu resumeblan blokon anstataŭ aldoni itinerojn po gastiganto.

Traduko ŝanĝas tion, kion vidas la cetero de la sistemo. Kiam la fonto estas reverkita, la adreso en la gastiganta fajroŝirmilo kaj en la aplikaĵa protokolo estas la tradukita, do regulo skribita kontraŭ la adresara adreso kongruas kun nenio kaj protokola linio ne estas spurebla al kliento. La dokumentaro de strongSwan pri plusendado kovras la servilflankan duonon de tiu vojo por IKEv2-pordego. DNS portas la saman limigon, ĉar nomo, kiu solviĝas al adreso, kiun la kliento ne povas atingi, malsukcesas poste kaj aliloke.

Du klientoj, poste unu revoko

Konektu du klientojn samtempe kaj legu ambaŭ adresojn. Ili devas esti apartaj, uzeblaj kaj ene de la adresaro, kaj ĉiu devas atingi la servon, por kiu ĝi destiniĝas. Adresaro, kiu disdonas duoblajn adresojn, kutime montriĝas ĉi tie, ne en la unua unuklienta testo.

Revoku unu akreditaĵon dum la alia kliento restas konektita, poste provu la servon de la postvivanta kliento. Revoko, kiu ĝenas la alian seancon, indikas komunan staton, plej ofte unu akreditaĵon aŭ unu adreson reuzatan inter aparatoj. Rekonektu la revokitan klienton kaj konfirmu, ke ĝi estas rifuzata anstataŭ ricevi la liberigitan adreson.

Finu per celo, kiu devus esti rifuzata. Kliento, kiu atingas ĉion, estis konektita, ne testita.

Skribu la kvar valorojn tie, kie la sekva ŝanĝo ilin trovos

La noto estas mallonga: la adresara gamo kaj prefikso, la atribua reĝimo, la revena vojo aŭ traduko en uzo, kaj la DNS-amplero, kiu respondas por tiuj celoj. Metu ĝin apud la servila agordo anstataŭ en bileton, kaj datu ĝin. Ĉiu, kiu poste ŝanĝas unu el la kvar, bezonas la aliajn tri antaŭ si, ĉar ŝanĝo de la adresara grandeco rompas la itineron kaj ŝanĝo de itinero rompas la DNS-respondon.

Tenu kun ĝi la posedan noton: la tunela gamo apartenas al la VPN-servilo, kaj rezervo farita en la LAN-DHCP-amplero rezervas nenion por kliento ene de la tunelo. Tiu unu linio malhelpas la plej oftan repropon, kie iu aldonas rezervon kaj atendas, ke la tunela adreso sekvos ĝin.