Tuneli i plotë në strongSwan kërkon 0.0.0.0/0 në të dyja anët

Një lidhje strongSwan që funksionon për një nënrrjet privat nuk do të mbajë trafik interneti vetëm sepse dikush redaktoi një rresht. Një tunel i plotë është një marrëveshje midis dy palëve për cilat adresa mbron child SA, dhe secila palë emërton palën tjetër në raport me veten. Bëni njërën anë të saktë dhe tjetrën të gabuar, dhe child SA ose nuk ngrihet ose ngrihet më e ngushtë sesa synohej. Pesë kontrollet më poshtë ndjekin atë marrëveshje nga klienti, përmes portës, deri në internet.

Kontrolloni fillimisht përzgjedhësin e klientit

Klienti përshkruan atë që dëshiron të mbrojë në anën e largët si remote_ts, dhe gjithçka që dërgon vjen nga adresa e tij e caktuar. Për trafikun e internetit ajo vlerë duhet të mbulojë destinacionet që përdoruesi do të arrijë vërtet, që në praktikë do të thotë i gjithë hapësira IPv4. Një klient që ende liston një nënrrjet kërkon një tunel të ndarë, sido që të quhet profili në ndërfaqe. Ana e burimit është zakonisht dynamic sepse adresa caktohet në kohën e lidhjes. Një burim fiks i shkruar atje prishet sapo ndryshon grupi i adresave.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Fragmenti nuk është skedar i plotë lidhjeje, dhe ky supozon se vërtetimi, identitetet dhe grupi i adresave virtuale janë konfiguruar tashmë. Përzgjedhësi i burimit të klientit dhe adresa që cakton serveri duhet ende të përputhen, përndryshe child SA ngrihet me një shtrirje që asnjëra palë nuk e priste. Ngarkojeni me swanctl --load-all dhe lexoni daljen përpara se të supozoni sukses. Një skedar që analizohet mund të refuzohet ende për një përzgjedhës që nuk mbivendoset me propozimin e palës tjetër.

Kontrolloni përzgjedhësin e portës në anën e saj

Porta lexon të njëjtin koncept nga drejtimi i kundërt. Destinacionet e internetit janë lokale për portën, kështu që local_ts i saj është ai i gjerë dhe remote_ts përshkruan grupin e klientëve. Ky përmbysje është gabimi më i zakonshëm në një konfigurim tuneli të plotë, dhe i mbijeton rishikimit sepse të dy rreshtat duken të besueshëm veçmas.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Kopjimi i fragmentit të klientit në skedarin e portës prodhon një çift përzgjedhësish që nuk përshkruan asgjë të dobishme, sepse të dyja palët do të kërkonin të njëjtin rol. Udhëzuesi i përcjelljes i strongSwan dokumenton në mënyrë eksplicite çiftimin e klientit dhe portës, dhe ia vlen ta lexoni pranë skedarit të lidhjes dhe jo pas dështimit. Skedari i portës ka nevojë edhe për përkufizimin e grupit të adresave të cilit i referohet remote_ts. Një përzgjedhës që emërton një grup që nuk ekziston ngarkohet pa ankesë dhe dështon në lidhje.

ipsec.conf i vjetër përdor role majtas dhe djathtas me çelësa të ndryshëm, dhe një rresht rightsubnet nuk është zëvendësim i drejtpërdrejtë për vlerën e swanctl. Mbani dy sintaksat në skedarë të veçantë në vend që të ngjitni njërën brenda tjetrës. Përzierja e tyre në një drejtori është mënyra se si një lidhje funksionale kthehet në heshtje pas një rindezjeje.

Kontrolloni child SA të negociuar, jo skedarin

Një konfigurim i ruajtur provon qëllimin dhe asgjë më shumë. Pala tjetër mund të ngushtojë atë që u kërkua, dhe një child SA ekzistues nuk zëvendësohet thjesht sepse skedari nën të ka ndryshuar. Konfirmoni çfarë është instaluar vërtet përpara se të ndryshoni diçka tjetër.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Komanda e parë tregon çfarë ngarkoi daemon-i, e dyta tregon child SA të vendosura dhe e treta politikat që do të zbatojë kernel-i. Nëse skedari thotë 0.0.0.0/0 dhe lista tregon një nënrrjet, negocimi e ngushtoi shtrirjen dhe rileximi i skedarit nuk do ta shpjegojë. Përfundoni child, rinisni atë dhe krahasoni përsëri të tre daljet. Një child që kthehet me të njëjtën shtrirje të ngushtë ngushtohet nga ana e largët dhe jo nga skedari lokal, dhe ky është një bisedë me administratorin tjetër në vend të një ndryshimi lokal.

