Sirang LAN access sa OpenVPN? Suriin ang mga zone, ruta at daan pabalik

Iniulat ng tunnel ang matagumpay na koneksyon, naglo-load ang sariling pahina ng router, ngunit ang drive mapping sa makina sa likod nito ay nag-eexpire pa rin. Walang kontradiksyon sa kombinasyong iyon: sumasagot ang router bilang sarili nito, at ang pag-abot sa anumang nasa likod nito ay ibang desisyon na ginawa sa ibang lugar. Gawin ang mga pagsusuri sa ibaba nang sunod-sunod at huminto sa unang pagkabigo, dahil bawat isa ay nakasalalay sa nauna. Kapag pumasa ang apat, ang depekto ay nasa itaas ng tunnel at hindi sa loob nito.

Aling filter ang nakakakita ng packet na patungo sa LAN

Ang packet na naka-address sa router ay natutupok nang lokal; ang packet na naka-address sa host sa likod nito ay dapat ipasa, at hinuhusgahan ng mga firewall ang dalawang kaso nang hiwalay. Kaya ang pahintulot na maabot ang router ay walang sinasabi tungkol sa pahintulot na lampasan ito. Ang firmware na nagtatago ng mga set ng patakaran nito ay nagpapatupad pa rin ng dalawa, kadalasan bilang tagapili na nag-aalok ng LAN, internet o pareho. Kung iniwan ng tagapili ang LAN, wala nang pagsusuring makabuluhan pagkatapos.

Ginagawang masuri ng OpenWrt ang paghahati, at ang pagkakaiba ay sulit basahin nang isang beses. Ang zone na nagtatapos sa tunnel ay kailangan ng patakaran sa pagpapasa patungo sa zone ng LAN, habang ang tuntunin sa papasok ay namamahala lamang sa mga serbisyo sa router mismo. Ang gumaganang pahina ng administrasyon sa tabi ng patay na LAN ay ang karaniwang resulta ng nawawalang patakarang iyon.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Tingnan ang target ng pagpapasa ng zone na nagdadala ng tunnel: accept ang kailangan ng hagdan, at ipinapaliwanag ng reject ang bawat timeout sa ibaba. Dalawang kalapit na setting ang nagbubunga ng parehong sintomas, kaya alisin ang mga ito habang narito ka. Itinatago ng wireless isolation ang mga wired host sa mga wireless client, at ang router na itinuturing na offline ang mga idle LAN host ay maaaring magtapon ng mga sagot kahit gumagana na ang pagpapasa.

Bakit kailangan ng split tunnel ang itinulak na prefix

Ang kliyenteng nagpapadala ng lahat ng trapiko sa tunnel ay mayroon nang prefix ng LAN sa pamamagitan ng default route nito, kaya wala nang idadagdag. Ang split tunnel ang kaso na nangangailangan ng prefix na tahasang nakasaad, dahil wala nang ibang binabanggit ito sa konfigurasyon. Idagdag ang direktiba sa konfigurasyon ng server at i-reload ang serbisyo.

push "route 192.168.50.0 255.255.255.0"

Ang mga profile na naglalaman ng route-nopull ay binabalewala ang mga itinulak na ruta, kaya ang parehong prefix ay dapat nasa file ng kliyente. Sa anumang kaso, tiyakin na nakarating ang entry sa halip na ipagpalagay, dahil ang tahimik na pag-override ay mukhang katulad ng problema sa firewall.

ip route show | grep 192.168.50

Ang site-to-site peer ay humihingi ng higit sa isang push. Kailangang matutunan ng server kung aling mga prefix ang nasa likod ng peer, na ginagawa ng linyang iroute sa file nitong client-config-dir, at kailangan din ng sarili nitong talahanayan ng tugmang ruta papasok sa tunnel.

Kailangan ng sagot ng address na maaabot nito

Ang pagpapasa ng kahilingan ay kalahati lamang ng palitan, dahil kailangang sumagot ng LAN host sa address sa pool ng tunnel. Karaniwang inaayos ito ng maliliit na router sa pamamagitan ng pagsasalin ng source sa zone ng tunnel, kaya ang sagot ay naka-address sa router at hindi na kailangan ng konfigurasyon sa ibang lugar. Alisin ang pagsasaling iyon at kailangan ng host ng sariling ruta papunta sa pool, na nakukuha nang libre kapag ang router ang default gateway nito. Ang host na may mano-manong address at ibang gateway ay sumasagot sa gateway na iyon, at nakikita ng kliyente ang session na bumubukas at pagkatapos ay tumitigil.

tcpdump -ni tun0 host 192.168.50.20

Patakbuhin ito sa router habang inuulit ng kliyente ang kahilingan, at basahin ang destinasyon ng sagot at hindi ang kahilingan. Ang sagot na naka-address sa pool ay nangangahulugang gumagana ang daan pabalik at mas malalim ang depekto. Walang sagot ay nangangahulugang hindi kailanman tinanggap ng host ang packet, na nagbabalik sa iyo sa set ng patakaran.

Isang hagdan na nagtatapos sa tamang lugar

Apat na pagsusuri ang tumutukoy sa layer, at bawat isa ay isang utos at hindi isang paghatol. Patakbuhin ang mga ito nang sunod-sunod at huminto sa unang pagkabigo. Mas mahalaga ang pagkakasunod-sunod kaysa sa mga utos, dahil ang huling hakbang na pumasa ay nagtatakip sa dahilan kung bakit nabigo ang nauna.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Ang mga pangalan ay kabilang sa dulo ng hagdan, hindi kailanman sa simula. Ang share na sumasagot bilang 192.168.50.20 ngunit hindi bilang nas.local ay tumuturo sa paglutas ng pangalan o sa search suffix, at hindi mababago ng mga pag-edit sa firewall ang alinman.

Itala ang unang hakbang na nabigo, pagkatapos bigyan ang mga port ng serbisyo ng sarili nitong pag-ikot, dahil magkaibang pangangailangan ang listener at pahintulot ng host. Ang file sharing, remote desktop at camera stream ay nangangailangan ng pareho, at ang firewall ng host na nagtitiwala sa subnet ng LAN ngunit hindi sa pool ng tunnel ay nagtatapon sa kliyente habang pumapasa pa rin ang ping. Kapag pumasa ang lahat ng pagsusuri at nabigo pa rin ang aplikasyon, ang depekto ay nasa itaas ng tunnel: serbisyong nakatali sa isang interface, o proxy na naka-configure sa kliyente.