Wêrom jo LAN gjin tsjinst op in VPN-klant berikke kin

In VPN-klant kin in tsjinst hostje dy’t it LAN net iepenje kin. Wat ornaris ûntbrekt is de weromweis: ien rûte, in DNAT-paar of de SNAT-rigel dy’t nimmen tafoeget.

Jo tunnel stiet, de tsjinst harket, en it kantoar-LAN krijt noch altyd neat werom. Nimmen hat de VPN brutsen. Fan de LAN-kant ôf bestiet it tunneladres fan de laptop net ear’t eat it LAN fertelt hoe’t it dêr komme moat, en it antwurd moat weromkomme oer deselde wei as it fersyk fuortgien is. Ik haw minsken trije kear in folslein sûne tunnel wer opbouwen sjoen ear’t immen nei de weromweis seach.

De tunnel is net wat brutsen is

Beide einden sitte op privee berikken, wat it normale gefal is en gjin ferkearde konfiguraasje. In adres lykas 10.8.0.6 is echt binnen de tunnel en bestiet nearne oars, dus it LAN hat gjin reden om dêr eat hinne te stjoeren. Ear’t jo oan de rûteleas reitsje, befêstigje dat de tsjinst oeral binnen de tunnel berikber is: op de klant lit ss -ltn sjen oft de harker bûn is oan 127.0.0.1, oan it LAN-ynterface of oan it tunneladres. In daemon dy’t allinne oan loopback bûn is antwurdet nimmen oars as himsels, en dêr feroaret gjin rûte, DNAT of poarte-trochstjoering eat oan.

In proxy op poarte 80 of 443 is in oar helpmiddel mei in oare sichtberens. It ferpleatst fersiken, gjin pakketten, dus it is de ferkearde laach foar in rau databankferbining, en dêrnei gripe is krekt hoe’t dit probleem trije helpmiddelen djip einiget ear’t immen eat mjit.

Foarm fan de rûte: fertel it LAN wêr’t de poel is

In statyske rûte op de LAN-gateway is it skjinste antwurd as it LAN en de tunnelpoel gjin oerlap hawwe. Rjochtsje de poel op de masine dy’t de tunnel beëiniget:

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

Dat ferhelpt mar ien rjochting, en dêrom lykje healôffre ferzjes fan dizze feroaring op foarútgong. De tunnelkant hat de byhearrende helte nedich, oars ferlit it antwurd de klant oer syn eigen standertrûte en stjert ûnderweis:

push "route 192.168.1.0 255.255.255.0"

Foar in subnet dat efter ien klant sit ynstee fan efter de tsjinner, hat de tsjinner sawol in systeemrûte as in iroute-ynfier nedich yn it bestân fan dy klant ûnder client-config-dir. Sûnder iroute wit OpenVPN dat it foarheaksel bestiet en hat gjin idee hokker klant it besit: pakketten komme oan en de daemon hat neat om se mei te ferbinen.

Hjir is de myte dy’t in namme fertsjinnet. In rûte makket in adres berikber; it makket de oare kant net ree om te antwurdzjen. Site-to-site-peers foegje dêr noch in laach oer hinne, want de fiere gateway akseptearret allinne boarnen binnen de foarheaksele yn syn belied, en in laptop dy’t út in thúspoel komt sit dêr net yn.

Foarm fan NAT: DNAT nei binnen, en de SNAT-rigel dy’t eltsenien oerslacht

As jo de LAN-gateway net oanreitsje kinne, of krekt ien poarte publisearje wolle, wurket oersetting op de VPN-host sûnder hokker rûte dan ek op it LAN. Publisearje de poarte, stjoer it troch en oerset de boarne ûnderweis de tunnel yn:

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

De tredde rigel is dejinge dy’t weirekket. Sla it oer en de klant sjocht it oarspronklike LAN-adres as boarne, antwurdet oer syn eigen standertrûte, en dat antwurd giet de tunnel yn ynstee fan werom nei it LAN. Oft de ferbining dan oerlibbet hinget ôf fan rûteleas dy’t jo nea pland hawwe. Mei SNAT sjocht de klant it tunneladres fan de tsjinner, dus it antwurd folget de tunnel werom nei de iennige host dy’t de oersetting ûngedien meitsje kin.

Ferbrûkersfirmware brûkt syn eigen kettingnammen en makket dy oersetting net foar jo. Op Tomato falt in ynkommende regel yn WANPREROUTING en dan yn in filterketting lykas wanin, en in regelset dy’t kompleet liket hat noch altyd in hânmjittige POSTROUTING-rigel nedich. Dat is gjin firmware-bug; it is in regelset dy’t allinne foar ynkommend ferkear skreaun is.

Wêrom’t in goedlykjende regel it pakket dochs weilitte lit

De measte fan dizze flaters sitte net yn de regel dêr’t jo nei stoarje. Kontrolearje fjouwer saken yn dizze folchoarder, en stop by de earste dy’t net hâldt:

  • Kettingfolchoarder. iptables -I foegjet boppe-oan yn en -A foeget ûnderoan ta, dus in eardere tastienende of blokkearjende regel beslút earst.
  • Ferkearde ketting. Ferkear nei de router sels giet troch INPUT, en trochstjoerd ferkear rekket dy nea oan. Ien tsjinst publisearje kin regels yn beide nedich hawwe.
  • Rjochtingsflaggen. -i tun0 past by ferkear dat fan klanten komt en -o tun0 by ferkear dat nei harren ta giet. In REJECT mei de ferkearde flag blokkearret eat dat jo net bedoelden.
  • Boarnebeheining. In trochstjoering dy’t ien klantadres akseptearret wurket fan dy klant ôf en lit elke oare boarne sûnder in wurd falle.

In regel mei in pakketteller fan nul is hielendal net op it paad, en de tellers lêze is de fluchste manier om in ferkearde-ketting-probleem fan in ferkearde-regel-probleem te skieden.

De lokale trochstjoering, as neat op it LAN feroarje kin

In lokale SSH-trochstjoering giet de hiele fraach foarby. It hat gjin rûte op it LAN nedich, gjin gearwurking fan de firewall fan de klant, en gjin poarte dy’t earne publisearre is:

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

De tsjinst ferskynt dan op localhost:3000 fan de masine dy’t de tunnel draait, en nearne oars. Dat is de grins: ien wurkstasjon, ien poarte, en de trochstjoering stjert mei de sesje, útsein as eat it opnij start. Foar in behearder dy’t in staging-databank kontrolearret is it it goede helpmiddel. Foar in kamera of in skener dêr’t oare minsken by moatte, is it dat net, want elke brûker soe syn eigen trochstjoering nedich hawwe.

Kontrolearje beide rjochtings ear’t jo noch in regel tafoegje

Oersetting lit spoaren nei, en dy lêze is better as riede. Op de VPN-host lit conntrack -L sjen oft de oersetting ea bard is, lit iptables -t nat -L -n -v sjen oft de tellers ferpleatst binne, en lit tcpdump -ni any port 3000 sjen hokker boarne-adres echt oankaam. Op de klant befêstiget ss -ltn dat de harker op in adres is dat de tunnel berikke kin.

Kies dan de foarm dy’t jo hâlde. Ien publisearre poarte, in rûte foar de hiele poel en in trochstjoering foar ien behearder binne trije ferskillende ferplichtings, en se te mingelen is hoe’t in wurkjende opset ien wurdt dy’t nimmen seis moanne letter útlizze kin. Skriuw op hokker adres fan wêr berikber is, en de folgjende persoan dy’t dit debugget begjint by it antwurd ynstee fan by de tunnel.

Relatearre artikelen