Etäkäyttäjät eivät tavoita toista toimipistettä VPN-keskittymän kautta

Etäkäyttäjä yhdistää keskittymään, tavoittaa tiedostopalvelimen keskittymän omassa lähiverkossa, ja kaikki näyttää terveeltä. Sitten hän avaa jaetun kansion osoitteessa 10.20.0.50 pääkonttorissa, johon keskittymä pääsee erillisen toimipisteiden välisen tunnelin kautta, ja se aikakatkaistaan. Molemmat tunnelit ovat pystyssä ja molemmat laskurit kasvavat, joten kumpikaan tunneli ei ole rikki. Keskittymän ylittäminen on kolme reitityspäätöstä kolmella laitteella, ja tunneli kuljettaa vain ne etuliitteet, joita varten se rakennettiin. Tässä on järjestys, jonka tarkistan, ja komento, joka näyttää, pitääkö jokainen vaihe paikkansa.

Kauttakulku vaatii kolme hakua, ei yhtä tunnelia

Jokainen laite tekee oman pisimmän etuliitteen osumansa ja unohtaa sen. Kannettavan on lähetettävä 10.20.0.50 tunneliin eikä paikalliselle reitittimelleen. Keskittymän on otettava paketti, joka saapui etäkäyttöliittymälle, ja annettava se toimipisteiden väliselle liittymälle. Pääkonttorin on lähetettävä vastaus käyttäjän osoitteelle takaisin tunnelin kautta. Jos mikä tahansa kolmesta epäonnistuu, se näyttää selaimessa samalta: hiljaisuudelta.

Siksi jokaisen tunnelin erikseen testaaminen todistaa niin vähän. Keskittymän lähiverkko-osoitteen pingaaminen harjoittaa ensimmäistä päätöstä ja keskittymän pingaaminen pääkonttorista kolmatta. Epäonnistuvassa paketissa on käyttäjäpooli lähteenä ja toinen toimipiste kohteena, joten kirjoita ne etuliitteet ensin ylös. Tässä pooli on 10.80.0.0/24, keskittymän lähiverkko 10.10.0.0/24 ja pääkonttori 10.20.0.0/24.

Työnnä kaukainen etuliite etäasiakkaalle

OpenVPN-etäkäyttöpalvelimella asiakas oppii reitit yhdistäessään. Ilman pushia jaetun tunnelin asiakas lähettää 10.20.0.50:n omalle yhdyskäytävälleen, eikä paketti koskaan päädy tunneliin.

push "route 10.20.0.0 255.255.255.0"

Työnnetty reitti astuu voimaan, kun asiakas yhdistää, joten verkossa pysyvä käyttäjä ei näe mitään ennen kuin yhdistää uudelleen. Tarkista asiakkaalta: ip route get 10.20.0.50 Linuxissa, route print Windowsissa. Tulosteen pitäisi nimetä tunneliliittymä.

Push ei auta keskittymää. Se on viesti asiakkaalle, ei palvelimen reitti eikä lupa välittää, joten täydellisellä push-rivillä varustettu keskittymä pudottaa virtauksen silti yhden hypyn myöhemmin. Tämä on tavallinen syy siihen, että ihmiset päättelevät pushin epäonnistuneen.

Anna keskittymälle todellinen lähtöreitti

Keskittymä tarvitsee oman seuraavan hyppynsä pääkonttorin etuliitteelle. Reititetyllä tunnelilla se on tavallinen reitti toimipisteiden välisen liittymän kautta, ja yksi komento näyttää sekä valitun reitin että valitun lähteen:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Kun toimipisteiden välinen osuus on itse OpenVPN, reitti voi elää siinä kokoonpanossa, kun vertaispartnerin tunneliosoite on yhdyskäytävänä: route 10.20.0.0 255.255.255.0 172.30.0.2. Yhdyskäytävä ei ole valinnainen. Jätä se pois, niin seuraava hyppy putoaa toteutuksen oletukseen, joka eroaa yhden vertaispartnerin asiakkaan ja usean vertaispartnerin keskittymän välillä.

Käytäntöperusteinen IPsec on erilainen: keskittymän ydin lähettää paketin tavalliselle lähiverkkoyhdyskäytävälleen ja käytäntö nappaa sen matkalla ulos, joten tunnelireitti joko ei tee mitään tai ohjaa liikenteen käytännön ohi. Tarkkaile lähteen kohtaa yllä olevassa komennossa, sillä 10.10.0.1 poolin osoitteen sijaan tarkoittaa, että ydin valitsi osoitteen, jonka vastapuoli hylkää. iroute ei ole sekään vastaus; se kertoo palvelimelle, mikä asiakas omistaa aliverkon oman tunnelinsa takana, ei mihin liikennettä kolmannelle toimipisteelle lähetetään.

