Kā nosūtīt tikai vienu privātu apakštīklu caur VPN

Vienu privātu apakštīklu caur tuneli un visu pārējo pa ierasto ceļu nosūtīt ir mazs pieprasījums ar daudziem veidiem, kā to sabojāt. Rezultātu nosaka nevis izvēles rūtiņa ar nosaukumu split tunneling, bet gan tas, kur lēmums tiek īstenots: paša klienta maršrutu tabulā, servera virzītā maršrutā vai politikā, par ko vienojas abi gali. Izvēlieties nepareizo slāni un iegūsiet vai nu pilnu tuneli, kuru nekad neesat gribējis, vai maršrutu uz tuneli, kuru pretējā puse atsakās pieņemt. Pirms jebkuras konfigurācijas atvēršanas es izmantoju trīs nosacījumu pārbaudi un pēc tam izvēlos vienu no zemāk minētajiem mehānismiem.

Trīs nosacījumi, kas nosaka dizainu

Pirmkārt, jums vajag precīzu prefiksu un masku no tīkla īpašnieka. 10.x tīkls nav prefikss; 10.20.0.0/16 ir. Pārbaudiet, vai tas nepārklājas ar jūsu mājas LAN, Docker tiltu vai citu jūsu darbinātu VPN, jo pārklāšanās padara maršrutu neviennozīmīgu un kodols izvēlas ierakstu, kuru neesat domājis.

Otrkārt, kas atbild uz atgriezenisko trafiku. Maršrutēt paku tunelī to tikai aizved līdz VPN serverim. Ja apakštīkls atrodas aiz cita maršrutētāja, kuram nav maršruta atpakaļ uz jūsu klientu kopu, serverim ir jāmaskē trafiks, vai arī tam maršrutētājam jāiemācās jūsu kopa. Neviens klienta puses maršruts nelabo trūkstošo atgriešanās ceļu.

Treškārt, īstenošanas vieta. Daži klienti instalē maršrutu, un pārējo dara operētājsistēma. Citi vienojas par politiku, un politika, ko vārteja nepieņem, nerada nekādu tuneli: paketes tiek izmestas bez skaidras kļūdas. Pirms kaut ko rakstāt, noskaidrojiet, kurš no diviem gadījumiem ir jūsējais.

WireGuard: AllowedIPs ir maršrutu tabula

Klientā AllowedIPs uzskaita galamērķus, kuriem drīkst iekļūt tunelī, un wg-quick katru ierakstu pārvērš parastā maršrutā. Tātad klienta puse šim uzdevumam ir viena rinda.

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

Tagad salīdziniet servera ierakstu tam pašam klientam. Tas apraksta, ko serveris sūtīs klientam, un tas parasti ir klienta tuneļa adrese, nevis privātais apakštīkls.

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

Šo divu samainīšana ir visbiežāk sastopamā kļūda, ko redzu. Ievietojot 10.20.0.0/16 zem servera peer sadaļas, tiek apgalvots, ka viss apakštīkls atrodas aiz šī klienta, un tas ir apgalvojums no vietas uz vietu, nevis atļauja. Paketes, kas neatbilst neviena peer AllowedIPs, tiek klusi izmestas, tāpēc nepareizs ieraksts izskatās tieši kā ugunsmūra problēma.

Ja maršrutus pārvaldāt paši, iestatiet Table = off zem [Interface] un pievienojiet vēlamo maršrutu. Tad nekas netiek pievienots automātiski, tāpēc maršruts pieder tam, kas paceļ saskarni.

OpenVPN: virziet maršrutu un pēc tam pārliecinieties, ka tas nonāk

Parastā serverī izmaiņas ir viena direktīva servera konfigurācijā, blakus klientu kopai.

push "route 10.20.0.0 255.255.0.0"

Klients to pievieno, kad izveido savienojumu. Kļūmes režīms parādās, kad tas pats profils virza arī redirect-gateway vai kad kāds jau ir pievienojis route-nopull: pirmais sesiju pārvērš pilnā tunelī, bet otrais izmet katru virzīto maršrutu, tostarp jūsējo.

Klientam, kuram vajadzīga šaura uzvedība pret pilna tuneļa serveri, vajadzētu ignorēt tikai tās daļas, ko tas nevēlas. OpenVPN 2.4 un jaunākās versijās pull-filter pastāv tieši tam.

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

Turiet adrešu saimes atsevišķi: virzīts IPv4 maršruts neko nedod iekšējam servisam, kas tiek atrisināts uz IPv6, un šis serviss cieš neveiksmi caur tuneli, kamēr viss pārējais izskatās kārtībā.

