VPN prievado atidarymas neleidžia klientams pasiekti LAN

Tunelis pakyla, klientas autentifikuojasi, bet LAN už šliuzo lieka nematomas. Taisyklė, kuri turėjo tai ištaisyti, leidžia VPN prievadą ir veikia tiksliai taip, kaip parašyta, nes ji valdo paketus, adresuotus pačiam šliuzui. Kliento srautas į mazgą už šliuzo turi kitą tikslą ir kitą grandinę. Sėkmingas prisijungimas nepakeičia to, kurią iš dviejų grandinių tikrina branduolys.

Dvi grandinės, du skirtingi tikslai

Paketo likimą lemia tai, kur jis eina, o ne kaip atėjo. Srautas į šliuzo adresą pristatomas vietoje ir vertinamas įvesties taisyklėmis. Srautas, kurį šliuzas persiunčia toliau, vertinamas persiuntimo taisyklėmis. Ta pati tunelio sąsaja gali kurti abiejų tipų paketus, todėl viena taisyklė negali apimti abiejų darbų.

Visas mitas vienu sakiniu: leisti klausytoją nieko nesako apie tinklo už jo leidimą. Tai du atskiri sprendimai su atskirais įrodymais, o sąsajos pavadinimas ant abiejų jų nesujungia.

Ką iš tikrųjų leidžia klausytojo taisyklė

Klausytojo paketai baigiasi VPN procese, ir būtent tai leidžia apskritai sukurti tunelį. Šliuzo administravimo puslapis ir vietinis diagnostinis atsakymas taip pat naudoja savo įvesties kelią, todėl bandymas į šliuzą pavyksta, o viskas už jo žlunga. Abu rezultatai teisingi ir nė vienas nėra apie LAN.

Kai procesas dekapsuliuoja kliento srautą kitam tikslui, paketas patenka į persiuntimo kelią ir ten reikia leidimo. Sėkminga autentifikacija nusprendžia, kas yra klientas; ji nenusprendžia, kur klientas gali eiti. Du klausimai turi skirtingus savininkus, skirtingus žurnalus ir skirtingus klaidų pranešimus.

Tikrinkite iš kliento, niekada iš šliuzo

Šliuze sukurtas bandymas eina savo išvesties keliu ir gali pavykti, kai persiuntimo kelias uždarytas. Pradėkite bandymą iš kliento ir stebėkite abu srauto galus.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Jei užklausa pasirodo tun0, o į tikslą niekas nepatenka, paketas išmetamas po atvykimo, tai rodo persiuntimo taisykles arba paties tikslo filtravimą. Jei tun0 nieko nepasirodo, klientas net nesiunčia jo į tunelį, o problema yra kliento maršrutizavime, ne šliuzo politikoje. Palyginkite su užklausa, kuri išeina teisingai ir nieko negrąžina, tai yra grįžimo kelio atvejis.

Persiuntimas reikalauja trijų dalykų, ne vieno

Branduolio persiuntimas turi būti įjungtas, filtro taisyklė turi priimti srautą, o tikslas turi būti pasiekiamas su keliu atsakymui grįžti. Jei trūksta bent vieno, tyla kliento požiūriu yra tokia pati.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Skaitykite tris išvestis kartu. Nulis pirmoje padaro kitas dvi nesvarbias, o antroje esanti numatytoji atmetimo politika meta kliento paketus, kol paties šliuzo srautas veikia toliau. Trečia išvestis parodo, kodėl klausytojo taisyklė niekada nebuvo problema.

Laikykite du taisyklių rinkinius dokumentacijoje atskirai

Rašykite klausytojo taisyklę ir persiunčiamos paslaugos taisyklę atskiromis eilutėmis, su atskirais savininkais ir priežastimis. Kai VPN prievadas pasikeičia ar paskelbiama nauja paslauga, tas atskyrimas neleidžia vienam pakeitimui tyliai išplėsti kito.

Užuot laikę kiekvieną autentifikuotą partnerį patikimu LAN nariu, naudokite siauras taisykles tiems klientų diapazonams ir paslaugoms, kurioms jų reikia. StrongSwan persiuntimo pastabos aprašo tos pačios ribos grįžimo maršruto ir vertimo pusę, o tai vėl trečias sprendimas.

Galiausiai laikykite sluoksnius tiesiai, kai vartotojas atmetamas. Jei užklausa pasiekia mazgą, o programa atmeta paskyrą, taisykite programos leidimą tame sluoksnyje; persiuntimo išplėtimas negali suteikti failų bendrinimo kredencialų ir išplės prieigą visiems kitiems, kurie sėkmingai prisijungia.