Kuidas saata VPN-i kaudu ainult üht privaatset alámvõrku

Üks privaatne alámvõrk tunnelist läbi ja kõik muu mööda teie tavalist teed on väike palve, millel on palju võimalusi valesti minna. Tulemuse otsustab mitte märkeruut nimega split tunneling, vaid see, kus otsus jõustub: kliendi enda marsruuditabelis, serveri lükatavas marsruudis või poliitikas, mille kaks otsa kokku lepivad. Valige vale kiht ja saate kas täistunneli, mida te kunagi ei tahtnud, või marsruudi tunnelisse, mida vastaspool keeldub vastu võtmast. Enne mis tahes konfiguratsiooni avamist kasutan kolme tingimusega testi ja valin seejärel ühe allpool kirjeldatud mehhanismidest.

Kolm tingimust, mis otsustavad lahenduse

Esiteks vajate täpset prefiksit ja maski võrgu omanikult. Võrk 10.x ei ole prefiks; 10.20.0.0/16 on. Veenduge, et see ei kattu teie koduse LAN-iga, Dockeri sillaga ega mõne teise VPN-iga, mida käitate, sest kattumine muudab marsruudi mitmetähenduslikuks ja tuum valib kirje, mida te ei kavatsenud.

Teiseks, kes vastab tagasitulevale liiklusele. Paketi tunnelisse suunamine viib selle ainult VPN-serverini. Kui alámvõrk asub teise ruuteri taga, millel pole marsruuti tagasi teie kliendikogumisse, peab server liiklust maskeerima või peab see ruuter teie kogumit õppima. Ükski kliendipoolne marsruut ei paranda puuduvat tagasiteed.

Kolmandaks, jõustamise koht. Mõned kliendid paigaldavad marsruudi ja operatsioonisüsteem teeb ülejäänu. Teised peavad läbirääkimisi poliitika üle, ja poliitika, mida lüüs ei aktsepteeri, ei tekita üldse tunnelit: paketid visatakse kõrvale ilma nähtava veata. Tehke enne millegi kirjutamist kindlaks, kumb kahest on teie oma.

WireGuard: AllowedIPs on marsruuditabel

Kliendis loetleb AllowedIPs sihtkohad, mis tohivad tunnelisse siseneda, ja wg-quick muudab iga kirje tavaliseks marsruudiks. Seega on selle ülesande kliendipoolne osa üks rida.

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

Nüüd võrrelge serveri kirjet sama kliendi jaoks. See kirjeldab, mida server kliendile saadab, mis on tavaliselt kliendi tunneli aadress, mitte privaatne alámvõrk.

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

Nende kahe vahetamine on viga, mida näen kõige sagedamini. 10.20.0.0/16 panemine serveri peer-jaotisse väidab, et kogu alámvõrk asub selle kliendi taga, mis on saidilt-saidile nõue, mitte luba. Paketid, mis ei vasta ühegi peeri AllowedIPs-ile, visatakse vaikselt kõrvale, seega vale kirje näeb välja täpselt nagu tulemüüri probleem.

Kui haldate marsruute ise, määrake [Interface] alla Table = off ja lisage marsruut, mida soovite. Siis ei lisata midagi automaatselt, seega kuulub marsruut selle juurde, mis liidese üles tõstab.

OpenVPN: lükake marsruut välja ja veenduge, et see kohale jõuab

Tavalisel serveril on muudatus serveri konfiguratsioonis üks direktiiv, kliendikogumi kõrval.

push "route 10.20.0.0 255.255.0.0"

Klient lisab selle ühendamisel. Tõrkerežiim ilmneb siis, kui sama profiil lükkab välja ka redirect-gateway, või kui keegi on juba lisanud route-nopull: esimene muudab sessiooni täistunneliks ja teine viskab kõrvale iga väljalükatud marsruudi, kaasa arvatud teie oma.

Klient, kes vajab täistunneli serveri vastu kitsast käitumist, peaks ignoreerima ainult neid osi, mida ta ei taha. OpenVPN-is 2.4 ja hiljem on pull-filter täpselt selle jaoks olemas.

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

Hoidke aadressiperekonnad lahus: väljalükatud IPv4 marsruut ei tee midagi sisemise teenuse jaoks, mis lahendub IPv6-ks, ja see teenus ebaõnnestub läbi tunneli, samal ajal kui kõik muu näeb korras välja.

