Näin lähetät vain yhden yksityisen aliverkon VPN:n kautta

Yksi yksityinen aliverkko tunnelin läpi ja kaikki muu tavallista reittiäsi pitkin on pieni pyyntö, jossa on monta tapaa mennä pieleen. Tuloksen ratkaisee se, missä päätös pannaan täytäntöön, ei split tunneling -niminen valintaruutu: asiakkaan omassa reititystaulussa, palvelimen työntämässä reitissä vai politiikassa, josta kaksi päätä neuvottelevat. Valitse väärä kerros ja saat joko täyden tunnelin, jota et koskaan halunnut, tai reitin tunneliin, jota vastapuoli kieltäytyy hyväksymästä. Käytän kolmen ehdon testiä ennen minkään asetuksen avaamista ja valitsen sitten yhden alla olevista mekanismeista.

Kolme ehtoa, jotka ratkaisevat suunnittelun

Ensinnäkin tarvitset tarkan etuliitteen ja peitteen verkon omistajalta. Verkko 10.x ei ole etuliite; 10.20.0.0/16 on. Varmista, että se ei ole päällekkäinen kotiverkkosi, Docker-sillan tai muun käyttämäsi VPN:n kanssa, koska päällekkäisyys tekee reitistä monitulkintaisen ja ydin valitsee merkinnän, jota et tarkoittanut.

Toiseksi, kuka vastaa paluuliikenteeseen. Paketin reitittäminen tunneliin vie sen vain VPN-palvelimelle. Jos aliverkko on toisen reitittimen takana, jolla ei ole paluureittiä asiakaspooliisi, palvelimen on maskattava liikenne tai tuon reitittimen on opittava pooli. Mikään asiakkaan puolen reitti ei korjaa puuttuvaa paluureittiä.

Kolmanneksi, täytäntöönpanokohta. Jotkin asiakkaat asentavat reitin ja käyttöjärjestelmä tekee loput. Toiset neuvottelevat politiikasta, ja politiikka, jota yhdyskäytävä ei hyväksy, ei tuota lainkaan tunnelia: paketit pudotetaan ilman selvää virhettä. Selvitä ennen kirjoittamista, kumpi näistä kahdesta on sinun.

WireGuard: AllowedIPs on reititystaulu

Asiakkaassa AllowedIPs luettelee kohteet, jotka saavat tulla tunneliin, ja wg-quick muuttaa jokaisen merkinnän tavalliseksi reitiksi. Asiakkaan osuus tästä tehtävästä on siis yksi rivi.

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

Vertaa nyt palvelimen merkintää samalle asiakkaalle. Se kuvaa, mitä palvelin lähettää asiakkaalle, ja se on yleensä asiakkaan tunneliosoite, ei yksityinen aliverkko.

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

Näiden kahden vaihtaminen on yleisin näkemäni virhe. 10.20.0.0/16 palvelimen peer-osan alle asettaminen väittää, että koko aliverkko on tuon asiakkaan takana, ja se on sivusto-sivustolle-väite, ei lupa. Paketit, jotka eivät vastaa minkään peerin AllowedIPs-arvoa, pudotetaan hiljaa, joten väärä merkintä näyttää täsmälleen palomuuriongelmalta.

Jos hallitset reitit itse, aseta Table = off [Interface]-kohdan alle ja lisää haluamasi reitti. Silloin mitään ei lisätä automaattisesti, joten reitti kuuluu siihen, mikä nostaa rajapinnan.

OpenVPN: työnnä reitti ja varmista sitten, että se saapuu

Tavallisella palvelimella muutos on yksi direktiivi palvelimen asetuksissa, asiakaspoolin vieressä.

push "route 10.20.0.0 255.255.0.0"

Asiakas lisää sen yhdistäessään. Vikatila ilmenee, kun sama profiili työntää myös redirect-gateway, tai kun joku on jo lisännyt route-nopull: ensimmäinen tekee istunnosta täyden tunnelin ja toinen hylkää jokaisen työnnetyn reitin, myös sinun.

Asiakkaan, joka tarvitsee kapeaa käyttäytymistä täystunnelipalvelinta vastaan, pitäisi jättää huomiotta vain ne osat, joita se ei halua. OpenVPN:ssä 2.4 ja uudemmissa pull-filter on olemassa juuri sitä varten.

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

Pidä osoiteperheet erillään: työnnetty IPv4-reitti ei tee mitään sisäiselle palvelulle, joka ratkeaa IPv6:ksi, ja se palvelu epäonnistuu tunnelin kautta, kun kaikki muu näyttää olevan kunnossa.