Lexoni të dy drejtimet në listën e politikave, sepse një tunel që instalon një drejtim dhe jo tjetrin është një problem rrugëtimi në kostum konfigurimi. Politikat përpara dhe prapa duhet të emërtojnë të njëjtin çift përzgjedhësish në imazh pasqyre, dhe pasqyra që mungon është një defekt në daemon ose në propozim, jo në tekstin e përzgjedhësit.

Kontrolloni përcjelljen dhe rrugën e kthimit

Një përzgjedhës lejon trafikun drejt portës, por nuk e bën portën ta rrugëtojë atë trafik më tej. Përcjellja duhet të jetë e aktivizuar, firewalls duhet të lejojë rrjedhën dhe përgjigja duhet të gjejë rrugën përsëri drejt grupit të klientëve. Këto janë tre kërkesa të veçanta, dhe secila dështon me një simptomë tjetër. Një rregull përcjelljeje që mungon sillet si një vrimë e zezë, ndërsa një rrugë kthimi që mungon sillet si një tunel njëdrejtimësh.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Adresat private të klientëve zakonisht kanë nevojë për përkthim burimi të qëllimshëm përpara se të mund të largohen nga një ndërfaqe publike, ndërsa një alokim i rrugëtuar shprehimisht kërkon trajtim tjetër. Nëse NAT është i përfshirë, mbani përjashtimet e mbështetura nga zbatimi, që trafiku që duhet të inspektohet nga një politikë sigurie të mos përkthehet përtej saj. Një rregull masquerade i gjerë i kopjuar nga një portë tjetër ndryshon shumë më shumë rrjedha sesa synonte autori i tij. Shkruani rregullin vetëm për grupin e klientëve dhe lini një koment që shpjegon pse ekziston.

Në klient, konfirmoni rrugët që instaloi backend-i dhe jo rrugët që supozuat. Një menaxher me instalimin e rrugëve të çaktivizuar ka nevojë për një dizajn rrugëtimi të mirëmbajtur me dorë, dhe ai dizajn duhet përditësuar sa herë që ndryshon tuneli. Kontrolloni tabelën e rrugëtimit pas rikthimit të lidhjes, jo vetëm pas një nisjeje të freskët.

Kontrolloni çfarë tuneli ende nuk mbulon

Çifti i përzgjedhësve mbulon IPv4 dhe asgjë tjetër. IPv6, DNS dhe çdo politikë në nivel aplikacioni janë vendime të veçanta që një përzgjedhës i gjerë IPv4 i injoron në heshtje. Një tunel që mbart çdo paketë IPv4 mund të rrjedhë ende çdo kërkim emri.

Deklaroni shprehimisht rrugën DNS të synuar, sepse një tunel i plotë që ende zgjidh emrat përmes resolver-it lokal rrjedh kërkesat jashtë tunelit dhe prish emrat privatë. Nëse klientit i caktohet një adresë IPv6, ajo familje adresash kërkon të njëjtin trajtim, përndryshe host-i do të preferojë një rrugë që tuneli nuk e mbron. Testoni me një emër të cilit vetëm ana private mund t'i përgjigjet, dhe trajtoni një përgjigje publike si rrjedhje.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Konfirmoni zinxhirin me ato dy komanda plus përzgjedhësit e negociuar nga lista më sipër. Nëse traceroute tregon ruterin lokal si kërcimin e parë, trafiku nuk po përdor tunelin, çfarëdo që pretendojnë përzgjedhësit. Aksesi në internet është i plotë vetëm kur trafiku i zgjedhur pranohet, përcillet dhe kthehet përmes portës së projektuar. Gjetja e 0.0.0.0/0 në një profil është fillimi i atij zinxhiri, jo prova e tij.