Kodėl jūsų LAN nepasiekia paslaugos VPN kliente

Jūsų tunelis veikia, paslauga klausosi, o biuro LAN vis tiek nieko negauna atgal. Niekas nesugadino VPN. Iš LAN pusės nešiojamojo kompiuterio tunelio adresas neegzistuoja tol, kol kažkas nepasako LAN, kaip jo pasiekti, ir atsakymas turi grįžti tuo pačiu keliu, kuriuo išėjo užklausa. Mačiau žmones tris kartus perstatinėjant visiškai sveiką tunelį, kol kas nors pažiūrėjo į grįžimo kelią.

Sugedo ne tunelis

Abu galai yra privačiuose diapazonuose, tai įprastas atvejis, o ne klaidinga konfigūracija. Toks adresas kaip 10.8.0.6 yra tikras tunelio viduje ir neegzistuoja niekur kitur, todėl LAN neturi priežasties siųsti ten ką nors. Prieš liesdami maršrutizavimą patvirtinkite, kad paslauga apskritai pasiekiama tunelio viduje: kliente ss -ltn rodo, ar klausytojas susietas su 127.0.0.1, LAN sąsaja ar tunelio adresu. Demonas, susietas tik su loopback, neatsako niekam, išskyrus save, ir to nepakeis joks maršrutas, DNAT ar prievado peradresavimas.

Tarpinė serveris, veikiantis 80 arba 443 prievade, yra kitas įrankis su kitu matomumu. Jis perkelia užklausas, o ne paketus, todėl tai netinkamas sluoksnis neapdorotam duomenų bazės ryšiui, ir būtent griebimasis jo yra kelias, kuriuo ši problema atsiduria trijų įrankių gylyje, kol kas nors ką nors išmatuoja.

Maršruto forma: pasakykite LAN, kur yra baseinas

Statinis maršrutas LAN tinkle gateway yra švariausias atsakymas, kai LAN ir tunelio baseinas nesikerta. Nukreipkite baseiną į kompiuterį, kuris užbaigia tunelį:

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

Tai ištaiso tik vieną kryptį, todėl pusiau baigtos šio pakeitimo versijos atrodo kaip pažanga. Tunelio pusei reikia atitinkamos pusės, kitaip atsakymas palieka klientą jo paties numatytuoju maršrutu ir žūva pakeliui:

push "route 192.168.1.0 255.255.255.0"

Potinkliui, kuris yra už vieno kliento, o ne už serverio, serveriui reikia ir sistemos maršruto, ir iroute įrašo to kliento faile, esančiame po client-config-dir. Be iroute OpenVPN žino, kad priešdėlis egzistuoja, ir neturi supratimo, kuris klientas jį valdo: paketai ateina, o demonas neturi su kuo jų sutapatinti.

Štai mitas, kuris vertas pavadinimo. Maršrutas padaro adresą pasiekiamą; jis nepadaro kitos pusės pasirengusios atsakyti. Svetainės su svetaine partneriai prideda dar vieną sluoksnį, nes nuotolinis tarpinis mazgas priima tik šaltinius, esančius jo politikoje išvardytuose priešdėliuose, o nešiojamasis kompiuteris, atėjęs iš namų baseino, jų viduje nėra.

NAT forma: DNAT į vidų ir SNAT eilutė, kurią visi praleidžia

Kai negalite liesti LAN tarpinio mazgo arba norite paskelbti tiksliai vieną prievadą, vertimas VPN hoste veikia be jokio maršruto LAN tinkle. Paskelbkite prievadą, peradresuokite jį ir išverskite šaltinį kelyje į tunelį:

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

Trečioji eilutė yra ta, kuri dingsta. Praleiskite ją ir klientas mato pradinį LAN adresą kaip šaltinį, atsako savo numatytuoju maršrutu, ir tas atsakymas eina į tunelį, o ne atgal į LAN. Ar ryšys išliks, tada priklauso nuo maršrutizavimo, kurio niekada neplanavote. Su SNAT klientas mato serverio tunelio adresą, todėl atsakymas seka tuneliu atgal iki vienintelio mazgo, galinčio atšaukti vertimą.

