Pse LAN-i juaj nuk arrin një shërbim në një klient VPN

Tuneli juaj është lart, shërbimi dëgjon dhe LAN-i i zyrës ende nuk merr asgjë mbrapsht. Askush nuk e prishi VPN-në. Nga ana e LAN-it, adresa e tunelit të laptopit nuk ekziston derisa diçka t’i thotë LAN-it se si të arrijë atje, dhe përgjigja duhet të kthehet në të njëjtën rrugë nga e cila doli kërkesa. Kam parë njerëz të rindërtojnë tre herë një tunel plotësisht të shëndoshë përpara se dikush të shikonte rrugën e kthimit.

Nuk u prish tuneli

Të dy skajet qëndrojnë në diapazon privatë, që është rasti normal dhe jo konfigurim i gabuar. Një adresë si 10.8.0.6 është reale brenda tunelit dhe nuk ekziston askund tjetër, prandaj LAN-i nuk ka arsye të dërgojë gjë atje. Para se të prekni rrugëtimin, konfirmoni që shërbimi është i arritshëm brenda tunelit: në klient, ss -ltn tregon nëse dëgjuesi lidhet me 127.0.0.1, me ndërfaqen e LAN-it apo me adresën e tunelit. Një daemon i lidhur vetëm me loopback nuk i përgjigjet askujt përveç vetes, dhe asnjë rrugë, DNAT apo ridrejtim porti nuk e ndryshon këtë.

Një përfaqësues në portin 80 ose 443 është mjet tjetër me dukshmëri tjetër. Ai lëviz kërkesa, jo paketa, prandaj është shtresa e gabuar për një lidhje të papërpunuar me bazë të dhënash, dhe pikërisht të shtrihesh drejt tij është mënyra se si ky problem përfundon tre mjete më thellë përpara se dikush të masë gjë.

Forma e rrugës: tregoni LAN-it ku është pishina

Një rrugë statike në portalin e LAN-it është përgjigja më e pastër kur LAN-i dhe pishina e tunelit nuk mbivendosen. Drejtojeni pishinën te makina që e përfundon tunelin:

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

Kjo rregullon vetëm një drejtim, prandaj versionet gjysmë të përfunduara të këtij ndryshimi duken si përparim. Ana e tunelit ka nevojë për gjysmën përkatëse, përndryshe përgjigja e lë klientin në rrugën e vet të paracaktuar dhe vdes rrugës:

push "route 192.168.1.0 255.255.255.0"

Për një nënrrjet që qëndron pas një klienti dhe jo pas serverit, serverit i duhet edhe një rrugë sistemi edhe një hyrje iroute në skedarin e atij klienti nën client-config-dir. Pa iroute, OpenVPN e di që prefiksi ekziston dhe nuk e ka idenë se cili klient e zotëron: paketat mbërrijnë dhe daemoni nuk ka me çfarë t’i përputhë.

Ja miti që meriton një emër. Një rrugë e bën një adresë të arritshme; nuk e bën anën tjetër të gatshme për t’u përgjigjur. Partnerët faqe-në-faqe shtojnë edhe një shtresë sipër, sepse porta e largët pranon vetëm burime brenda prefikseve të politikës së saj, dhe një laptop që vjen nga një pishinë shtëpiake nuk është brenda tyre.

Forma e NAT: DNAT nga brenda, dhe rreshti SNAT që të gjithë e anashkalojnë

Kur nuk mund ta prekni portalin e LAN-it, ose doni të publikoni saktësisht një port, përkthimi në hostin VPN punon pa asnjë rrugë në LAN. Publikoni portin, përcilleni dhe përktheni burimin në rrugë drejt tunelit:

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

