Shtimi i nje nenrrjeti te dyte ne VPN mes lokacioneve: dy rruge
Tunelet e bazuara ne politike kerkojne perzgjedhes perputhes ne te dy anet; ato te bazuara ne rruge kerkojne nje rruge. Zgjidhni rrugen e duhur dhe rregulloni fillimisht rrugen e kthimit.
Shtimi i nje nenrrjeti te dyte ne nje tunel mes lokacioneve qe funksionon merr pese minuta ne nje projekt dhe pothuajse gjithe pasditen ne tjetrin. Kur tuneli instalon rruge per prefikset qe permendni, shtoni nje rruge dhe trafiku e ndjek. Kur negocion nje cift fiks perzgjedhesish, prefiksi i ri mbetet i pambrojtur derisa te dy anet te bien dakord per nje cift perputhes. Tri gjerа vendosin: çfare pershkruajne vertet konfigurimet e seciles ane, nese trafiku i negociuar ngushtohet ne çiftin me te vogel perputhes, dhe kujt i takon rruga e kthimit per diapazonin e ri.
Lexoni kernelin, jo etiketen e statusit
Nje tunel qe raporton lidhje ka instaluar te pakten nje shoqate femije, por jo domosdoshmerisht ate qe mendoni. Ne Linux kerneli tregon çfare zbatohet: ip xfrm policy numeron çiftet e perzgjedhesve dhe swanctl --list-sas (ose ipsec statusall i vjeter) tregon per çfare u moren vesh anet, perfshire perzgjedhesit e trafikut ne çdo drejtim. Nese prefiksi i ri nuk eshte ne asnjerin, ai eshte i pambrojtur, çfaredo qe thote skedari i konfigurimit.
Krahasojeni me tabelen e rrugeve. Ne nje skeme te bazaar ne rruge, pajisja e tunelit eshte hapi tjeter per prefikset e mbrojtura. Nje skeme e bazaar ne politike shpesh nuk ka rruge te veçante per nenrrjetin e larget, vetem rrugen e paracaktuar, sepse politika zgjedh trafikun dhe jo tabela.
Te bazuara ne politike: te dy anet duhet te listojne prefiksin e ri
Ne termat e strongSwan perzgjedhesi rri ne local_ts dhe remote_ts nen konfigurimin femije, pasardhesit e leftsubnet dhe rightsubnet. Prefiksi i ri duhet te shfaqet ne te dy anet si ne pasqyre: ate qe lokacioni A e quan lokal, lokacioni B e quan te larget. Mosperputhja rrallë jep nje gabim te paster. Anet ngushtohen ne kryqezim, prefiksi i vjeter vazhdon te punoje dhe vetem ai i ri deshton ne heshtje.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyNe pfSense ose OPNsense kjo do te thote nje hyrje e dyte Phase 2 qe çiftezon nenrrjetin e ri lokal me ate te larget, dhe pastaj aplikim. Mbani hyrjen e vjeter; zevendesimi e zhvendos nenrrjetin origjinal ne vend qe ta shtoje. Nese nje Phase 2 ekzistuese mbulon tashme nje superrrjet si 0.0.0.0/0 ose nje diapazon te permbledhur, mos shtoni nje hyrje me te ngushte prane saj: perzgjedhesit e mbivendosur instalojne politika konkurruese dhe rendi i vleresimit vendos fituesin.
IKEv1 e ben çdo çift nenrrjetesh Phase 2 te vetin, dhe ana qe pranon nje çift per shkembim i hedh poshte te tjeret. IKEv2 mund te mbaje disa çifte perzgjedhesish ne nje femije, por vetem nese te dy implementimet i pranojne. Lista nga swanctl --list-sas eshte e verteta; ajo qe shkruat eshte nje kerkese.
Te bazuara ne rruge: rruga eshte politika
Nje nderfaqe XFRM ose nje pajisje VTI mbart trafikun sipas tabeles se rrugeve. Drejtoni prefiksin e ri te pajisja ne te dy lokacionet, dhe zbatohet gjendja e lidhur me transformimin e nderfaqes. Nuk ka çift perzgjedhesish per te sinkronizuar, prandaj ky projekt shkallezohet me mire kur nenrrjetet shtohen. Udhëzuesi i strongSwan per perçillje trajton anen e kernelit ne detaje.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard shkon me tej. AllowedIPs eshte njekohësisht lista e lejeve kriptografike dhe, permes wg-quick, hyrja ne tabelen e rrugeve. Shtoni prefiksin vetem ne njerin ane dhe do te merrni shtrengim duarsh, paketa dalese dhe heshtje, sepse ana e larget i hedh poshte paketat qe nuk e kane burimin ne listen e saj. Forma wg set zevendeson gjithe listen, prandaj perseritni prefikset qe punonin me pare, perndryshe do te priten:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0Urdhri i dyte nuk eshte opsional kur keni perdorur wg set ne vend te wg-quick. Kerneli e pranon listen e re menjehere, por asgje nuk i shton nje rruge, prandaj trafiku i krijuar lokalisht del ende nga porta e paracaktuar. Ky eshte shkaku me i zakonshem qe nje nenrrjet i ri WireGuard punon nga hosti i tunelit dhe jo nga nje laptop.
Rruga e kthimit deshton me shpesh sesa tuneli
Hostet ne nenrrjetin e ri te larget duhet t i dergojne pergjigjet permes portes VPN. Kur ajo porte nuk eshte ruteri i tyre i paracaktuar, pergjigja shkon te ruteri i LAN-it, i cili ose e hedh poshte ose e perçell ne internet me nje adrese burimore private. Testoni nga nje host ne anen e larget, jo nga porta: ip route get 10.30.20.15 ne Linux ose Find-NetRoute -RemoteIPAddress 10.30.20.15 ne PowerShell tregon hapin tjeter qe hosti perdor vertet. Nese pergjigja nuk eshte pika fundore e tunelit, shtoni atje nje rruge statike per prefiksin e ri.
NAT-i burimor ne lokacionin qe i mungon rruga e kthimit eshte nje alternative e ligjshme dhe menyra se si shume vendosje hub-and-spoke shmangin prekjen e çdo serveri. Zbatojeni edhe per prefiksin e ri ne porten e anes se destinacionit:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEKostoja eshte reale. Regjistrat e larget nuk tregojne me adresa burimore individuale, dhe rregullat e firewall-it te bazuara ne nenrrjetin origjinal bashkohen ne nje rregull per porten. Zgjidhni kete me qellim, jo sepse mungonte nje rruge.
Firewall-et jane gjysma tjeter e rruges se kthimit. Pajisjet e bazuara ne zona nuk e zgjerojne automatikisht zonen e nje nderfaqeje tuneli ekzistues per nje nenrrjet te ri, dhe nje rregull i shkruar per prefiksin e vjeter nuk perputhet. Shtoni nenrrjetin e ri ne zone ose ne çiftin e rregullave ne te dy drejtimet perpara se te fajesoni IPsec.
Vendosni me tri pyetje, pastaj verifikoni me trafik
Versioni i shkurter: konfigurimi i anes permend prefikse (i bazaar ne politike), apo trafiku rutohet ne nje nderfaqe (i bazaar ne rruge)? A i listojne te dy skajet prefiksin e ri? A ka nje rruge kthimi nga nenrrjeti i ri te diapazoni burimor origjinal?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
Verifikimi eshte vendi ku shumica e ndryshimeve mbyllen shume shpejt. Nje ping nga porta provon pak, sepse porta dergon nga vetja dhe shpesh perputhet me nje politike te ndryshme nga ajo e nje hosti. Beni ping nga nje host ne nenrrjetin e ri, pastaj ekzekutoni aplikacionin qe shkaktoi ndryshimin dhe shikoni numeruesit, jo nje ikone statusi.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showNe nje tunel te bazaar ne politike numeruesit e ip xfrm state duhet te rriten ne te dy drejtimet; numeruesit e rrafshet nenkuptojne qe paketa rutohet por nuk zgjidhet. Ne WireGuard wg show raporton transferimin per ane, dhe nje shtrengim duarsh me zero bajt te marra tregon listen e anes se larget ose rrugen e saj te kthimit.
Perfundoni duke regjistruar prefiksin, perzgjedhesin ose rrugen e anes, vendimin per rrugen e kthimit dhe hyrjen e firewall-it bashke me pjesen tjeter te inventarit te tunelit. Pastaj rinisni nje porte dhe provoni perseri: nje rruge e shtuar me dore zhduket, dhe personi tjeter nuk duhet ta zbulojë perseri.