Paskelbti LAN paslaugą pačiu VPN šliuzo adresu

LAN įrenginio pristatymas vienu iš savo šliuzo tunelio adresų tereikia vienos NAT eilutės. Ryšys vis tiek nepavyksta, nes atsakantis įrenginys nežino, kad kliento adresas pasiekiamas per tą šliuzą. Peržiūrėkite paketą nuo kliento į vidų, tada peržiūrėkite atsakymą atgal į išorę, ir trūkstama pusė taps akivaizdi.

Pradėkite nuo kliento požiūrio

Šio pavyzdžio klientas yra VPN telkinyje 10.62.0.0/24 ir jungiasi prie 10.62.0.1 per 8080 prievadą. Tas adresas priklauso pačiam šliuzui, todėl paketas patenka į šliuzo branduolį, o ne pas kitą partnerį. Už šliuzo LAN yra 172.21.4.0/24. Šliuzas turi 172.21.4.10, o įrenginys, kuris iš tikrųjų aptarnauja HTTP, yra 172.21.4.40.

Adresas, priklausantis kitam VPN partneriui, nėra keičiamas su šliuzo paslaugos adresu. Jei klientas jungiasi prie partnerio adreso, jokia šliuzo taisyklė išvis nedalyvauja, ir visas šis perėjimas yra netinkamas atvejis.

Apibrėžkite paskirties vertimą sąmoningai

Siaura versija pateikia vieną prievadą ir perrašo tik paskirtį. Paketas išlaiko protokolą ir šaltinį, ir būtent tai daro likusią perėjimo dalį įdomią.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Taisyklė be protokolo ir prievado kriterijų yra plati versija: ji išlaiko bet kurį kliento pasirinktą prievadą ir keičia tik adresą. Tai teisėta, kai ketinama pateikti visą mazgą, ir neteisinga, kai ketinta viena paslauga. Perskaitykite taisyklę atgal ir patvirtinkite sąsajos pavadinimą. DNAT taisyklė neteisingoje sąsajoje nieko neatitinka, o tai duoda tokią pačią laiko limitą kaip trūkstama taisyklė ir sugaišta valandą žiūrint į įrenginį.

Tegul persiuntimo riba sutaria

Vertimas keičia antraštę, bet nesuteikia leidimo. Esant numatytajai atmetimo politikai, persiųstas srautas turi savo leidimą, o grįžimo kryptis turi turėti nustatyto ryšio taisyklę, kurią jūsų politika tikriausiai jau turi.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Besąlyginis leidimas kiekvienam DNAT srautui yra platesnis nei šis projektas ir leis ir susiejimus, kuriuos vėliau pridės kas nors kitas. Įvardykite paskirtį ir prievadą, o likusią dalį palikite uždarytą. Jei persiuntimo taisyklės skaitikliai lieka nuliu, o NAT skaitikliai kyla, paketas atmetamas prieš jūsų taisyklę. Skaitykite grandinių tvarką, o ne pridėkite antrą kopiją.

Įrenginys turi kaip nors atsakyti

Po vertimo įrenginys mato šaltinį 10.62.0.0/24 viduje. Jo atsakymas eina į numatytąjį šliuzą, kuris yra LAN maršrutizatorius, o ne VPN šliuzas, nebent kažkas jam pasakytų kitaip. Du išdėstymai tai ištaiso, ir jie nėra lygiaverčiai. Maršrutas įrenginyje arba LAN maršrutizatoriuje siunčia 10.62.0.0/24 į 172.21.4.10 ir išlaiko kliento šaltinį. Apribotas šaltinio vertimas vietoj to paslepia klientą už šliuzo LAN adreso.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Rinkitės pagal tai, ko reikia paslaugai. Politika pagal klientą ir prasmingi žurnalai nori maršrutizuotos formos; įrenginys, kuriam negalima duoti maršruto, arba paslauga, kuri tiesiog turi matyti LAN adresą, rodo į išverstą formą. Nesiekite visuotinės masquerade taisyklės, kad veiktų vienas atsakymas. Ji paslepia kiekvieną klientą nuo kiekvienos paskirties ir tyliai sulaužo politikas, priklausančias nuo šaltinio adresų.

Neišbandykite iš paties šliuzo

Užklausa, sugeneruota šliuze adresui 10.62.0.1, išeina per OUTPUT grandinę, o ne per gaunamąją PREROUTING. Jos nepavyks ar sėkmė nieko nesako apie taisyklę, atgręžtą į klientą, ir taip žmonės daro išvadą, kad veikianti taisyklė sulaužyta.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Paleiskite tikrą kliento užklausą ir perskaitykite abu. conntrack įrašas rodo pritaikytą vertimą, o fiksavimai rodo, ar užklausa perėjo į LAN, ir ar atsakymas grįžo link tunelio. Po taisyklių pakeitimų naudokite naują ryšį, nes esama būsena išlaiko ankstesnį susiejimą ir toliau nepavyks senuoju būdu. Tada patvirtinkite visą pokalbį: įrenginio adresas, persiuntimo leidimas ir atsakymo maršrutas visi apibūdina tą patį srautą.