Vartotojiška programinė aparatinė įranga naudoja savo grandinių pavadinimus ir negeneruoja to vertimo už jus. Tomato atveju įeinanti taisyklė patenka į WANPREROUTING, o paskui į filtravimo grandinę kaip wanin, ir taisyklių rinkiniui, kuris atrodo išsamus, vis tiek reikia rankinės POSTROUTING eilutės. Tai ne programinės aparatinės įrangos klaida; tai taisyklių rinkinys, parašytas tik įeinančiam srautui.

Kodėl taisyklingai atrodanti taisyklė vis tiek numeta paketą

Dauguma šių gedimų yra ne toje taisyklėje, į kurią spokote. Patikrinkite keturis dalykus šia tvarka ir sustokite ties pirmuoju, kuris netinka:

• Grandinių tvarka. iptables -I įterpia viršuje, o -A prideda pabaigoje, todėl ankstesnė leidžianti ar blokuojanti taisyklė nusprendžia pirma.
• Neteisinga grandinė. Srautas, adresuotas pačiam maršrutizatoriui, praeina pro INPUT, o persiunčiamas srautas jos niekada neliečia. Vienos paslaugos paskelbimas gali reikalauti taisyklių abiejose.
• Krypties vėliavėlės. -i tun0 atitinka srautą, ateinantį iš klientų, o -o tun0 – išeinantį link jų. REJECT su neteisinga vėliavėle blokuoja tai, ko nenorėjote.
• Šaltinio apribojimas. Peradresavimas, priimantis vieną kliento adresą, veikia iš to kliento ir numeta bet kurį kitą šaltinį be žodžio.

Taisyklė, kurios paketų skaitiklis lygus nuliui, visai nėra kelyje, o skaitiklių skaitymas yra greičiausias būdas atskirti neteisingos grandinės problemą nuo neteisingos taisyklės problemos.

Vietinis peradresavimas, kai LAN nieko pakeisti negalima

SSH vietinis peradresavimas apeina visą klausimą. Jam nereikia maršruto LAN tinkle, kliento ugniasienės bendradarbiavimo ir niekur paskelbto prievado:

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

Tada paslauga atsiranda to kompiuterio, kuris laiko tunelį, localhost:3000, ir niekur kitur. Tai riba: viena darbo stotis, vienas prievadas, ir peradresavimas miršta kartu su sesija, nebent kažkas jį paleidžia iš naujo. Administratoriui, tikrinančiam bandomąją duomenų bazę, tai teisingas įrankis. Kamerai ar skaitytuvui, kurį turi pasiekti kiti žmonės, tai netinka, nes kiekvienam naudotojui reikėtų savo peradresavimo.

Prieš pridėdami dar vieną taisyklę patikrinkite abi kryptis

Vertimas palieka pėdsakus, ir juos skaityti geriau nei spėlioti. VPN hoste conntrack -L rodo, ar vertimas apskritai įvyko, iptables -t nat -L -n -v rodo, ar skaitikliai pajudėjo, o tcpdump -ni any port 3000 rodo, koks šaltinio adresas iš tikrųjų atvyko. Kliente ss -ltn patvirtina, kad klausytojas yra adresu, kurį tunelis gali pasiekti.

Tada pasirinkite formą, kurią paliekate. Vienas paskelbtas prievadas, maršrutas visam baseinui ir peradresavimas vienam administratoriui yra trys skirtingi įsipareigojimai, ir jų maišymas yra kelias, kuriuo veikianti sąranka tampa tokia, kurios po pusės metų niekas negalės paaiškinti. Užsirašykite, kuris adresas iš kur pasiekiamas, ir kitas žmogus, kuris tai derins, pradės nuo atsakymo, o ne nuo tunelio.