Miksi OpenVPN-asiakkaat ohittavat yhdyskäytävän IPsec-valitsimet

Pingaa yhdyskäytävästä etäisen IPsec-tunnelin takana olevaa isäntää ja se vastaa puhtaasti, joten tunneli näyttää terveeltä ja tiketti etenee. Sitten yhdistetty asiakas yrittää samaa isäntää eikä saa mitään takaisin. Se pingi ei ollut koskaan todiste asiakkaan virrasta, koska se lähti yhdyskäytävän omalla lähdeosoitteella ja vastasi eri IPsec-valitsinta. Sen ymmärtäminen, miksi nämä kaksi tapausta erkanevat, on suurin osa korjauksesta.

Yhdyskäytävän pingi testaa virtaa, jota asiakkaasi ei koskaan käytä

Lähdeosoite ratkaisee, mitä käytäntöä sovelletaan. Yhdyskäytävällä luotu paketti lähtee sen paikallisen LAN-verkon tai tunnelin päätepisteen osoitteella, ja sitä vastaava käytäntö kirjoitettiin täsmälleen tuota tapausta varten. Asiakkaan paketti saapuu OpenVPN-rajapintaan asiakaspoolin osoitteella, mikä on täysin eri valitsin.

Siksi vika näyttää reititysongelmalta, vaikka se onkin todellisuudessa käytännön laajuuden ongelma. Yhdyskäytävästä saavutettavuus todistaa, että vastapuoli on pystyssä ja ehdotukset neuvoteltiin, eikä se todista mitään siitä, onko pooli suojattu.

Työnnä etäinen etuliite, jota sovellus todella tarvitsee

Ota havainnollistava pari 10.8.0.0/24 yhdistetyille asiakkaille ja 172.30.239.0/25 suojatulle etäverkolle. Asiakas tarvitsee reitin tuohon toiseen etuliitteeseen, ei yhdyskäytävän LAN-verkkoon eikä johonkin muuhun tunneliosoitteeseen. Pooliin työnnetty reitti on se, mikä saa asiakkaan ylipäätään luovuttamaan tämän liikenteen yhdyskäytävälle. Ilman sitä paketti ei koskaan saavuta sitä käytäntöpäätöstä, jota selvität.

Community-palvelimessa, joka hyväksyy työnnetyt reitit, direktiivi ottaa todellisen maskin: push "route 172.30.239.0 255.255.255.128". Access Server määrittää saman kohteen asennetun version yksityisverkon tai käyttösääntöjen asetuksilla, ja reititetty tai käännetty tila valitaan tarkoituksella. Luotujen palomuuriketjujen muokkaaminen omistavan kokoonpanon sijaan on se, miten toimivasta asennuksesta tulee mahdoton toistaa.

Yhdistämisen jälkeen lue asiakkaan reititystaulukko, älä palvelimen aikomus. Reitti, joka kattaa vain poolin, tarkoittaa, että työntö ei koskaan saapunut, ja tunnelin kautta kulkeva oletusreitti on tätä vaatimusta laajempi ja yllättää sinut myöhemmin. Tarkista maski ja myös etuliite, koska /25:nä työnnetty /24 lähettää naapuriosoitteiden liikennettä polulle, joka ei voi kantaa sitä. Vahvista sitten, että asiakas valitsi tunnelirajapinnan tuolle kohteelle.

Sisällytä asiakaspooli valitsimiin

Reititetylle käytölle, joka säilyttää asiakkaiden osoitteet, IPsec-käytännön on suojattava poolin ja etäisen etuliitteen välinen liikenne. Yhdyskäytävän omaa LAN-verkkoa varten kirjoitetut valitsimet päästävät pingin läpi ja pudottavat asiakkaan pyynnön, ja juuri se epäsymmetria aloitti tämän tutkinnan.

Tarkastele neuvoteltua käytäntöä sekä määritettyjä ehdotuksia, esimerkiksi komennolla ipsec statusall strongSwanissa tai toteutuksesi vastaavalla tilakomennolla. Käytäntöpohjaisessa IPsecissä tavallinen reitti voi osoittaa fyysiseen rajapintaan, vaikka vastaava liikenne salataan silti, joten puuttuva tunnelilaite ei todista mitään. Vertaa valitsinpareja kirjoittamaasi pooliin ja etuliitteeseen.

Yhdyskäytävän yleinen lähde-NAT voi myös rikkoa täsmäytyksen. Jos masquerade-sääntö kirjoittaa asiakkaan lähteen uudelleen ennen käytäntötarkistusta, paketti ei enää näytä kirjoittamaltasi valitsimelta. Siksi laaja masquerade-sääntö on huono ratkaisu toiselle VPN:lle: se muuttaa, mitä käytäntöä sovelletaan ja minkä osoitteen etäpuoli kirjaa. Vapauta liikenne, jonka aiot reitittää, tai käännä se tarkoituksella ja päivitä valitsimet.

Valitse reititys tai käännös tarkoituksella

Reititys pitää asiakkaan osoitteen etäpuolelle näkyvänä, joten etälokit ja lähdekohtaiset säännöt pysyvät merkityksellisinä, ja se vaatii, että etäinen yhdyskäytävä tuntee paluupolun pooliin. Käännös piilottaa poolin yhden osoitteen taakse, mikä poistaa paluureitin ongelman ja tuhoaa jokaisen asiakkaan identiteetin.

Valitse yksi suunnittelu ja kirjoita se muistiin, koska ne tarvitsevat eri valitsimet ja eri palomuurijärjestyksen. Puoliksi sovellettu masquerade asettuu niiden väliin eikä tyydytä kumpaakaan. Kirjattu valinta on myös se, mikä antaa seuraavalle insinöörille mahdollisuuden erottaa virheen tarkoituksellisesta päätöksestä.

Sulje silmukka edelleenlähetyksessä ja vastauksessa

Yhdyskäytävän on välitettävä protokolla ja kohde, jotka aiot, mikä tarkoittaa päällä olevaa IP-edelleenlähetystä ja edelleenlähetysketjua, joka sallii parin. Sitten etäpuolen on lähetettävä vastaukset takaisin IPsec-polkua pitkin, ja se on reitityspäätös heidän yhdyskäytävällään, ei sinun. Molemmat puolet ovat tavallista kokoonpanoa, ja molemmat jäävät helposti puolitiehen. Testaa ne erikseen, jotta puuttuvaa edelleenlähetyssääntöä ei luulla rikkoutuneeksi tunneliksi.

Vahvista yhdellä todellisella asiakas-sovellus-pyynnöllä ja katso, miten se kulkee OpenVPN-rajapinnan, IPsec-päätöksen ja etäisen isännän läpi. Tarkastele vastausta erillisenä havaintona, koska saapuva pyyntö ja vastaus, joka ei koskaan palaa, näyttävät asiakkaan paikalta samalta. Yksi jäljitetty pyyntö on arvokkaampi kuin mikään määrä yhdyskäytävän pingejä.

Pidä kohteen valtuutus kapeana testauksen aikana ja vahvista, että asiakas ilman sääntöä ei pääse palveluun. Asennettu reitti ja muodostettu assosiaatio eivät ole sama asia kuin myönnetty pääsy.