Ar turėtumėte taikyti SNAT porto peradresavimui į VPN potinklį?

Porto peradresavimas į prieglobą, kuri yra už paties maršrutizatoriaus VPN kliento, nepavyksta taip, kad atrodo kaip ugniasienės problema, nes užklausa aiškiai atvyksta. Paslauga įrašo ryšį, klientas laukia, ir nieko negrįžta. Paskirties vertimas atliko savo darbą; grįžtamasis paketas yra ta dalis, kuri dingo. Viena selektyvi šaltinio NAT taisyklė maršrutizatoriuje tai ištaiso, o įdomiausia dalis yra nuspręsti, kokia siaura ši taisyklė gali būti.

Kodėl atsakymas pasirenka kitą kelią

Porto peradresavimas perrašo, kur paketas eina, niekada — iš kur jis atėjo. Interneto kliento adresas išlieka šaltinio lauke visą kelią per tunelį, todėl tolima paslauga mato nepažįstamąjį ir atsako vieninteliu būdu, kurį žino: per savo numatytąją šliuzą. Ta šliuzas yra VPN koncentratorius kitoje pusėje, kuris neturi maršruto atgal į savavališką viešą adresą.

Stebėkite įrašą tunelio sąsajoje ir asimetrija akivaizdi: užklausos paketai išeina, į vidų nieko. Peradresavimo grandinė leido srautą, o tunelis jį pernešė, tad atmetimas įvyksta po to, kai tolima priegloba jau pasirinko grįžimo kelią.

Šaltinio taisyklė, pakankamai siaura, kad ja pasitikėtumėte

Padarykite maršrutizatorių šaltiniu, į kurį atsako tolima priegloba. Šioje schemoje WAN adresas yra 203.0.113.24, LAN yra 192.168.88.0/24, maršrutizatoriaus tunelio adresas yra 172.20.5.1, o paslauga atsako 172.20.5.40:8443. Toliau pateikta taisyklė sutampa su paketu po paskirties vertimo, todėl ji nurodo išverstą adresą, o ne viešąjį. Niekas joje nepriklauso nuo kliento adreso, ir būtent tai yra esmė.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Kiekvienas tos eilutės atitikimas egzistuoja tam, kad perrašymas liktų vietinis vienai paslaugai viename tunelyje. Pašalinkite sąsają arba portą ir perrašote daugiau srauto, nei reikalauja problema, ir taip tiksli pataisa tampa mįsle kitam žmogui.

Kada bendra maskarada yra sąžiningas pasirinkimas

Jei maršrutizatorius peradresuoja daug paslaugų į tą patį VPN potinklį, taisyklė kiekvienai paslaugai tampa sąrašu, kurio niekas neprižiūri. Maskuoti viską, kas išeina iš tunelio sąsajos, yra paprasčiau ir nuspėjamiau, už tai, kad pradinis klientas paslepiamas nuo kiekvienos prieglobos kitoje pusėje. Pasirinkite tai, kai ten esantys žurnalai nenaudojami priskyrimui; palikite siaurą taisyklę, kai naudojami.

Abu variantai irgi nepavyksta skirtingai. Trūkstama siaura taisyklė sugadina vieną paslaugą; plati maskarada, kuri atitinka per daug, gali tyliai perrašyti srautą, kuris jau veikė, įskaitant paties maršrutizatoriaus išeinančius ryšius.

Prieš publikuodami patikrinkite skaitiklius

Taisyklės, kurios niekada nesutampa, atrodo vienodai kaip veikiančios taisyklės, kol nesuskaičiuosite paketų. Perskaitykite lentelę su baitų skaitikliais prieš prisijungiant bet kuriam klientui, tada prisijunkite iš tinklo, kuris nėra LAN, ir perskaitykite dar kartą. Du skaitymai yra tai, kas spėjimą paverčia faktu. Paskelbkite peradresavimą tik po to, kai pajuda antrasis.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Nulis skaitiklis šaltinio taisyklėje po tikro ryšio reiškia, kad atitikimas neteisingas, dažniausiai todėl, kad paskirtis arba portas neatitinka paketo po vertimo. Jei skaitiklis kyla, bet klientas vis dar pasiekia laiko limitą, grįžimo kelias sutaisytas ir kažkas kita meta atsakymą, todėl toliau pažiūrėkite į peradresavimo politiką kitoje pusėje. Priėjimas per plaukų segtuką iš LAN vidaus yra atskira problema ir jam reikia savo taisyklės, o ne platesnės šios versijos.