Kaip per VPN siųsti tik vieną privatų potinklį

Vieną privatų potinklį per tunelį, o visa kita įprastu keliu siųsti yra mažas prašymas su daugybe būdų jį sugadinti. Rezultatą lemia ne žymimasis langelis pavadinimu split tunneling, o tai, kur sprendimas įgyvendinamas: paties kliento maršrutų lentelėje, serverio stumiamame maršrute arba politikoje, dėl kurios susitaria abu galai. Pasirinkite netinkamą sluoksnį ir gausite arba visą tunelį, kurio niekada nenorėjote, arba maršrutą į tunelį, kurio kita pusė atsisako priimti. Prieš atidarydamas bet kokią konfigūraciją taikau trijų sąlygų testą, o tada pasirenku vieną iš toliau pateiktų mechanizmų.

Trys sąlygos, lemiančios sprendimą

Pirmiausia jums reikia tikslaus prefikso ir kaukės iš tinklo savininko. 10.x tinklas nėra prefiksas; 10.20.0.0/16 yra. Patikrinkite, ar jis nesutampa su namų LAN, Docker tiltu ar kitu jūsų paleistu VPN, nes sutapimas daro maršrutą dviprasmišką ir branduolys pasirenka ne tą įrašą.

Antra, kas atsako į grįžtamąjį srautą. Paketo nukreipimas į tunelį tik nuveda jį iki VPN serverio. Jei potinklis yra už kito maršrutizatoriaus, kuris neturi maršruto atgal į jūsų klientų telkinį, serveris turi maskuoti srautą arba tas maršrutizatorius turi išmokti jūsų telkinį. Joks kliento pusės maršrutas nepataiso trūkstamo grįžimo kelio.

Trečia, įgyvendinimo vieta. Vieni klientai įdiegia maršrutą, o likusį atlieka operacinė sistema. Kiti derasi dėl politikos, o politika, kurios šliuzas nepriima, nesukuria jokio tunelio: paketai išmetami be aiškios klaidos. Prieš ką nors rašydami nustatykite, kuris iš dviejų atvejų yra jūsų.

WireGuard: AllowedIPs yra maršrutų lentelė

Kliente AllowedIPs išvardija paskirties vietas, kurioms leidžiama patekti į tunelį, o wg-quick kiekvieną įrašą paverčia paprastu maršrutu. Taigi kliento pusė šios užduoties yra viena eilutė.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Dabar palyginkite serverio įrašą tam pačiam klientui. Jis aprašo, ką serveris siųs klientui, o tai paprastai yra kliento tunelio adresas, ne privatus potinklis.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Šių dviejų sukeitimas yra dažniausiai man matoma klaida. Įrašius 10.20.0.0/16 po serverio peer sekcija teigiama, kad visas potinklis yra už to kliento, o tai yra teiginys nuo vietos iki vietos, ne leidimas. Paketai, neatitinkantys jokio peer AllowedIPs, išmetami tyliai, todėl neteisingas įrašas atrodo lygiai kaip ugniasienės problema.

Jei maršrutus valdote patys, nustatykite Table = off po [Interface] ir pridėkite norimą maršrutą. Tada nieko nepridedama automatiškai, todėl maršrutas priklauso tam, kas pakelia sąsają.

OpenVPN: nustumkite maršrutą, tada įsitikinkite, kad jis atkeliavo

Įprastame serveryje pakeitimas yra viena direktyva serverio konfigūracijoje, šalia klientų telkinio.

push "route 10.20.0.0 255.255.0.0"

Klientas jį prideda prisijungdamas. Gedimo režimas pasireiškia, kai tas pats profilis taip pat stumia redirect-gateway arba kai kas nors jau pridėjo route-nopull: pirmasis paverčia sesiją visu tuneliu, antrasis išmeta kiekvieną stumiamą maršrutą, įskaitant jūsiškį.

Klientas, kuriam reikia siauro elgesio su viso tunelio serveriu, turėtų ignoruoti tik tas dalis, kurių nenori. OpenVPN 2.4 ir vėlesnėse versijose pull-filter egzistuoja būtent tam.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Laikykite adresų šeimas atskirai: stumiamas IPv4 maršrutas nieko neduoda vidinei paslaugai, kuri sprendžiama į IPv6, ir ta paslauga nepavyksta per tunelį, kol visa kita atrodo gerai.