Kun yksityinen aliverkko ei ole VPN-palvelimella vaan toisen asiakkaan takana, palvelimelle on kerrottava. Lisää client-config-dir-asetuksen kautta asiakaskohtainen tiedosto, joka sisältää iroute 10.20.0.0 255.255.0.0, sekä vastaava route, jotta muut asiakkaat oppivat reitin. Ilman iroute palvelimella ei ole syytä lähettää tuota etuliitettä juuri tuon tunnelin kautta.

IPsec: liikennevalitsimien on sovittava yhteen

IPsecissä ei ole työnnettävää reittiä. Kaksi päätä neuvottelee, mitkä osoitteet ovat tunnelin sisällä, ja sovittujen valitsimien ulkopuolista liikennettä ei salata eikä lähetetä sen kautta. strongSwan-asiakkaassa valitsimet ovat nimenomaisia.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Jos yhdyskäytävä on määritetty 0.0.0.0/0-arvolla molemmilla puolilla, IKEv2-kavennus pienentää lapsi-SA:n yleensä kahden ehdotuksen leikkaukseksi, mikä on haluttu tulos. Jotkin yhdyskäytävät hylkäävät sen sijaan ehdotuksen, joka ei vastaa niiden määritettyjä valitsimia, ja loki näyttää silloin epäonnistuneen lapsi-SA:n eikä reititysvalitusta. Kun näin käy, muutos kuuluu yhdyskäytävälle, koska asiakkaan reitti ei voi luoda tunnelia valitsimelle, jota toinen puoli ei hyväksy.

Windowsissa sisäänrakennettu asiakas kätkee saman päätöksen kahden asetuksen taakse. Tunnelin jako on kytkettävä päälle ja etuliite rekisteröitävä profiiliin.

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

Juuri etuliitteen rekisteröinti saa sen säilymään uudelleenyhdistämisen yli, mitä käsin lisätty reitti ei tee.

Pidä päätepiste ja DNS päätöksen ulkopuolella

VPN:n päätepisteen on pysyttävä tavoitettavana ilman tunnelia, muuten tunneli romahtaa itseensä. Kun vain 10.20.0.0/16 reititetään, se on automaattista, koska päätepiste on julkinen osoite. Täystunneliprofiilissa se ei ole, ja asiakas tarvitsee nimenomaisen isäntäreitin päätepisteeseen ennen kuin tunneli nousee.

DNS on toinen päätös, jota reitin työntäminen ei tee puolestasi. Sisäiset nimet ratkeavat yleensä ratkaisijan kautta, johon vain yksityinen verkko pääsee. Jos palvelin työntää DNS-palvelimen, jokainen nimi kulkee sen kautta; jos ei, sisäiset nimet joko epäonnistuvat tai ratkeavat julkisesti johonkin, jota et tarkoittanut. Jaettu DNS pitää yhden hakutoimialueen sisäisellä ratkaisijalla, mutta se riippuu asiakastuesta, joten käsittele sitä omana tehtävänään äläkä reitityksen sivuvaikutuksena.

Varmista, käynnistä sitten uudelleen ja varmista taas

Kolme koetta kattavat reitityskysymyksen. Kysy ytimeltä, minne etäosoite menisi, hae jotain aliverkon sisältä ja varmista sitten, että tavallinen julkinen pyyntö lähtee edelleen tavallisen yhteytesi kautta.

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

Ensimmäinen rivi nimeää rajapinnan. Jos se nimeää fyysisen rajapintasi, reitti ei koskaan saapunut. Windowsissa Find-NetRoute -RemoteIPAddress 10.20.5.7 vastaa samaan kysymykseen, ja viimeisen kokeen pitäisi näyttää edelleen tavallinen osoitteesi eikä VPN-palvelimen osoitetta.

Käynnistä sitten uudelleen. Käsin lisätyt reitit katoavat, kun taas profiilista, työnnetystä asetuksesta tai AllowedIPs-arvosta tulevat reitit palaavat. Jos kapea pääsy toimii ennen uudelleenkäynnistystä ja epäonnistuu sen jälkeen, vika on siinä, miten tunneli käynnistyy, ei itse reitissä.

Ennen kuin sanot sen valmiiksi, varmista neljä asiaa: etuliite tuli verkon omistajalta eikä ole päällekkäinen minkään paikallisen kanssa, paluureitti on olemassa tai maskaussääntö korvaa sen, määrittämäsi mekanismi on se, joka panee reitityksen täytäntöön alustallasi, ja samat kokeet menevät läpi puhtaan uudelleenkäynnistyksen jälkeen. strongSwanin edelleenlähetysmuistiinpanot kannattaa lukea, jos paluureitti on se osa, joka jatkuvasti pettää.