OpenVPN-LAN-tagong stikken? Kontrolearje sônes, rûtes en weromwei

De tunnel meldt in slagge ferbining, de eigen side fan 'e router laded, en in skiifskeppeling nei in masine efter him ferrint noch altyd. Neat yn dy kombinaasje is tsjinstridich: de router antwurdet as himsels, en eat efter him berikke is in oare beslissing dy't op in oare plak nommen wurdt. Wurket de kontrôles hjirûnder yn folchoarder ôf en stopje by de earste fout, want elk stiet op 'e foarige. As alle fjouwer slagje, sit de fout boppe de tunnel en net deryn.

Hokker filter sjocht in pakket nei it LAN

In pakket dat oan 'e router rjochte is, wurdt lokaal ferbrûkt; in pakket dat oan in host efter him rjochte is, moat trochstjoerd wurde, en firewalls beoardielje dy twa gefallen apart. Tastimming om de router te berikken seit dus neat oer tastimming om him te krúsjen. Firmware dy't syn regelgroepen ferberget, ymplementearret dochs beide, meast as in selektor dy't it LAN, it ynternet of beide biedt. As de selektor it LAN weilitten lit, sil gjin inkele lettere kontrôle mear fan belang wêze.

OpenWrt makket dy splitsing ûndersykber, en it ûnderskied is ien kear lêzen wurdich. De sône dy't de tunnel einiget, hat in trochstjoerregel nedich nei de LAN-sône, wylst in ynfierregel allinnich tsjinsten op 'e router sels regelet. In wurkjende behearspagina njonken in deade LAN is it gewoane resultaat fan dy ûntbrekkende trochstjoerregel.

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

Sjoch nei it trochstjoerdiel fan 'e sône dy't de tunnel draacht: accept is wat de ljedder nedich hat, en reject ferklearret elk ferstriken hjirûnder. Twa oanbuorjende ynstellingen meitsje itselde symptoom, dus slút se hjir út wylst jo hjir binne. Draadleaze isolaasje ferberget bedrade hosts foar draadleaze klanten, en in router dy't ledige LAN-hosts as offline behannelet, kin de antwurden fuortsmite sels nei't trochstjoeren wurket.

Wêrom in splitst tunnel it trochdrukte prefiks nedich hat

In klant dy't al it ferkear troch de tunnel stjoert, hat it LAN-prefiks al fia syn standertrûte, dus der is neat ta te foegjen. In splitst tunnel is it gefal dat it prefiks eksplisyt neamd hawwe wol, om't neat oars yn 'e konfiguraasje it neamt. Foegje de rjochtline ta oan 'e tsjinnerkonfiguraasje en laad de tsjinst opnij.

push "route 192.168.50.0 255.255.255.0"

Profilen dy't route-nopull befetsje, negearje trochdrukte rûtes, dus itselde prefiks heart yn it klantbestân. Befêstigje hoe dan ek dat de ynfier oankaam yn stee fan it oan te nimmen, want in stil oerskriuwen liket krekt op in firewallprobleem.

ip route show | grep 192.168.50

In site-nei-site-pear freget mear as in push. De tsjinner moat leare hokker prefiksen efter dat pear sitte, wat in iroute-rigel yn syn client-config-dir-bestân docht, en syn eigen tabel hat in bypassende rûte de tunnel yn nedich.

It antwurd hat in adres nedich dat it berikke kin

It fersyk trochstjoere is mar de helte fan in útwikseling, want de LAN-host moat in adres yn 'e tunnelpool beantwurdzje. Lytse routers regelje dat meast troch de boarne op 'e tunnelsône te oersetten, sadat it antwurd oan 'e router rjochte is en nearne oars konfiguraasje nedich hat. Helje dy oersetting fuort en de host hat syn eigen rûte nei de pool nedich, dy't er fergees krijt as de router syn standertpoarte is. In host mei in mei de hân ynsteld adres en in oare poarte antwurdet fia dy poarte, en de klant sjocht in sesje iepenjen en dan fêstrinne.

tcpdump -ni tun0 host 192.168.50.20

Rin dat op 'e router wylst de klant syn fersyk werhellet, en lês it bestimmingsadres fan it antwurd yn stee fan it fersyk. In antwurd oan 'e pool betsjut dat de weromwei wurket en de fout fierder nei binnen sit. Gjin antwurd betsjut dat de host it pakket nea oannaam, wat jo weromstjoert nei de regelgroep.

In ljedder dy't op it goede plak einiget

Fjouwer kontrôles lokalisiere de laach, en elk is ien opdracht yn stee fan in oardiel. Rin se yn folchoarder en stopje by de earste fout. De folchoarder is wichtiger as de opdrachten, want in lettere stap dy't slagget ferberget de reden wêrom't in eardere mislearre.

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

Nammen hearre oan 'e ein fan 'e ljedder, nea oan it begjin. In dieling dy't antwurdet as 192.168.50.20 mar net as nas.local wiist op nameresolúsje of op in sykstafoegsel, en firewallwizigingen kinne gjin fan beide feroarje.

Skriuw de earste mislearre stap op, jou dan de tsjinstpoarten har eigen rûnde, want in lústerder en in hosttastimming binne aparte easken. Bestânsdielen, fierskerm en kamerastreams hawwe beide nedich, en in hostfirewall dy't it LAN-subnet fertrout mar net de tunnelpool, smyt de klant fuort wylst ping noch slagget. As alle kontrôles slagje en de applikaasje dochs mislearret, sit de fout boppe de tunnel: in tsjinst bûn oan ien ynterface, of in proxy konfigurearre op 'e klant.