Pse një rrugë OpenVPN humbet ndaj një politike XFRM të strongSwan

Paketat mund të ndjekin një rrugë OpenVPN dhe gjithsesi të kapen nga një politikë IPsec, dhe ky kombinim duket si një gabim rrugëtimi nga çdo kënd përveç atij të saktë. Linux zgjidh një rrugë dhe më pas konsulton një bazë të dhënash të veçantë të politikave të sigurisë, kështu që një rrugë destinacioni më specifike nuk e zëvendëson një politikë XFRM që përputhet. Simptoma e dukshme është trafiku që largohet nga hosti dhe nuk arrin kurrë, ndërsa të dy tunelet raportojnë se janë të shëndetshëm. Tre opsione e zgjidhin, dhe cilin zgjidhni varet nga cila prej dy rrugëve është menduar të mbajë atë prefiks.

Dy vendime, jo një

Zgjedhja e rrugës përgjigjet një pyetjeje të ngushtë: cili hop i radhës dhe adresa burimore duhet ta mbajnë këtë paketë. Baza e politikave të sigurisë përgjigjet një tjetre: a kërkon kjo paketë mbrojtje IPsec, dhe nën cilët përzgjedhës. Të dyja ekzekutohen për të njëjtën paketë, dhe përmbushja e të parës nuk thotë asgjë për të dytën. Prandaj ndryshimi i një metrike ose shtimi i një rrugë statike mund ta lërë simptomën të paprekur.

Një përzgjedhës i gjerë IPsec është shkaku i zakonshëm. Një politikë që mbron 172.16.0.0/12 mbulon edhe 172.20.8.0/24, ku administratori mund të ketë ndërmend të arrijë përmes tunelit OpenVPN. Qëllimi ekziston vetëm në tabelën e rrugëtimit, dhe baza e politikave nuk e ka mësuar kurrë.

Trajtojeni këtë si një konflikt midis dy rrugëve të konfiguruara mbrojtjeje, jo si një garë midis dy metrikave. Korrigjimi i takon komponentit që u konfigurua me shtrirjen e gabuar.

Lexoni rrugën që kernel-i zgjedh në të vërtetë

Filloni me kërkimin që kryen kernel-i, duke përfshirë adresën burimore dhe çdo rregull politike që mund ta devijojë drejt një tabele tjetër. Një rrugë në tabelën kryesore mund të mos konsultohet kurrë nëse një rregull i mëparshëm zgjedh një tabelë tjetër, dhe përputhja e prefiksit më të gjatë vlen vetëm brenda tabelës që zgjedh një rregull.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

Komanda e fundit është ajo që ka rëndësi, sepse shtyp rrugën e zgjedhur së bashku me adresën burimore që kernel-i do të përdorte. Krahasoni atë dalje me përzgjedhësin me të cilin përputhet politika IPsec. Kur rruga tregon ndërfaqen OpenVPN dhe politika vazhdon të përputhet me të njëjtin palë, e keni riprodhuar konfliktin pa hamendësuar.

Mbani dumpp-et pa adresa të palidhura përpara se të arrijnë në një tiketë. Një tabelë rrugëtimi nga një host prodhimi mbart topologji të brendshme, dhe vetëm rreshtat që i përgjigjen pyetjes meritojnë të ngjiten.

Lexoni edhe politikën që zbatohet

Lista e politikave tregon drejtimin, përzgjedhësit dhe shabllonin që vendos çfarë ndodh me një paketë që përputhet. Lexoni së pari drejtimin dalës, pastaj anën hyrëse për trafikun e kthimit, sepse një përjashtim njëdrejtimësh prodhon një lidhje që fillon dhe nuk përfundon kurrë.

ip -s xfrm policy
swanctl --list-sas

Krahasoni përzgjedhësit në listë me prefikset që lidhja negocioi. Çaktivizimi i instalimit të rrugëve të strongSwan nuk i heq ato politika, dhe ndryshimi i një metrike nuk ndryshon cilin palë burimi dhe destinacioni mbron një politikë. Këto dy pseudo-korrigjime meritojnë të përjashtohen herët, sepse janë të parat që njerëzit provojnë.

Nëse lista nuk përmban asnjë politikë për prefiksin që prisnit, problemi është diku tjetër dhe tabela e rrugëtimit ndoshta thotë të vërtetën. Nëse përmban një politikë më të gjerë që mbulon prefiksin, e keni gjetur kapjen.

Tre opsione kur të dyja rrugët janë të ligjshme

Ngushtimi i përzgjedhësit IPsec është opsioni më i pastër kur prefiksi i gjerë ishte komoditet dhe jo kërkesë. Zvogëlimi i përzgjedhësit të trafikut në distancë në nënrrjetet që vërtet i përkasin pas IPsec e heq konfliktin për çdo host njëherësh, dhe kushton një rinovim çelësi, jo një komponent të re.

Një përjashtim passthrough është opsioni kirurgjik kur përzgjedhësi i gjerë duhet të mbetet. strongSwan mbështet një lidhje të veçantë, fëmija i së cilës përdor modalitetin pass, që i thotë kernel-it se trafiku që përputhet nuk duhet të përpunohet nga IPsec. Adresa e largët loopback e mban atë lidhje nga zgjedhja për bashkëmoshatarët hyrës, dhe përzgjedhësit duhet të përshkruajnë palën e vërtetë të autorizuar dhe jo gjithçka.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

Shembujt e konfigurimit të strongSwan dokumentojnë këtë lloj politike dhe konventën e bashkëmoshatarit loopback. Opsioni i tretë është një dizajn i bazuar në rrugëtim me ndërfaqe XFRM, që e lidh politikën me trafikun e rrugëtuar përmes një ndërfaqeje të emërtuar në vend të një përzgjedhësi global. Është migrim dhe jo rregullim, dhe trafiku duhet ende të përmbushë përzgjedhësit e negociuar.

Provojeni përjashtimin pa dobësuar pjesën tjetër

Pas ngarkimit të ndryshimit, provoni përjashtimin dhe një destinacion të zakonshëm që duhet të mbetet i mbrojtur. Kontrolloni të dy drejtimet, pastaj ulni tunelin OpenVPN dhe konfirmoni çfarë ndodh me trafikun e përjashtuar. Një përjashtim që e dërgon atë prefiks në hapësirë të hapur në heshtje kur tuneli është jashtë është një vendim politike që duhet ta merrni me qëllim, jo ta zbuloni gjatë një incidenti.

Shënoni cili prefiks përdor cilën rrugë dhe pse. Përndryshe inxhinieri i radhës që sheh një përzgjedhës të gjerë do të rihapë të njëjtin hetim, dhe përgjigja do të rrijë në një mesazh commit që askush nuk e lexon.