Laajenna vastapuoli käyttäjäpooliin

Pääkonttori kattaa jo keskittymän lähiverkon, 10.10.0.0/24. Käyttäjäpooli on toinen etuliite ja sen on oltava myös valitsimissa, muuten mikään käytäntö ei kata osoitteeseen 10.80.0.25 osoitettua vastausta. Jokainen vertaispartneri nimeää saman etuliitejoukkojen parin omalta puoleltaan:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Yhden laitteen local_ts on toisen remote_ts. Kopioi keskittymän lohko pääkonttoriin, niin pari kääntyy, eikä child SA nouse koskaan.

Vanhempi ipsec.conf syntaksi käyttää pilkuilla erotettua leftsubnet. Käynnissä oleva tietoturvayhteys säilyttää neuvottelemansa valitsimet, joten pystytä tunneli uudelleen muokkauksen jälkeen. Klo 10:00 muutettu valitsin, jota testataan klo 09:40 noussutta SA:ta vasten, epäonnistuu edelleen, vaikka asetustiedosto näyttää koko ajan oikealta.

Tarkista sitten viimeinen hyppy. ip route get 10.80.0.25 etäpäätepisteessä pitäisi osoittaa tunneliin. Jos palvelu käyttää lähiverkkoreititintä oletusyhdyskäytävänään, myös se reititin tarvitsee paluureitin, muuten vastaus kuolee sinne. tcpdump -ni eth1 host 10.80.0.25 kyseisellä segmentillä näyttää, lähtikö vastaus päätepisteestä lainkaan.

Salli virtaus keskittymässä

Välityksen on oltava käytössä ja polun sallittu. Rajaa säännöt kahteen etuliitteeseen sen sijaan, että hyväksyt kaiken liittymien välillä.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Käänteisen polun suodatus on sen vieressä hiljainen vika: kun molemmat osuudet ovat eri liittymillä, rp_filter=1 voi pudottaa vastauksen, kun taas hyväksyntäsäännön laskuri ei koskaan liiku. Vertaa iptables -vnL FORWARD ennen yritystä ja sen jälkeen. Sääntöön, joka ei koskaan kasva, ei päästä, joten katso kerros alemmas sen uudelleenkirjoittamisen sijaan.

Jos vain yksi ryhmä tarvitsee kauttakulkua, laita reitti asiakaskohtaiseen tiedostoon hakemistoon client-config-dir sen sijaan, että laajentaisit globaalia pushia. Keskittymän lähde-NAT poistaa myös vastapuolen paluureitin tarpeen, mutta se kätkee käyttäjän osoitteen, joten vastapuolen lokit ja osoiteperusteiset säännöt lakkaavat erottamasta käyttäjiä.

Tarkista asiakkaalta ja peru sitten käänteisessä järjestyksessä

Testaa TCP-portti, älä vain ICMP:tä, koska ping voi mennä läpi, kun palvelu pysyy estettynä. nc -vz 10.20.0.50 445 ja traceroute -n 10.20.0.50 asiakkaalta näyttävät, onko toinen hyppy keskittymän tunneliosoite. Keskittymässä tcpdump -ni tun0 host 10.20.0.50 ja sama suodatin toimipisteiden välisellä liittymällä: pyyntö molemmissa ilman vastausta kummassakaan siirtää ongelman vastapuolelle.

Testaa sitten jotain, jonka on pysyttävä estettynä. Jos myös isäntä, johon poolin ei pitäisi koskaan päästä, vastaa, olet avannut muutakin kuin kauttakulun ja sinun pitäisi kaventaa sääntöjä. Keskittymä, joka välittää kaiken jokaiselle haaralle, läpäisee ensimmäisen testin ja epäonnistuu toisessa.

Pidä peruutuslista, koska neljä objektia muuttui ja kolme on helppo unohtaa: työnnetty reitti, keskittymän reitti, valitsimet ja palomuurisäännöt. Peru ne käänteisessä järjestyksessä, pystytä SA uudelleen ja anna yhden käyttäjän yhdistää uudelleen. Osittainen peruutus jättää reitin osoittamaan tunneliin, joka ei enää täsmää, ja sitä on vaikeampi lukea kuin alkuperäistä hiljaisuutta. OpenVPN 2.6 -käsikirja dokumentoi push, route ja iroute versiollesi.