Bakit hindi naaabot ng iyong LAN ang isang serbisyo sa isang VPN client

Buhay ang iyong tunnel, nakikinig ang serbisyo, at wala pa ring natatanggap na sagot ang LAN ng opisina. Walang sumira sa VPN. Mula sa panig ng LAN, wala ang address ng tunnel ng laptop hanggang may magsabi sa LAN kung paano ito maaabot, at dapat bumalik ang sagot sa mismong daang nilabas ng kahilingan. Nakita ko na ang mga tao na muling itinayo nang tatlong beses ang isang ganap na maayos na tunnel bago pa may tumingin sa daan pabalik.

Hindi ang tunnel ang nasira

Parehong nakaupo ang dalawang dulo sa mga pribadong saklaw, na siyang normal na kaso at hindi maling konfigurasyon. Ang address na tulad ng 10.8.0.6 ay totoo sa loob ng tunnel at wala saanman, kaya walang dahilan ang LAN na magpadala ng kahit ano roon. Bago hawakan ang routing, tiyakin muna na maabot talaga ang serbisyo sa loob ng tunnel: sa client, ipinapakita ng ss -ltn kung ang tagapakinig ay nakatali sa 127.0.0.1, sa interface ng LAN, o sa address ng tunnel. Ang daemon na nakatali lamang sa loopback ay walang sinasagot kundi ang sarili nito, at walang ruta, DNAT, o port forwarding ang makakabago niyon.

Ang proxy sa port 80 o 443 ay ibang kasangkapan na may ibang visibility. Naglilipat ito ng kahilingan, hindi ng packet, kaya maling layer ito para sa hilaw na koneksyon sa database, at ang pag-abot dito ang paraan kung bakit nauuwi ang problemang ito nang tatlong kasangkapan ang lalim bago pa may sumukat ng kahit ano.

Hugis ng ruta: sabihin sa LAN kung nasaan ang pool

Ang static na ruta sa gateway ng LAN ang pinakamalinis na sagot kapag hindi nag-o-overlap ang LAN at ang pool ng tunnel. Ituro ang pool sa makina na nagtatapos ng tunnel:

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

Isang direksyon lamang ang naayos niyan, kaya ang kalahating-tapos na bersyon ng pagbabagong ito ay mukhang progreso. Kailangan din ng panig ng tunnel ang katambal na kalahati, kung hindi ay iiwan ng sagot ang client sa sarili nitong default na ruta at mamamatay sa daan:

push "route 192.168.1.0 255.255.255.0"

Para sa subnet na nasa likod ng isang client at hindi sa likod ng server, kailangan ng server ang ruta ng sistema at ang entry na iroute sa file ng client na iyon sa ilalim ng client-config-dir. Kung walang iroute, alam ng OpenVPN na may prefix at wala itong ideya kung aling client ang nagmamay-ari nito: dumarating ang packet at wala ang daemon ng maipapares dito.

Narito ang alamat na dapat pangalanan. Ginagawang maabot ng ruta ang isang address; hindi nito ginagawang handa ang kabilang panig na sumagot. Nagdadagdag ng isa pang sapin ang mga site-to-site peer, dahil tinatanggap lamang ng malayong gateway ang mga pinagmulan sa loob ng mga prefix sa patakaran nito, at ang laptop na galing sa pool sa bahay ay wala sa loob ng mga iyon.

Hugis ng NAT: DNAT papasok, at ang linyang SNAT na nilalaktawan ng lahat

Kapag hindi mo mahawakan ang gateway ng LAN, o gusto mong maglathala ng eksaktong isang port, gumagana ang pagsasalin sa host ng VPN na walang anumang ruta sa LAN. Ilathala ang port, ipasa ito, at isalin ang pinagmulan sa daang papasok ng tunnel:

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

Ang ikatlong linya ang nawawala. Laktawan ito at makikita ng client ang orihinal na address ng LAN bilang pinagmulan, sasagot sa sarili nitong default na ruta, at ang sagot na iyon ay papasok sa tunnel sa halip na bumalik sa LAN. Kung mabubuhay ang koneksyon ay depende noon sa routing na hindi mo kailanman pinlano. Sa SNAT nakikita ng client ang address ng tunnel ng server, kaya sinusundan ng sagot ang tunnel pabalik sa nag-iisang host na makakabawi sa pagsasalin.

