Waarom jou LAN nie ’n diens op ’n VPN-kliënt kan bereik nie

’n VPN-kliënt kan ’n diens huisves wat die LAN nie kan oopmaak nie. Wat gewoonlik ontbreek, is die terugpad: een roete, ’n DNAT-paar, of die SNAT-reël wat niemand byvoeg nie.

Jou tonnel is op, die diens luister, en die kantoor se LAN kry steeds niks terug nie. Niemand het die VPN gebreek nie. Van die LAN se kant af bestaan die skootrekenaar se tonneladres nie voordat iets die LAN vertel hoe om dit te bereik nie, en die antwoord moet terugkom op dieselfde pad as waarlangs die versoek uitgegaan het. Ek het al gesien hoe mense ’n heeltemal goeie tonnel drie keer herbou voordat iemand na die antwoordpad gekyk het.

Die tonnel is nie wat gebreek het nie

Albei kante sit op private reekse, wat die normale geval is en nie ’n foutkonfigurasie nie. ’n Adres soos 10.8.0.6 is eg binne die tonnel en bestaan nêrens anders nie, so die LAN het geen rede om enigiets daarheen te stuur nie. Voordat jy aan roetering raak, bevestig dat die diens hoegenaamd binne die tonnel bereikbaar is: op die kliënt wys ss -ltn of die luisteraar aan 127.0.0.1, die LAN-koppelvlak of die tonneladres bind. ’n Daemon wat net aan loopback bind, antwoord niemand behalwe homself, en geen roete, DNAT of poortaanstuur verander dit nie.

’n Volmag op poort 80 of 443 is ’n ander hulpmiddel met ’n ander sigbaarheid. Dit skuif versoeke, nie pakkette nie, so dit is die verkeerde laag vir ’n rou databasisverbinding, en om daarna te gryp is hoe hierdie probleem drie instrumente diep beland voordat iemand enigiets meet.

Roetevorm: vertel die LAN waar die poel is

’n Statiese roete op die LAN-hek is die skoonste antwoord wanneer die LAN en die tonnelpoel nie oorvleuel nie. Wys die poel na die masjien wat die tonnel termineer:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Dit regstel net een rigting, en daarom lyk halfvoltooide weergawes van hierdie verandering soos vordering. Die tonnelkant het die passende helfte nodig, anders verlaat die antwoord die kliënt via sy eie verstekroete en sterf op pad:

push "route 192.168.1.0 255.255.255.0"

Vir ’n subnet wat agter een kliënt sit eerder as agter die bediener, het die bediener beide ’n stelselroete en ’n iroute-inskrywing in daardie kliënt se lêer onder client-config-dir nodig. Sonder iroute weet OpenVPN dat die voorvoegsel bestaan en het geen idee watter kliënt dit besit nie: pakkette kom aan en die daemon het niks om hulle aan te pas nie.

Hier is die mite wat ’n naam werd is. ’n Roete maak ’n adres bereikbaar; dit maak nie die ander kant gewillig om te antwoord nie. Werf-tot-werf-eweknieë voeg nog ’n laag by, want die afgeleë hek aanvaar net bronne binne die voorvoegsels in sy beleid, en ’n skootrekenaar wat uit ’n tuispoel kom, is nie daarbinne nie.

NAT-vorm: DNAT in, en die SNAT-reël wat almal oorslaan

Wanneer jy nie aan die LAN-hek kan raak nie, of jy wil presies een poort publiseer, werk translasie op die VPN-gasheer met geen roete op die LAN hoegenaamd nie. Publiseer die poort, stuur dit aan, en translaseer die bron op pad in die tonnel in:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Die derde reël is die een wat wegraak. Slaan dit oor en die kliënt sien die oorspronklike LAN-adres as die bron, antwoord deur sy eie verstekroete, en daardie antwoord gaan die tonnel in eerder as terug na die LAN toe. Of die verbinding oorleef, hang dan af van roetering wat jy nooit beplan het nie. Met SNAT sien die kliënt die bediener se tonneladres, so die antwoord volg die tonnel terug na die enigste gasheer wat die translasie kan ontslaan.

Verbruikerfirmware gebruik sy eie kettingname en genereer nie daardie translasie vir jou nie. Op Tomato beland ’n inkomende reël in WANPREROUTING en dan in ’n filterketting soos wanin, en ’n reëlstel wat volledig lyk, het steeds ’n handmatige POSTROUTING-reël nodig. Dit is nie ’n firmwarefout nie; dit is ’n reëlstel wat net vir inkomende verkeer geskryf is.

Waarom ’n korrek-ogende reël die pakket steeds laat val

Die meeste van hierdie mislukkings sit nie in die reël waarna jy staar nie. Kontroleer vier dinge in hierdie volgorde, en stop by die eerste een wat nie hou nie:

  • Kettingorde. iptables -I voeg bo-aan in en -A voeg onderaan by, so ’n vroeëre toelatende of blokkerende reël besluit eerste.
  • Verkeerde ketting. Verkeer wat aan die router self gerig is, kruis INPUT, en aangestuurde verkeer raak dit nooit nie. Om een diens te publiseer kan reëls in albei nodig hê.
  • Rigtingvlae. -i tun0 pas verkeer wat van kliënte af kom, en -o tun0 pas verkeer wat na hulle toe vertrek. ’n REJECT met die verkeerde vlag blokkeer iets wat jy nie bedoel het nie.
  • Bronbeperking. ’n Aansturing wat een kliëntadres aanvaar, werk van daardie kliënt af en laat elke ander bron sonder ’n woord val.

’n Reël met ’n pakketteller van nul is glad nie in die pad nie, en om die tellers te lees is die vinnigste manier om ’n verkeerde-ketting-probleem van ’n verkeerde-reël-probleem te skei.

Die plaaslike aanstuur, wanneer niks op die LAN kan verander nie

’n Plaaslike SSH-aanstuur omseil die hele vraag. Dit het geen roete op die LAN nodig nie, geen samewerking van die kliënt se vuurmuur nie, en geen poort wat enige plek gepubliseer word nie:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Die diens verskyn dan op localhost:3000 van die masjien wat die tonnel hardloop, en nêrens anders nie. Dit is die grens: een werkstasie, een poort, en die aanstuur sterf saam met die sessie tensy iets dit herbegin. Vir ’n administrateur wat ’n stoomdatabasis nagaan, is dit die regte instrument. Vir ’n kamera of ’n skandeerder wat ander mense moet bereik, is dit nie, want elke gebruiker sou sy eie aanstuur nodig hê.

Verifieer albei rigtings voordat jy nog ’n reël byvoeg

Translasie laat spore, en om dit te lees is beter as om te raai. Op die VPN-gasheer wys conntrack -L of die translasie hoegenaamd plaasgevind het, wys iptables -t nat -L -n -v of die tellers beweeg het, en wys tcpdump -ni any port 3000 watter bronadres werklik aangekom het. Op die kliënt bevestig ss -ltn dat die luisteraar op ’n adres is wat die tonnel kan bereik.

Kies dan die vorm wat jy hou. Een gepubliseerde poort, ’n roete vir die hele poel en ’n aanstuur vir een enkele administrateur is drie verskillende verbintenisse, en om hulle te meng is hoe ’n werkende opstelling een word wat niemand ses maande later kan verduidelik nie. Skryf neer watter adres van waar bereikbaar is, en die volgende persoon wat dit ontfout, begin by die antwoord eerder as by die tonnel.

Verwante artikels