VPN maršrutas ar ugniasienės taisyklė: kuri numeta paketą?

Tam pačiam paketui įvyksta du nepriklausomi sprendimai, ir bet kuris iš jų gali tyliai užbaigti užklausą. Maršruto paieška parenka sąsają ir kitą šuolį, tada paketų filtras nusprendžia, ar ta kombinacija leidžiama. Laiko skirtasis laikas jums pasako, kad vienas iš dviejų atmetė, o ne kuris. Eikite etapais iš eilės ir taisymas paprastai nustoja būti spėjimu.

Du sprendimai, vienas paketas, du savininkai

Maršruto paieška pirmiausia pasikonsultuoja su politikos taisyklėmis, paskui su lentele, į kurią jos nurodo, ir parenka tiksliausią priešdėlį, atitinkantį paskirties vietą. Klientas, įdiegęs tunelio maršrutą, valdo tą sprendimą, ir niekas ugniasienės taisyklėje negali jo pakeisti. Kai paieška nurodo netikėtą vietą, kiekvienas vėlesnis etapas dirba su netinkamu paketu.

Filtravimas yra atskiras. Linux pagrindiniame kompiuteryje netfilter kabliai skirsto srautą pagal tai, kam paketas skirtas: išvestis palieka mašiną, įvestis joje baigiasi, persiuntimas praeina pro ją. Šliuzui, kuris priima VPN klientus ir nukreipia juos į LAN, reikia persiuntimo kelio, ir tai yra būtent ta grandinė, kurią dauguma numatytųjų konfigūracijų palieka tuščią.

Šaltinio pasirinkimas priklauso tam pačiam sprendimui, ir čia slypi dauguma neatitikimų. Branduolys renkasi šaltinio adresą iš išeinančios sąsajos, nebent maršrutas nurodo vieną, todėl filtro taisyklė, parašyta LAN potinkliui, niekada nesutampa su paketu, išeinančiu su tunelio adresu.

Perskaitykite, ką paieška iš tikrųjų pasirinko

Atspausdinkite sprendimą, o ne jį spėkite. Toliau pateikta komanda išsprendžia maršrutą, kurį branduolys naudotų tai paskirties vietai, įskaitant sąsają ir šaltinį, kurį jis pasirinktų:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN klientai dažnai įdiegia politikos taisykles prioritetais žemiau pagrindinės lentelės, todėl švari pagrindinė lentelė savaime nieko neįrodo. Palyginkite taisyklių prioritetus su lentelėmis, kurias jos pasirenka, ir patikrinkite, ar tunelio maršrutas išlieka po prisijungimo iš naujo, o ne pridedamas ranka vieną kartą.

Politika pagrįstas IPsec prideda trečią atitikimo etapą, kurio maršrutizavimas neapima, kaip aprašo strongSwan persiuntimo pastabos tunelio ir transporto sąrankoms. Saugumo politika parenka srautą pagal priešdėlį ir protokolą, o maršrutas tik nusprendžia, kur eitų neapsaugotas paketas. Potinklis, kuris maršrutizuojamas, bet neturi atitinkančio selektoriaus, arba lieka neapsaugotas, arba išmetamas, priklausomai nuo konfigūracijos, ir nė vienas rezultatas neatrodo kaip ugniasienės problema. Atspausdinkite politiką ir palyginkite jos selektorius su priešdėliais, kuriuos tikėjotės, kad tunelis perneš.

Filtravimas taikomas kabliuke, o ne maršrute

Taisyklė, leidžianti VPN klausytoją, yra taisyklė apie srautą, adresuotą pačiam šliuzui. Ji nieko nesako apie klientus, pasiekiančius kompiuterius už to šliuzo, nes persiunčiamas srautas eina kita grandine. Taisyklių rinkinio skaitymas kaip vieno plokščio sąrašo yra įprasta priežastis, kodėl teisingai atrodanti taisyklė niekada nesuveikia.

Skaitikliai greitai išsprendžia klausimą. Taisyklė su nuliniu paketų skaičiumi niekada nebuvo pasiekta, o tai rodo netinkamą grandinę, netinkamą sąsają ar ankstesnį numetimą. Taisyklė su augančiu skaičiumi pagal numetimo politiką yra ta riba, kurios ieškojote, ir paketas išmetamas, o ne maršrutizuojamas neteisingai.

Siųskite zondą keliu, kurį naudoja klientas

Testai, atliekami pačiame šliuze, eina per išvestį ir įvestį su paties šliuzo šaltinio adresu. Tai kitas kelias nei kliento persiunčiama užklausa, todėl sėkmingas vietinis curl įrodo mažiau, nei atrodo. Tikrinkite iš mašinos, kuri nepavyksta, arba aiškiai prisekite sąsają ir šaltinį.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Užfiksavimas abiejuose galuose atskiria likusius atvejus. SYN, kuris palieka klientą ir niekada neateina, reiškia maršrutizavimą, šifravimą ar priešvėjinį prieigos sąrašą. SYN, kuris ateina ir negauna atsakymo, reiškia paslaugą arba jos pagrindinio kompiuterio filtrą, ir tunelis niekada nebuvo problema.

Grįžtamasis srautas nusipelno atskiro žvilgsnio. Asimetrinis maršrutizavimas ir atvirkštinio kelio filtravimas išmeta atsakymus, atvykstančius per netinkamą sąsają, o tai pasireiškia kaip vienkryptis ryšys, o ne užblokuotas prievadas. Patikrinkite sysctl reikšmę prieš kaltindami ugniasienę dėl simptomo, kurio ji nesukėlė.

Žurnalų rašymas veikia kaip antra nuomonė, o ne pirmas žingsnis. Laikinas žurnalo įrašas persiuntimo grandinėje įvardija sąsają ir adresus, kurie jį pasiekė, ir jį lengva pašalinti vėliau. Palikite jį visam laikui ir sukūrėte žurnalų apimties problemą, o ne atsakymą.

Įdėkite kiekvieną pakeitimą ten, kur jis išlieka po prisijungimo iš naujo

Maršrutas, pridėtas su ip route add, gyvuoja tol, kol sąsaja nukrenta. Išsaugokite jį ryšio profilyje: NetworkManager priima papildomus maršrutus ryšyje, o netplan išlaiko juos tarp įkrovimų. Ta pati taisyklė taikoma kliento pusės ugniasienės išimčiai, kuri dingsta po kito perkrovimo.

Serverio pusės taisyklės priklauso konfigūracijos failui, kurį paslauga įkelia paleidžiant, o ne interaktyviai sesijai, kuri baigiasi, kai ją uždarote. Parašykite taisyklę, perkraukite ir patvirtinkite, kad skaitiklis pajudėjo, nes perkrovimas, atmetęs sintaksę, tyliai palieka seną taisyklių rinkinį vietoje.

Tada pakartokite pirminę programos užklausą nuo pradžios iki pabaigos ir užrašykite, kuris sluoksnis pasikeitė. Maršruto taisymas, kuriam taip pat reikėjo filtro pakeitimo, vis tiek nepavyks, o antrą nesėkmę skaityti daug lengviau, kai žinote, kad pirmosios nebėra. Užsirašykite datą ir kliento versiją šalia rezultato, nes maršrutizavimo ir filtravimo numatytosios reikšmės abi keičiasi tarp versijų. Laikykite tą pastabą biliete, kad kitas žmogus pradėtų ten, kur jūs sustojote, o ne kartotų dviejų etapų kelią.