Kad privātais apakštīkls ir nevis VPN serverī, bet aiz cita klienta, serveris ir jāinformē. Pievienojiet failu katram klientam, izmantojot client-config-dir, ar iroute 10.20.0.0 255.255.0.0, kā arī atbilstošo route, lai citi klienti apgūtu ceļu. Bez iroute serverim nav iemesla sūtīt šo prefiksu tieši pa to tuneli.

IPsec: trafika selektoriem ir jāsakrīt

Ar IPsec nav maršruta, ko virzīt. Abi gali vienojas, kuras adreses atrodas tuneļa iekšienē, un trafiks ārpus saskaņotajiem selektoriem netiek šifrēts un netiek caur to sūtīts. strongSwan klientā selektori ir skaidri.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Ja vārteja abās pusēs ir konfigurēta ar 0.0.0.0/0, IKEv2 sašaurināšana parasti samazina bērnu SA līdz abu priekšlikumu šķēlumam, kas ir vēlamais rezultāts. Dažas vārtejas tā vietā noraida priekšlikumu, kas neatbilst to konfigurētajiem selektoriem, un žurnāls tad rāda neizdevušos bērnu SA, nevis maršrutēšanas sūdzību. Kad tas notiek, izmaiņas attiecas uz vārteju, jo klienta maršruts nevar izveidot tuneli selektoram, kuru pretējā puse nepieņems.

Windows iekļautais klients to pašu lēmumu slēpj aiz diviem iestatījumiem. Tuneļa sadalīšanai jābūt ieslēgtai, un prefikss ir jāreģistrē profilā.

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

Tieši prefiksa reģistrēšana ļauj tam pārdzīvot atkārtotu savienojumu, ko manuāli pievienots maršruts nepanāk.

Turiet galapunktu un DNS ārpus lēmuma

VPN galapunktam jāpaliek sasniedzamam bez tuneļa, citādi tunelis sabrūk pats sevī. Kad maršrutēts tiek tikai 10.20.0.0/16, tas notiek automātiski, jo galapunkts ir publiska adrese. Pilna tuneļa profilā tas tā nav, un klientam pirms tuneļa pacelšanas vajag skaidru maršrutu uz galapunkta resursdatoru.

DNS ir otrs lēmums, ko maršruta virzīšana jūsu vietā nepieņem. Iekšējie nosaukumi parasti tiek atrisināti ar atrisinātāju, kuram var piekļūt tikai privātais tīkls. Ja serveris virza DNS serveri, katrs nosaukums iet caur to; ja ne, iekšējie nosaukumi vai nu cieš neveiksmi, vai tiek publiski atrisināti kaut kam, ko neesat domājis. Sadalītais DNS patur vienu meklēšanas domēnu iekšējā atrisinātājā, bet tas ir atkarīgs no klienta atbalsta, tāpēc uztveriet to kā atsevišķu uzdevumu, nevis maršrutēšanas blakusefektu.

Pārbaudiet, pēc tam pārstartējiet un pārbaudiet vēlreiz

Trīs pārbaudes aptver maršrutēšanas jautājumu. Pajautājiet kodolam, kur aizietu attāla adrese, iegūstiet kaut ko no apakštīkla iekšienes un pēc tam apstipriniet, ka parasts publisks pieprasījums joprojām iziet caur jūsu ierasto savienojumu.

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

Pirmā rinda nosauc saskarni. Ja tā nosauc jūsu fizisko saskarni, maršruts tā arī nenonāca. Windows Find-NetRoute -RemoteIPAddress 10.20.5.7 atbild uz to pašu jautājumu, un pēdējai pārbaudei joprojām jārāda jūsu ierastā adrese, nevis VPN servera adrese.

Pēc tam pārstartējiet. Manuāli pievienotie maršruti pazūd, bet maršruti no profila, no virzītas konfigurācijas vai no AllowedIPs atgriežas. Ja šaura piekļuve strādā pirms pārstartēšanas un cieš neveiksmi pēc tam, vaina ir tajā, kā tunelis startē, nevis pašā maršrutā.

Pirms saukt to par pabeigtu, apstipriniet četras lietas: prefikss nācis no tīkla īpašnieka un nepārklājas ar neko vietēju, atgriešanās ceļš pastāv vai to aizstāj maskēšanas noteikums, konfigurētais mehānisms ir tas, kas īsteno maršrutēšanu jūsu platformā, un tās pašas pārbaudes iztur pēc tīras pārstartēšanas. strongSwan piezīmes par pāradresēšanu ir vērtas izlasīšanas, ja atgriešanās ceļš ir tā daļa, kas pastāvīgi cieš neveiksmi.