Kui privaatne alámvõrk ei asu VPN-serveris, vaid teise kliendi taga, tuleb serverit teavitada. Lisage client-config-dir kaudu fail iga kliendi kohta, mis sisaldab iroute 10.20.0.0 255.255.0.0, pluss vastav route, et teised kliendid õpiksid tee. Ilma iroute-ta pole serveril põhjust seda prefiksit just selle konkreetse tunneli kaudu saata.

IPsec: liiklusselektorid peavad ühtima

IPsec-i puhul pole marsruuti, mida välja lükata. Kaks otsa lepivad kokku, millised aadressid tunnelis asuvad, ja kokkulepitud selektoritest väljaspool olev liiklus ei ole ei krüpteeritud ega saadeta selle kaudu. strongSwan-kliendis on selektorid selgesõnalised.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Kui lüüs on mõlemal pool konfigureeritud aadressiga 0.0.0.0/0, vähendab IKEv2 kitsendamine tavaliselt tütar-SA kahe pakkumise ühisosani, mis ongi soovitud tulemus. Mõned lüüsid lükkavad selle asemel tagasi pakkumise, mis ei vasta nende konfigureeritud selektoritele, ja logi näitab siis ebaõnnestunud tütar-SA-d, mitte marsruutimiskaebust. Kui see juhtub, kuulub muudatus lüüsile, sest kliendi marsruut ei saa luua tunnelit selektori jaoks, mida teine pool ei aktsepteeri.

Windowsis peidab sisseehitatud klient sama otsuse kahe sätte taha. Tunneli jagamine peab olema sisse lülitatud ja prefiks peab olema profiili juurde registreeritud.

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

Just prefiksi registreerimine teeb selle ühenduse taastamise üle elavaks, mida käsitsi lisatud marsruut ei tee.

Hoidke lõpp-punkt ja DNS otsusest väljas

VPN-i lõpp-punkt peab jääma ilma tunnelita kättesaadavaks, muidu variseb tunnel iseendasse kokku. Kui marsruuditakse ainult 10.20.0.0/16, on see automaatne, sest lõpp-punkt on avalik aadress. Täistunneli profiilis see nii ei ole ja klient vajab selgesõnalist hostimarsruuti lõpp-punktini enne, kui tunnel üles tõuseb.

DNS on teine otsus, mida marsruudi väljalükkamine teie eest ei tee. Sisemised nimed lahenduvad tavaliselt resolveri kaudu, kuhu pääseb ainult privaatvõrk. Kui server lükkab välja DNS-serveri, käib iga nimi selle kaudu; kui ei, siis sisemised nimed kas ebaõnnestuvad või lahenduvad avalikult millekski, mida te ei kavatsenud. Jagatud DNS hoiab üht otsingudomeeni sisemisel resolveril, kuid see sõltub kliendi toest, seega käsitlege seda omaette ülesandena, mitte marsruutimise kõrvalmõjuna.

Kontrollige, seejärel taaskäivitage ja kontrollige uuesti

Kolm proovi katavad marsruutimise küsimuse. Küsige tuumalt, kuhu läheks kaugaddress, hankige midagi alámvõrgu seest ja seejärel kinnitage, et tavaline avalik päring väljub endiselt teie tavalisest ühendusest.

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

Esimene rida nimetab liidese. Kui see nimetab teie füüsilist liidest, ei jõudnud marsruut kunagi kohale. Windowsis vastab samale küsimusele Find-NetRoute -RemoteIPAddress 10.20.5.7 ja viimane proov peaks endiselt näitama teie tavalist aadressi, mitte VPN-serveri oma.

Seejärel taaskäivitage. Käsitsi lisatud marsruudid kaovad, samas kui profiilist, väljalükatud konfiguratsioonist või AllowedIPs-st pärit marsruudid tulevad tagasi. Kui kitsas juurdepääs töötab enne taaskäivitust ja ebaõnnestub pärast, on viga selles, kuidas tunnel käivitub, mitte marsruudis endas.

Enne kui nimetate selle valmis, kinnitage neli asja: prefiks tuli võrgu omanikult ega kattu millegi kohalikuga, tagasitee on olemas või asendab selle maskeerimisreegel, konfigureeritud mehhanism on see, mis jõustab marsruutimist teie platvormil, ja samad proovid läbivad puhta taaskäivituse järel. strongSwani edasisaatmise märkmed tasub lugeda, kui tagasitee on see osa, mis pidevalt ebaõnnestub.