Parehong subnet sa magkabilang dulo: i-map ang malayong LAN sa isang libreng saklaw

Ang tahanan at opisina ay parehong gumagamit ng 192.168.1.0/24, kaya ang kahilingan sa 192.168.1.1 ay may dalawang posibleng sagot at pinipili ng kliyente ang isa nang hindi nagtatanong. Bihirang maging popular ang muling pagbilang ng gumaganang network ng opisina, at ang mga address ng router ay madalas na nakabaon sa mga printer, camera at dokumentasyon. Ang pagmamapa ng address sa panig ng kliyente ay maaaring magpakita ng malayong network sa ilalim ng libreng saklaw sa halip, at ang bahagi ng host ay maaaring manatiling pareho upang lumitaw ang 192.168.1.20 bilang 10.203.41.20. Ang problema ay ilang kliyente lang ang nagpapatupad nito, at wala itong ginagawa para sa daan pabalik.

Dalawang pananaw sa parehong host

Pinapanatili ng pagmamapa ang bahagi ng host at binabago lamang ang bahagi ng network. Ang parehong makina ay sumasagot sa dalawang address depende sa kinatatayuan mo. Ang pagsusulat ng parehong hanay bago mag-configure ng anuman ay pumipigil sa maling pagbasa ng mga log at patakaran ng firewall mamaya.

Ang mga lokal na device sa bahay ay nagpapanatili ng kanilang sariling 192.168.1.x address, at iyon ang layunin ng pagsasanay. Nananatiling maabot ang printer sa katabing silid habang lumilitaw ang opisina sa ilalim ng saklaw na hindi nagbabanggaan.

Ang pagkakasunod-sunod ng mga argumento ang buong pakulo

Tumatanggap ang option ng direksyon, network at mask, at isang alias: ang unang network ay ang nakikita ng kliyente, ang alias ang nakikita ng server. Para sa mga resource na nasa likod ng malayong gateway, ang direksyon ay ang anyo ng destinasyon. Ang pagbaligtad ng dalawang network dahil ang huling argumento ay tinatawag na alias ang pagkakamaling gumagawa ng tunnel na kumokonekta at walang naipapamapa.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

Ang ruta ang nagpapadala ng mga packet ng kliyente para sa bagong saklaw papasok sa tunnel; isinusulat muli ng pagsasalin ang destinasyon sa daan. Ang sagot mula sa 192.168.1.20 ay isinusulat pabalik sa 10.203.41.20 upang manatiling pare-pareho ang socket sa kliyente. Gumagana rin ang isang host sa parehong paraan na may mask na buong haba, hangga't inilalarawan ng ruta at pagmamapa ang parehong address.

Ito ay pagmamapa ng address, hindi pagmamapa ng port. Hindi maihihiwalay ang dalawang serbisyo sa isang host gamit ito, at ang protocol na naglalagay ng mga IP address sa loob ng payload nito ay makikita pa rin ang tunay.

Hindi gumagawa ng daan pabalik ang pagmamapa

Nangyayari ang pagsasalin sa kliyente, kaya kailangan pa ring i-ruta ng server ang mga sagot papasok sa tunnel at kailangan pa ring payagan ito ng firewall nito. Kung hindi alam ng malayong gateway kung paano maabot ang subnet ng tunnel, dumarating ang kahilingan at lumalabas ang sagot sa maling pinto; ginagawa lang ng pagmamapa na magmukhang problema ng kliyente ang pagkabigo.

Dapat ilarawan ng mga patakaran sa panig ng server ang mga address na umiiral sa server pagkatapos ng pagsasalin, hindi ang saklaw na nakikita ng kliyente. Ang pagkopya ng alias sa isang patakaran ng pahintulot ay nagsasayang ng isang hapon, dahil walang packet sa panig na iyon ang nagdadala nito.

Pumili ng saklaw ng alias na hindi nagbabanggaan sa anumang iba pang ini-ruta ng kliyente: isa pang VPN, isang network ng container, isang pangalawang opisina. Ang banggaan dito ay muling nagpapasok ng orihinal na kalabuan sa ilalim ng ibang numero at mas mahirap makita dahil mukhang hindi pamilyar ang mga address.

Nakaligtas ang mga pangalan at payload sa pagsasalin

Ang hostname na nagre-resolve sa tunay na 192.168.1.20 ay nagpapadala sa browser sa lokal na device sa halip na sa malayo, anuman ang sabihin ng routing table. Dapat ituro ng sagot ng pribadong DNS ang saklaw na nakikita ng kliyente, habang dinadala pa rin ng TLS certificate ang pangalang inaasahan ng application. Subukan gamit ang pangalan sa halip na address, dahil maaaring gumana ang address habang tahimik na nagre-resolve ang pangalan sa maling direksyon. Kapag pinaglilingkuran din ng malayong gateway ang zone na iyon, kailangan din ng sarili nitong record ang saklaw na nakikita ng kliyente.

Ang mga redirect, naka-embed na URL at application na nagbibigay ng sariling address sa isang payload ay maaaring masira sa paraang walang pagmamapa ng packet na makakapag-ayos. Ituring ang mga ito na problema ng application at sukatin ang pagsisikap nang naaayon bago mangako na hindi kailangan ang muling pagbilang.

Tatlong pagsusuri bago magbigay ng pangako

Una, kumpirmahin ang implementasyon ng kliyente. Sinusuportahan ng Community OpenVPN ang option na ito; inililista ito ng OpenVPN 3 codebase sa mga feature na hindi sinusuportahan, kaya ang profile na itinulak sa kliyenteng tulad ng Connect ay maaaring balewalain lang ito. Ang direktibang tinatanggap at hindi kailanman inilalapat ay mas malala kaysa sa error, dahil mukhang malusog ang tunnel.

Pangalawa, i-verify nang hiwalay ang ruta at pagsasalin gamit ang maikling diagnostic window sa mataas na verbosity, pagkatapos ay subukan ang aktwal na serbisyo sa halip na ping. Pangatlo, kumpirmahin na nananatiling makikilala mula sa kliyente ang lokal na router at malayong resource, dahil iyon ang orihinal na layunin.

Kung hindi kayang gawin ng kliyente ang pagsasalin, humingi ng tulong sa panig ng gateway o tanggapin ang muling pagbilang. Ang pagdaragdag ng mas maraming ruta para sa parehong address ay hindi disenyo.