Toimipisteiden välisen VPN:n vastaus ei kulje tunnelin läpi

Vietin aamun tunnelin parissa, joka nousi puhtaasti ja siirsi liikennettä täsmälleen yhteen suuntaan: sivukonttori pääsi pääkonttorin tiedostopalvelimelle, ja jokainen pääkonttorista sivukonttoriin avattu yhteys kuoli ensimmäiseen SYN-pakettiin. SA:t olivat ylhäällä, tunnelin laskurit kasvoivat, eikä kättely ollut koskaan ongelma. Vastaus reititettiin jonnekin, mitä tunneli ei kata, ja se valinta kuuluu kaukopäähän. Toimipisteiden välinen VPN kuljettaa vain paketit, jotka isäntä luovuttaa yhdyskäytävälle, ja jokainen isäntä tekee sen valinnan erikseen, kussakin suunnassa, omasta reititystaulustaan.

Molemmat suunnat reititetään erikseen

IP ei muista keskustelun suuntaa. Jokainen paketin lähettävä isäntä tekee oman pisimmän etuliitteen hautansa, valitsee yhden seuraavan hypyn ja unohtaa päätöksen. Pyyntö ja vastaus ovat kaksi toisiinsa liittymätöntä pakettia, jotka sattuvat kuulumaan samaan yhteyteen, ja tunneli on yksi hyppy, jota kumpi tahansa voi käyttää tai olla käyttämättä. Mikään IKE-vaihdossa ei opeta kaukopalvelimelle, miten se tavoittaa aliverkkosi; neuvottelu sopii vain siitä, mitkä etuliitteet saa salata.

Se sopimus on toinen portti. strongSwanissa liikenteen valitsimet ovat leftsubnet ja rightsubnet, eikä pakettia, jonka lähde tai kohde jää neuvotellun parin ulkopuolelle, salata, mitä reititystaulu sitten sanookin. Etuliite, joka reititetään tunneliin mutta puuttuu valitsimista, on hiljainen yksisuuntainen vika: reitti näyttää oikealta, paketti lähtee silti salaamattomana tai pudotetaan, ja vain charonin loki valittaa.

Kaukoisäntä ei tiedä tunnelistasi mitään

Kauko-LAN:in sisällä vastaus on tavallinen paketti, joka on osoitettu asiakkaallesi. Kohdeisäntä ei näe IPsec-otsaketta eikä sillä ole syytä suosia VPN-yhdyskäytävää; se etsii etuliitteesi, ei löydä mitään tarkempaa kuin oletusreittinsä ja seuraa sitä. Jos oletus osoittaa ydinpalomuuriin, palomuurilla joko on reitti takaisin tunneliin tai ei ole. Kun ei ole, saat hiljaisen pudotuksen, ICMP unreachablen tai vastauksen, joka lähtee internetiin päin olevasta rajapinnasta ja kuolee.

Toinen rajapinta riittää rikkomaan tämän, vaikka reitti olisi olemassa. NAS, jonka hallintalinkki on toisessa VLAN:issa, varmistusuplinkilla varustettu palvelin, politiikkasääntö, joka lähettää yhden lähdealueen toiseen tauluun: mikä tahansa näistä voi napata vastauksen. Linuxissa ip rule show ja ip route show table all paljastavat säännöt ja taulut, jotka oletuslistaus kätkee.

Lue päätös koneelta, joka lähettää vastauksen

Kysy ytimeltä ennen kuin muutat mitään, ja anna sille lähdeosoite, koska lähteestä riippuvat säännöt muuttavat vastausta.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Tuloste kertoo lähtevän rajapinnan ja seuraavan hypyn. Jos rajapinta ei ole VPN-yhdyskäytävään päin oleva, olet löytänyt vian, ja jäljellä on valita, mihin reitti kuuluu. Yhdyskäytävästä tehty pingi todistaa vähän: se vastaa osoitteella, jonka kaukoisäntä osaa sijoittaa, ei kannettavasi osoitteella.