Rreshti i tretë është ai që humbet. Anashkalojeni dhe klienti e sheh adresën origjinale të LAN-it si burim, përgjigjet përmes rrugës së vet të paracaktuar, dhe ajo përgjigje shkon në tunel në vend që të kthehet drejt LAN-it. Nëse lidhja mbijeton varet atëherë nga rrugëtim që nuk e keni planifikuar kurrë. Me SNAT klienti sheh adresën e tunelit të serverit, kështu që përgjigja ndjek tunelin mbrapsht deri te hosti i vetëm që mund ta anulojë përkthimin.

Firmware-i i konsumatorit përdor emrat e vet të zinxhirëve dhe nuk e gjeneron atë përkthim për ju. Në Tomato, një rregull hyrës bie në WANPREROUTING dhe pastaj në një zinxhir filtrim si wanin, dhe një grup rregullash që duket i plotë ka ende nevojë për një rresht POSTROUTING manual. Ky nuk është defekt i firmware-it; është një grup rregullash i shkruar vetëm për trafik hyrës.

Pse një rregull që duket i saktë gjithsesi e hedh paketën

Shumica e këtyre dështimeve nuk janë në rregullin ku po shikoni me këmbëngulje. Kontrolloni katër gjëra në këtë rend dhe ndaloni te e para që nuk vlen:

• Rendi i zinxhirëve. iptables -I shton në krye dhe -A shton në fund, prandaj vendos i pari një rregull lejues ose bllokues më i hershëm.
• Zinxhir i gabuar. Trafiku i drejtuar te vetë routeri kalon nëpër INPUT, dhe trafiku i përçuar nuk e prek kurrë. Publikimi i një shërbimi mund të kërkojë rregulla në të dyja.
• Flamujt e drejtimit. -i tun0 përputhet me trafikun që vjen nga klientët dhe -o tun0 me trafikun që shkon drejt tyre. Një REJECT me flamurin e gabuar bllokon diçka që nuk e kishit synuar.
• Kufizimi i burimit. Një përcjellje që pranon një adresë klienti punon nga ai klient dhe hedh çdo burim tjetër pa asnjë fjalë.

Një rregull me numërues paketash zero nuk është fare në rrugë, dhe leximi i numëruesve është mënyra më e shpejtë për të ndarë një problem zinxhiri të gabuar nga një problem rregulli të gabuar.

Përcjellja lokale, kur asgjë në LAN nuk mund të ndryshohet

Një përcjellje lokale SSH e anashkalon tërë pyetjen. Nuk i duhet rrugë në LAN, as bashkëpunim nga muri i zjarrit i klientit, as port i publikuar kudo:

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

Shërbimi shfaqet atëherë në localhost:3000 të makinës që mban tunelin, dhe askund tjetër. Ky është kufiri: një stacion pune, një port, dhe përcjellja vdes me sesionin nëse diçka nuk e rinis. Për një administrator që kontrollon një bazë të dhënash provë është mjeti i duhur. Për një kamerë ose skaner që njerëz të tjerë duhet të arrijnë, nuk është, sepse çdo përdorues do të kishte nevojë për përcjelljen e vet.

Verifikoni të dy drejtimet para se të shtoni një rregull tjetër

Përkthimi lë gjurmë, dhe leximi i tyre është më i mirë se hamendja. Në hostin VPN, conntrack -L tregon nëse përkthimi ndodhi, iptables -t nat -L -n -v tregon nëse numëruesit lëvizën, dhe tcpdump -ni any port 3000 tregon cila adresë burimi mbërriti vërtet. Në klient, ss -ltn konfirmon që dëgjuesi është në një adresë që tuneli mund ta arrijë.

Pastaj zgjidhni formën që mbani. Një port i publikuar, një rrugë për tërë pishinën dhe një përcjellje për një administrator të vetëm janë tre angazhime të ndryshme, dhe përzierja e tyre është mënyra se si një konfigurim që punon bëhet një që askush nuk di ta shpjegojë gjashtë muaj më vonë. Shkruani cila adresë është e arritshme nga ku, dhe personi i ardhshëm që do ta korrigjojë këtë nis nga përgjigja në vend të tunelit.