Piniping ng kliyente ang address ng tunnel ng OpenVPN server at nakakuha ng sagot, pagkatapos sinusubukan ang isang host sa LAN ng server at walang nakukuha. Ang paghahati na ito ay malaking nagpapaliit ng sira: nakabangon ang tunnel, malamang gumagana ang pagpapasa, at lumalabas ang sagot sa pinto na hindi bumabalik. May tatlong lunas, at ang tama ay depende sa kung ano ang kontrolado mo at kung ano ang handa kang isuko. Sagutin ang tatlong tanong sa ibaba nang sunud-sunod at hindi na ito magiging usapin ng lasa.

Una, tiyakin kung aling direksyon ang sira

Dumarating ang kahilingan sa interface ng tunnel na may source address mula sa pool ng VPN. Ipinapasa ito ng server sa host sa LAN, at sumasagot ang host na iyon sa gateway na itinakda ng sarili nitong talahanayan, kadalasan ang router ng LAN. Kung walang ruta ang router patungo sa pool, namamatay ang sagot doon o gumagala patungo sa internet.

Subukan ang dalawang makina bago baguhin ang alinman. Tanungin ang routing table sa server kung paano nito maaabot ang kliyente; tanungin ang host sa LAN kung paano nito maaabot ang parehong address. Karaniwang tumuturo ang unang paghahanap sa tunnel at ang pangalawa sa router ng LAN, at ang pagkakaibang iyon ang sira sa isang linya. Mas mura ang dalawang paghahanap kaysa sa audit ng firewall at tinutukoy nila ang direksyon ng problema.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Kung nakaturo na ang host sa LAN sa VPN server, ang problema mo ay tuntunin ng firewall o limitasyon ng MTU, hindi nawawalang daan pabalik. Huwag magdagdag ng ruta para ayusin ang filter.

Unang tanong: mababago mo ba ang router ng malayong LAN?

Kapag pag-aari mo ang router ng LAN, malinis na sagot ang static na ruta patungo sa pool ng VPN na may address ng LAN ng VPN server bilang susunod na hakbang. Pinapanatili nitong buo ang source address ng mga kliyente, na mahalaga kapag nagla-log, nagfi-filter o naglilimita ng bilis ang mga host sa LAN ayon sa address. Hindi rin ito nangangailangan ng pagsasalin sa server, kaya nananatiling purong landas ng routing ang tunnel. Ang obligasyong nililikha nito ay dokumentasyon, dahil dapat magtugma ang pool, ruta at configuration ng server.

Tahimik itong nabibigo sa araw na may magpalit ng pool. Isulat ang halaga nang isang beses at ituring na pagbabago sa alinman sa tatlong lugar ang pagbabago sa lahat ng tatlo.

Kailangan din ng NAS o Layer 3 switch na nagho-host ng serbisyo ang parehong ruta, maliban kung ipinapadala nito ang lahat sa router na mayroon nito. Suriin ang device na nagtatapos sa subnet, hindi lang ang nakaharap sa internet. Madalas may tatlong device ang maliliit na network na may opinyon tungkol sa routing.

Ikalawang tanong: maaari bang tumigil ang LAN sa pagtingin sa mga address ng kliyente?

Kapag pag-aari ng iba ang router, hindi kailangan ng pagsasalin sa VPN server ang pakikipagtulungan. Nakikita ng host sa LAN ang address ng LAN ng server, sumasagot dito, at nagsasalin pabalik ang server. Iyon ang dahilan kung bakit ganoon ang ugali ng mga appliance at ng mga papel ng remote access na nakabatay sa NAT.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Ang halaga ay attribution: nawawala sa mga log ng LAN ang mga address bawat kliyente. Kailangan nang banggitin ng anumang allowlist sa host sa LAN ang server sa halip na ang pool.

Piliin ang pagsasalin kapag walang pakikipagtulungan, hindi kapag hindi lang ito komportable. Itinatago nito ang kliyente mula sa bawat susunod na imbestigasyon, kabilang ang mga kailangan mong malaman kung aling laptop ang nagbukas ng koneksyon. Maaari rin nitong sirain ang mga protocol na naglalagay ng address sa payload, dahil nasa header ang pagsasalin. Walang opsyon na mas advanced; sumasagot sila sa magkaibang tanong tungkol sa pagmamay-ari.

Ikatlong tanong: kliyente ba mismo ng ibang tunnel ang server?

Isipin ang kabilang topolohiya: dumadaan din ang VPN server sa isang komersyal na provider, kaya may dalawang tunnel at dalawang set ng address ito. Lumalabas sa provider ang trapikong ipinapasa nito para sa sariling mga kliyente, at hindi iruruta nito pabalik ang mga sagot sa mga address ng pool. Iyon ang dahilan kung bakit nawawala ang mga sagot kahit malusog ang dalawang tunnel.

Ang lunas ay i-masquerade din ang papalabas na tunnel, para ang address ng tunnel ng server lang ang makita ng provider. Kailangan ng sariling tuntunin ang kabaligtarang direksyon, dahil ibang daloy ang server na nagsisimula ng koneksyon patungo sa sariling kliyente. Kung wala ang tuntuning iyon, sumasagot ang kliyente sa address na hindi nito maaaring iruta. Ilagay ang makitid na tuntunin bago ang anumang malawak na masquerade para manalo ang partikular na pagsasalin.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Nagdadagdag ng kaugnay na sira ang mga host na may maraming interface na mukhang pareho mula sa kliyente. Lumalabas ang sagot sa interface na may mas mababang metric dahil pinili ang source address mula sa ibang talahanayan. Suriin ang daan pabalik sa paghahanap sa halip na ipagpalagay na kasama ito ng daan papunta.

Pagkatapos, tiyakin ang dalawang direksyon at dalawang sukat

Pagkatapos ng pagbabago, mag-ping mula sa kliyente patungo sa host sa LAN at pagkatapos mula sa host sa LAN pabalik sa kliyente. Ang pangalawang direksyon ang madalas laktawan, at ito ang naglalantad ng kulang na tuntunin sa pagsasalin. Itala ang dalawang resulta na may timestamp para maihambing ang susunod na regression.

Pagkatapos, ilipat ang totoong data, dahil ang maliit na ping na nagtagumpay habang natigil ang malaking paglilipat ay sintomas ng MTU. Lumalabas ang sirang iyon kaagad pagkatapos mong batiin ang sarili mo sa pag-ayos ng ruta.

Sa huli, subukan muli pagkatapos ng reboot. Hindi nakakalampas ang mga utos ng ruta at firewall sa runtime, at ang lunas na nawawala sa susunod na boot ay muling masusuri ng taong may mas kaunting konteksto. Gawing permanente ang pagbabago sa paraang ginagawa na ng sistema mo, pagkatapos mag-reboot nang isang beses nang sadya.

Kaugnay na mga artikulo