Windowsissa vastineet ovat Find-NetRoute -RemoteIPAddress 10.10.5.10 päätökselle ja Get-NetRoute taululle. Reitti, joka lisätään New-NetRoute-komennolla ja jonka metriikka on oletusta korkeampi, häviää hiljaa, joten lue metriikkasarake, älä merkintää. Vahvista sitten paketeilla: tcpdump -ni any "host 10.10.5.10 and tcp port 445" kauko-LAN:in rajapinnalla näyttää pyynnön, ja sama suodatin tunnelin puolella näyttää, tuliko vastaus takaisin. Näkyvä pyyntö ilman vastausta tarkoittaa, että vastaus reititettiin muualle tai pudotettiin; vastaus väärällä rajapinnalla antaa syyllisen ennen kuin kosket reittiin.

Kun palvelimen yhdyskäytävä ei ole VPN:n päätepiste

Monet paikat laittavat palomuurin palvelimien ja keskittimen väliin. Se palomuuri välittää vastauksen, joten se tarvitsee reitin asiakkaasi etuliitteelle kohti VPN-yhdyskäytävää ja välityspolitiikan molempiin suuntiin. Tilalliset laitteet pahentavat asiaa: pyyntö ylitti palomuurin siltä LAN-isännältä, jonka se salli, vastaus saapuu nyt eri suunnasta eikä yhteysseurannan merkintä enää täsmää, joten paketti hylätään kelvottomana eikä kiellettynä. Siksi politiikkaloki näyttää tyhjältä, kun liikenne katoaa.

Yhdyskäytävällä on oma toinen suodattimensa. Linuxin käänteisen polun suodatus pudottaa paketit, joiden lähde ei ole tavoitettavissa siltä rajapinnalta, jolta ne saapuivat, ja juuri se on laillisen epäsymmetrisen paluupolun muoto. strongSwanin välitysohje vaatii juuri siksi net.ipv4.ip_forward ja löysemmän net.ipv4.conf.all.rp_filter. Tiukka arvo 1 kummassa tahansa yhdyskäytävässä rikkoo hiljaa oikean reitin, ja nstat -az näyttää pudotukset, jos tiedät mihin katsoa.

Reititä tai käännä ja vahvista sitten molemmissa suunnissa

Kaksi korjausta eivät ole samanarvoisia. Reitin lisääminen pitää asiakkaan osoitteen ehjänä, joten lähdeperusteiset säännöt, audit-lokit ja kutsujan tallentavat sovellukset toimivat edelleen; hinta on, että jokainen päätöksen tekevä hyppy tarvitsee reitin, eli useampia paikkoja mennä pieleen. Naatiointi kaukoyhdyskäytävässä kutistaa paluupolun yhdeksi hypyksi, koska vastaus on nyt osoitettu yhdyskäytävälle itselleen, ja kätkee, kuka asiakas teki mitä.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Valitse se tietoisesti: kun asiakkaat alkavat näkyä yhdyskäytävän osoitteena, lähdeperusteiset ACL:t lakkaavat erottamasta heitä, ja conntrack:n on pidettävä kartoitus, jotta vastaus kirjoitetaan takaisin tunneliin. Jos valitsimet yhä sulkevat asiakkaan etuliitteen pois, NAT ei muuta mitään, koska pyyntö ei koskaan tullut tunneliin.

Ennen kuin sanot sen korjatuksi, vahvista neljä asiaa järjestyksessä: reitti vastauksen lähettävällä isännällä, reitti jokaisella sitä välittävällä hypyllä, molemmat etuliitteet kattavat valitsimet ja tallenne, joka näyttää vastauksen tulevan tunneliin odottamastasi lähteestä. Toista sitten testi toisesta toimipisteestä. Yhden suunnan läpäisy on puoliavoin rakenne, ja toinen suunta epäonnistuu yleensä eri syystä kuin se, jonka juuri korjasit.