Përdoruesit në distancë nuk arrijnë sitin e dytë përmes hub-it VPN

Një përdorues në distancë lidhet me hub-in, arrin serverin e skedarëve në LAN-in e vetë hub-it dhe gjithçka duket në rregull. Pastaj hap një ndarje në 10.20.0.50 në selinë qendrore, ku hub-i arrin përmes një tuneli të veçantë sit-në-sit, dhe kërkesa skadon. Të dy tunelet janë lart dhe të dy numëruesit rriten, prandaj asnjë tunel nuk është i prishur. Kalimi përmes hub-it janë tre vendime rrugëtimi në tre pajisje, dhe një tunel mbart vetëm prefikset për të cilat u ndërtua. Ja rendi që kontrolloj, dhe komanda që tregon nëse çdo hap është i vërtetë.

Transiti kërkon tre kërkime, jo një tunel

Çdo pajisje bën përputhjen e vet të prefiksit më të gjatë dhe e harron atë. Laptopi duhet ta dërgojë 10.20.0.50 në tunel dhe jo te ruteri i tij lokal. Hub-i duhet të marrë një paketë që mbërriti në ndërfaqen e aksesit në distancë dhe t'ia dorëzojë ndërfaqes sit-në-sit. Selia qendrore duhet të dërgojë një përgjigje për adresën e përdoruesit përsëri përmes tunelit. Secili prej tre dështimeve duket njësoj në shfletues: heshtje.

Kjo është arsyeja pse testimi i secilit tunel veçmas provon kaq pak. Ping i adresës LAN të hub-it ushtron vendimin e parë, dhe ping i hub-it nga selia qendrore ushtron të tretin. Paketa që dështon e ka burimin grupin e përdoruesve dhe destinacionin sitin e dytë, prandaj shkruani fillimisht ato prefikse. Këtu grupi është 10.80.0.0/24, LAN-i i hub-it është 10.10.0.0/24 dhe selia qendrore është 10.20.0.0/24.

Shtyjeni prefiksin e largët te klienti në distancë

Në një server aksesi në distancë OpenVPN klienti i mëson rrugët në momentin e lidhjes. Pa push, një klient me tunel të ndarë e dërgon 10.20.0.50 te porta e vet dhe paketa nuk hyn kurrë në tunel.

push "route 10.20.0.0 255.255.255.0"

Një rrugë e shtyrë hyn në fuqi kur klienti lidhet, prandaj një përdorues që qëndron online nuk sheh asgjë derisa të rilidhet. Kontrolloni në klient: ip route get 10.20.0.50 në Linux, route print në Windows. Dalja duhet të emërtojë ndërfaqen e tunelit.

push nuk e ndihmon hub-in. Është një mesazh për klientin, jo një rrugë në server dhe jo një leje për përcjellje, prandaj një hub me rresht push të përsosur prapë e hedh rrjedhën një hop më vonë. Ky është shkaku i zakonshëm pse njerëzit përfundojnë se push dështoi.

Jepini hub-it një rrugë të vërtetë daljeje

Hub-i ka nevojë për hop-in e vet të ardhshëm për prefiksin e selisë qendrore. Në një tunel të rrugëtuar kjo është një rrugë e zakonshme përmes ndërfaqes sit-në-sit, dhe një komandë tregon si rrugën e zgjedhur ashtu edhe burimin e zgjedhur:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Kur krahu sit-në-sit është vetë OpenVPN, rruga mund të jetojë në atë konfigurim me adresën e tunelit të partnerit si portë: route 10.20.0.0 255.255.255.0 172.30.0.2. Porta nuk është opsionale. Nëse e lini jashtë, hop-i i ardhshëm bie në një vlerë të parazgjedhur të implementimit, e cila ndryshon midis një klienti me një pikë të largët dhe një hub-i me shumë partnerë.

IPsec i bazuar në politika është ndryshe: kernel-i i hub-it e dërgon paketën te porta e tij normale LAN dhe politika e kap atë në dalje, prandaj rruga e tunelit ose nuk bën asgjë ose e drejton trafikun përtej politikës. Vini re burimin në komandën më sipër, sepse 10.10.0.1 në vend të adresës së grupit do të thotë që kernel-i zgjodhi një adresë që ana e largët do ta refuzojë. As iroute nuk është përgjigjja; i tregon serverit cili klient zotëron një nënrrjet pas tunelit të vet, jo ku të dërgohet trafiku për një sit të tretë.