Gumagamit ang firmware ng consumer ng sarili nitong mga pangalan ng chain at hindi nito nililikha ang pagsasaling iyon para sa iyo. Sa Tomato, ang papasok na patakaran ay nahuhulog sa WANPREROUTING at pagkatapos sa isang chain ng pag-filter tulad ng wanin, at ang set ng patakarang mukhang kumpleto ay kailangan pa rin ng manu-manong linyang POSTROUTING. Hindi iyon bug ng firmware; isang set ng patakaran iyon na isinulat para lamang sa papasok na trapiko.

Bakit ang patakarang mukhang tama ay nagtatapon pa rin ng packet

Karamihan sa mga pagkabigong ito ay wala sa patakarang tinititigan mo. Suriin ang apat na bagay sa ayos na ito, at huminto sa unang hindi totoo:

• Ayos ng chain. Naglalagay ang iptables -I sa itaas at nagdaragdag ang -A sa dulo, kaya ang naunang patakarang nagpapahintulot o humaharang ang unang magpapasya.
• Maling chain. Ang trapikong patungo sa router mismo ay dumadaan sa INPUT, at ang trapikong ipinapasa ay hindi ito kailanman nadidikit. Ang paglathala ng isang serbisyo ay maaaring mangailangan ng patakaran sa pareho.
• Mga flag ng direksyon. Ang -i tun0 ay tumutugma sa trapikong galing sa mga client at ang -o tun0 sa trapikong patungo sa kanila. Ang REJECT na may maling flag ay humaharang sa bagay na hindi mo sinasadya.
• Paghihigpit sa pinagmulan. Ang pagpapasang tumatanggap ng isang address ng client ay gumagana mula sa client na iyon at itinatapon ang bawat ibang pinagmulan nang walang salita.

Ang patakarang may sero na counter ng packet ay wala talaga sa landas, at ang pagbasa ng mga counter ang pinakamabilis na paraan upang ihiwalay ang problema ng maling chain sa problema ng maling patakaran.

Ang lokal na pagpapasa, kapag walang mababago sa LAN

Ang lokal na pagpapasa ng SSH ay lumilihis sa buong tanong. Hindi ito nangangailangan ng ruta sa LAN, ng pakikipagtulungan ng firewall ng client, at ng port na nailathala kahit saan:

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

Lumilitaw noon ang serbisyo sa localhost:3000 ng makinang may hawak ng tunnel, at wala sa iba pang lugar. Iyon ang hangganan: isang workstation, isang port, at namamatay ang pagpapasa kasama ng session maliban kung may mag-restart nito. Para sa administrador na sumusuri ng staging na database, ito ang tamang kasangkapan. Para sa kamera o scanner na kailangang maabot ng ibang tao, hindi, dahil ang bawat user ay mangangailangan ng sarili nitong pagpapasa.

Suriin ang dalawang direksyon bago magdagdag ng isa pang patakaran

Nag-iiwan ng bakas ang pagsasalin, at mas mabuti ang pagbasa nito kaysa paghula. Sa host ng VPN, ipinapakita ng conntrack -L kung nangyari ang pagsasalin, ipinapakita ng iptables -t nat -L -n -v kung gumalaw ang mga counter, at ipinapakita ng tcpdump -ni any port 3000 kung aling address ng pinagmulan ang talagang dumating. Sa client, ipinapakita ng ss -ltn na ang tagapakinig ay nasa address na kayang maabot ng tunnel.

Pagkatapos piliin ang hugis na ititira mo. Isang nailathalang port, isang ruta para sa buong pool, at isang pagpapasa para sa isang administrador ay tatlong magkaibang pangako, at ang paghahalo sa kanila ang paraan kung paanong ang gumaganang setup ay nagiging isang walang makapagpapaliwanag anim na buwan mamaya. Isulat kung aling address ang maaabot mula saan, at ang susunod na taong magde-debug nito ay magsisimula sa sagot sa halip na sa tunnel.