Zašto OpenVPN klijenti propuštaju IPsec selektore pristupnika

Pošaljite ping na host iza udaljenog IPsec tunela s pristupnika i on čisto odgovori, pa tunel izgleda zdravo i tiket ide dalje. Zatim povezani klijent pokuša isti host i ne dobije ništa natrag. Taj ping nikada nije bio dokaz za klijentov tok, jer je otišao s vlastitom izvornom adresom pristupnika i pogodio drugi IPsec selektor. Razumijevanje zašto se ta dva slučaja razilaze veći je dio popravka.

Ping s pristupnika testira tok koji vaš klijent nikada ne koristi

Izvorna adresa odlučuje koja se politika primjenjuje. Paket nastao na pristupniku odlazi s adresom iz njegove lokalne LAN mreže ili iz njegove tunelske krajnje točke, a politika koja mu odgovara napisana je točno za taj slučaj. Klijentov paket dolazi na OpenVPN sučelje noseći adresu iz klijentskog poola, što je posve drugi selektor.

Zato kvar izgleda kao problem usmjeravanja, a zapravo je problem opsega politike. Dostupnost s pristupnika dokazuje da je peer aktivan i da su prijedlozi dogovoreni, a ne dokazuje ništa o tome je li pool zaštićen.

Pushajte udaljeni prefiks koji aplikacija stvarno treba

Uzmite ilustrativni par 10.8.0.0/24 za povezane klijente i 172.30.239.0/25 za zaštićenu udaljenu mrežu. Klijentu treba ruta do tog drugog prefiksa, ne do pristupnikove LAN mreže i ne do neke druge tunelske adrese. Ruta pushana u pool jest ono što klijenta uopće navodi da taj promet preda pristupniku. Bez nje paket nikada ne stigne do odluke o politici koju otklanjate.

Na Community poslužitelju koji prihvaća pushane rute, direktiva preuzima stvarnu masku: push "route 172.30.239.0 255.255.255.128". Access Server konfigurira istu destinaciju kroz postavke privatne mreže ili pravila pristupa instalirane verzije, s namjerno odabranim usmjerenim ili prevedenim načinom. Uređivanje generiranih firewall lanaca umjesto matične konfiguracije put je kojim radna postava postaje nemoguća za reproduciranje.

Nakon povezivanja čitajte klijentovu tablicu usmjeravanja, a ne namjeru poslužitelja. Ruta koja pokriva samo pool znači da push nije stigao, a zadana ruta kroz tunel šira je od ovog zahtjeva i iznenadit će vas kasnije. Provjerite masku kao i prefiks, jer /25 pushan kao /24 šalje promet susjednih adresa putem koji ga ne može nositi. Zatim potvrdite da je klijent odabrao tunelsko sučelje za tu destinaciju.

Neka selektori uključuju klijentski pool

Za usmjereni pristup koji čuva klijentske adrese, IPsec politika mora štititi promet između poola i udaljenog prefiksa. Selektori napisani za pristupnikovu vlastitu LAN mrežu propuštaju ping i odbacuju klijentov zahtjev, a to je upravo asimetrija koja je pokrenula ovo istraživanje.

Pregledajte dogovorenu politiku kao i konfigurirane prijedloge, na primjer s ipsec statusall na strongSwanu ili ekvivalentnom naredbom stanja za vašu implementaciju. Kod IPsec-a temeljenog na politikama obična ruta može pokazivati na fizičko sučelje dok se odgovarajući promet ipak šifrira, pa nedostatak tunelskog uređaja ništa ne dokazuje. Usporedite parove selektora s poolom i prefiksom koje ste zapisali.

Generički izvorni NAT na pristupniku također može pokvariti podudaranje. Ako masquerade pravilo prepiše klijentov izvor prije provjere politike, paket više ne izgleda kao selektor koji ste napisali. To je jedan razlog zašto je široko masquerade pravilo loše rješenje za drugi VPN: mijenja koja se politika primjenjuje i koju adresu udaljena strana bilježi. Izuzećite promet koji namjeravate usmjeravati ili ga namjerno prevedite i ažurirajte selektore.

Namjerno odaberite usmjeravanje ili prevođenje

Usmjeravanje drži klijentsku adresu vidljivom udaljenoj strani, pa udaljeni dnevnici i pravila po izvoru ostaju smisleni, i zahtijeva da udaljeni pristupnik zna povratni put do poola. Prevođenje skriva pool iza jedne adrese, što uklanja problem povratne rute i uništava identitet svakog klijenta.

Odaberite jedan dizajn i zapišite ga, jer dvoje treba različite selektore i različit redoslijed firewalla. Napola primijenjen masquerade staje između njih i ne zadovoljava nijedno. Zapisani izbor je i ono što sljedećem inženjeru omogućuje da razlikuje pogrešku od namjerne odluke.

Zatvorite petlju na prosljeđivanju i odgovoru

Pristupnik mora prosljeđivati protokol i destinaciju koju namjeravate, što znači uključeno IP prosljeđivanje i lanac prosljeđivanja koji dopušta par. Udaljena strana zatim mora slati odgovore natrag IPsec putem, a to je odluka o usmjeravanju na njihovu pristupniku, ne na vašem. Obje polovice obična su konfiguracija i obje lako ostaju nedovršene. Testirajte ih odvojeno da se nedostajuće pravilo prosljeđivanja ne zamijeni za pokvaren tunel.

Provjerite jednim stvarnim zahtjevom klijenta prema aplikaciji, gledajući kako prelazi OpenVPN sučelje, IPsec odluku i udaljeni host. Promatrajte odgovor kao zasebno opažanje, jer zahtjev koji stigne i odgovor koji se nikada ne vrati izgledaju isto s klijentova mjesta. Jedan praćeni zahtjev vrijedi više od bilo kojeg broja pingova s pristupnika.

Držite odobrenje destinacije uskim dok testirate i potvrdite da klijent bez pravila ne može dosegnuti uslugu. Instalirana ruta plus uspostavljena asocijacija nije isto što i odobren pristup.