Kai privatus potinklis yra ne VPN serveryje, o už kito kliento, serverį reikia informuoti. Per client-config-dir pridėkite failą kiekvienam klientui su iroute 10.20.0.0 255.255.0.0, taip pat atitinkamą route, kad kiti klientai išmoktų kelią. Be iroute serveris neturi priežasties siųsti to prefikso būtent tuo tuneliu.

IPsec: srauto selektoriai turi sutarti

Su IPsec nėra maršruto, kurį reikėtų stumti. Abu galai derasi, kurie adresai yra tunelio viduje, o srautas už suderintų selektorių nėra šifruojamas ir neinamas per jį. strongSwan kliente selektoriai yra aiškūs.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Jei šliuzas sukonfigūruotas su 0.0.0.0/0 abiejose pusėse, IKEv2 susiaurinimas paprastai sumažina vaikinį SA iki dviejų pasiūlymų sankirtos, o tai yra norimas rezultatas. Kai kurie šliuzai vietoj to atmeta pasiūlymą, kuris neatitinka jų sukonfigūruotų selektorių, ir žurnale tada matomas nepavykęs vaikinis SA, o ne maršrutizavimo skundas. Kai taip atsitinka, pakeitimas priklauso šliuzui, nes kliento maršrutas negali sukurti tunelio selektoriui, kurio kita pusė nepriims.

Windows sistemoje įtaisytasis klientas tą patį sprendimą slepia po dviem nustatymais. Tunelio skaidymas turi būti įjungtas, o prefiksas turi būti užregistruotas profilyje.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Būtent prefikso registravimas leidžia jam išlikti po pakartotinio prisijungimo, ko rankiniu būdu pridėtas maršrutas nepadaro.

Laikykite galinį tašką ir DNS už sprendimo ribų

VPN galinis taškas turi likti pasiekiamas be tunelio, kitaip tunelis sugriūva į save patį. Kai maršrutizuojamas tik 10.20.0.0/16, tai vyksta automatiškai, nes galinis taškas yra viešas adresas. Viso tunelio profilyje taip nėra, ir klientui reikia aiškaus maršruto į galinio taško mazgą prieš pakeliant tunelį.

DNS yra antras sprendimas, kurio maršruto stūmimas už jus nepriima. Vidinius vardus paprastai išsprendžia tik privatus tinklas pasiekiamas resolveris. Jei serveris stumia DNS serverį, kiekvienas vardas eina per jį; jei ne, vidiniai vardai arba nepavyksta, arba viešai išsprendžiami į kažką, ko nenorėjote. Atskirtas DNS palaiko vieną paieškos domeną vidiniame resolveryje, bet tai priklauso nuo kliento palaikymo, todėl traktuokite tai kaip atskirą užduotį, o ne maršrutizavimo šalutinį poveikį.

Patikrinkite, tada paleiskite iš naujo ir patikrinkite dar kartą

Trys patikros apima maršrutizavimo klausimą. Paklauskite branduolio, kur keliautų nuotolinis adresas, atsisiųskite ką nors iš potinklio vidaus ir tada patvirtinkite, kad įprasta vieša užklausa vis dar išeina per jūsų normalų ryšį.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Pirmoji eilutė nurodo sąsają. Jei ji nurodo jūsų fizinę sąsają, maršrutas taip ir nepateko. Windows sistemoje Find-NetRoute -RemoteIPAddress 10.20.5.7 atsako į tą patį klausimą, o paskutinė patikra vis dar turėtų rodyti jūsų įprastą adresą, ne VPN serverio.

Tada paleiskite iš naujo. Rankiniu būdu pridėti maršrutai dingsta, o maršrutai iš profilio, iš stumiamos konfigūracijos ar iš AllowedIPs grįžta. Jei siaura prieiga veikia prieš perkrovimą ir nepavyksta po jo, kaltė yra tame, kaip tunelis startuoja, o ne pačiame maršrute.

Prieš vadindami tai baigtu, patvirtinkite keturis dalykus: prefiksas gautas iš tinklo savininko ir nesutampa su niekuo vietiniu, grįžimo kelias egzistuoja arba jį pakeičia maskavimo taisyklė, sukonfigūruotas mechanizmas yra tas, kuris įgyvendina maršrutizavimą jūsų platformoje, ir tos pačios patikros praeina po švaraus perkrovimo. strongSwan persiuntimo pastabos vertos perskaityti, jei grįžimo kelias yra ta dalis, kuri nuolat nepavyksta.