Zgjeroni anën e largët deri te grupi i përdoruesve

Selia qendrore tashmë mbulon LAN-in e hub-it, 10.10.0.0/24. Grupi i përdoruesve është një prefiks i dytë dhe duhet të jetë edhe në përzgjedhës, përndryshe asnjë politikë nuk mbulon një përgjigje të adresuar te 10.80.0.25. Çdo partner emërton të njëjtin çift grupesh prefiksesh nga ana e tij:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts i një pajisjeje është remote_ts i tjetrës. Kopjoni bllokun e hub-it në selinë qendrore dhe çifti përmbyset, prandaj SA fëmijë nuk ngrihet kurrë.

Sintaksa më e vjetër ipsec.conf përdor leftsubnet të ndarë me presje. Asociacioni i sigurisë në punë mban përzgjedhësit që negocioi, prandaj rivendosni tunelin pas redaktimit. Një përzgjedhës i ndryshuar në 10:00 dhe i testuar kundër një SA që u ngrit në 09:40 prapë dështon, ndërsa skedari i konfigurimit duket i saktë gjatë gjithë kohës.

Pastaj kontrolloni hop-in e fundit. ip route get 10.80.0.25 në skajin e largët duhet të tregojë në tunel. Nëse shërbimi përdor një ruter LAN si portën e tij të parazgjedhur, ai ruter ka nevojë edhe për rrugën e kthimit, përndryshe përgjigjja vdes atje. Ekzekutimi i tcpdump -ni eth1 host 10.80.0.25 në atë segment tregon nëse përgjigjja doli fare nga skaji.

Lejoni rrjedhën në hub

Përcjellja duhet të jetë e aktivizuar dhe rruga e lejuar. Kufizoni rregullat në dy prefikset në vend që të pranoni gjithçka midis ndërfaqeve.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Filtrimi i rrugës së kthimit është dështimi i heshtur pranë tij: kur dy krahët janë në ndërfaqe të ndryshme, rp_filter=1 mund ta hedhë përgjigjjen ndërsa numëruesi i rregullit të pranimit nuk lëviz fare. Krahasoni iptables -vnL FORWARD para dhe pas një përpjekjeje. Një rregull që nuk rritet kurrë nuk arrihet, prandaj shikoni një shtresë më poshtë në vend që ta rishkruani.

Nëse vetëm një grup ka nevojë për transit, vendosni rrugën në një skedar për klient nën client-config-dir në vend që të zgjeroni push-in global. Source NAT në hub gjithashtu heq nevojën për një rrugë kthimi në anën e largët, por fsheh adresën e përdoruesit, prandaj regjistrat e sitit të largët dhe rregullat e bazuara në adresa nuk i dallojnë më përdoruesit.

Verifikoni nga klienti, pastaj kthehuni mbrapsht në rend të kundërt

Testoni një portë TCP, jo vetëm ICMP, sepse ping-u mund të kalojë ndërsa shërbimi mbetet i bllokuar. nc -vz 10.20.0.50 445 dhe traceroute -n 10.20.0.50 nga klienti tregojnë nëse hop-i i dytë është adresa e tunelit të hub-it. Në hub, tcpdump -ni tun0 host 10.20.0.50 dhe i njëjti filtër në ndërfaqen sit-në-sit: një kërkesë në të dyja pa përgjigje në asnjërën e zhvendos problemin në anën e largët.

Pastaj testoni diçka që duhet të mbetet e bllokuar. Nëse një host ku grupi nuk duhet të arrijë kurrë përgjigjet gjithashtu, keni hapur më shumë se transiti dhe duhet t'i ngushtoni rregullat. Një hub që përcjell gjithçka te çdo degë kalon provën e parë dhe dështon në të dytën.

Mbani një listë kthimi, sepse katër objekte ndryshuan dhe tre harrohen lehtë: rruga e shtyrë, rruga e hub-it, përzgjedhësit dhe rregullat e murit të zjarrit. Anuloni ato në rend të kundërt, rivendosni SA dhe lejoni një përdorues të rilidhet. Një kthim i pjesshëm lë një rrugë që tregon një tunel që nuk përputhet më, dhe kjo lexohet më vështirë se heshtja fillestare. Manuali i OpenVPN 2.6 dokumenton push, route dhe iroute për versionin tuaj.