Zakaj odjemalci OpenVPN zgrešijo IPsec selektorje prehoda

Pošljite ping s prehoda na gostitelja za oddaljenim tunelom IPsec in ta čisto odgovori, zato je tunel videti zdrav in zahtevek gre naprej. Nato povezan odjemalec poskusi istega gostitelja in ne prejme ničesar. Tisti ping nikoli ni bil dokaz za tok odjemalca, ker je odšel z lastnim izvornim naslovom prehoda in se ujemal z drugim selektorjem IPsec. Razumevanje, zakaj se ta dva primera razhajata, je večji del popravka.

Ping s prehoda preizkusi tok, ki ga vaš odjemalec nikoli ne uporabi

Izvorni naslov odloči, katera politika velja. Paket, ustvarjen na prehodu, odide z naslovom iz njegovega lokalnega omrežja LAN ali s končne točke tunela, politika, ki se z njim ujema, pa je bila napisana točno za ta primer. Paket odjemalca pride na vmesnik OpenVPN z naslovom iz bazena odjemalcev, kar je povsem drug selektor.

Zato je videti napaka kot težava usmerjanja, v resnici pa je težava obsega politike. Dosegljivost s prehoda dokazuje, da je partner živ in da so bili predlogi dogovorjeni, in ne dokazuje ničesar o tem, ali je bazen zaščiten.

Potisnite oddaljeno predpono, ki jo aplikacija zares potrebuje

Vzemite ilustrativni par 10.8.0.0/24 za povezane odjemalce in 172.30.239.0/25 za zaščiteno oddaljeno omrežje. Odjemalec potrebuje pot do druge predpone, ne do omrežja LAN prehoda in ne do kakšnega drugega naslova tunela. Prav v bazen potisnjena pot poskrbi, da odjemalec sploh izroči ta promet prehodu. Brez nje paket nikoli ne doseže odločitve o politiki, ki jo razhroščujete.

Na strežniku Community, ki sprejema potisnjene poti, direktiva prevzame pravo masko: push "route 172.30.239.0 255.255.255.128". Access Server konfigurira isti cilj prek nastavitev zasebnega omrežja ali pravil dostopa nameščene različice, pri čemer je usmerjeni ali prevedeni način izbran namenoma. Urejanje ustvarjenih verig požarnega zidu namesto lastne konfiguracije je pot, po kateri delujoča namestitev postane nereproduktivna.

Po povezavi berite usmerjevalno tabelo odjemalca in ne namero strežnika. Pot, ki pokriva samo bazen, pomeni, da potisk ni prispel, privzeta pot skozi tunel pa je širša od te zahteve in vas bo pozneje presenetila. Preverite masko in predpono, ker /25, potisnjena kot /24, pošilja promet sosednjih naslovov po poti, ki ga ne zmore nesti. Nato potrdite, da je odjemalec za ta cilj izbral vmesnik tunela.

Naj selektorji vključujejo bazen odjemalcev

Za usmerjen dostop, ki ohranja naslove odjemalcev, mora politika IPsec zaščititi promet med bazenom in oddaljeno predpono. Selektorji, napisani za lastno omrežje LAN prehoda, spustijo ping in zavržejo zahtevo odjemalca, in prav to je asimetrija, ki je začela to preiskavo.

Preglejte dogovorjeno politiko in tudi konfigurirane predloge, na primer s ipsec statusall na strongSwanu ali enakovrednim statusnim ukazom za vašo izvedbo. Pri IPsec, ki temelji na politikah, lahko običajna pot kaže na fizični vmesnik, medtem ko je ujemajoči promet še vedno šifriran, zato odsotna tunelska naprava ne dokazuje ničesar. Primerjajte pare selektorjev z bazenom in predpono, ki ste ju zapisali.

Splošni izvorni NAT na prehodu lahko prav tako pokvari ujemanje. Če pravilo masquerade prepiše vir odjemalca pred preverjanjem politike, paket ni več videti kot selektor, ki ste ga napisali. To je eden od razlogov, zakaj je široko pravilo masquerade slab popravek za drugi VPN: spremeni, katera politika velja in kateri naslov zabeleži oddaljena stran. Izvzemite promet, ki ga nameravate usmerjati, ali ga namenoma prevedite in posodobite selektorje.

Namenoma izberite usmerjanje ali prevajanje

Usmerjanje ohrani naslov odjemalca viden oddaljeni strani, zato oddaljeni dnevniki in pravila po viru ostanejo smiselni, in zahteva, da oddaljeni prehod pozna povratno pot do bazena. Prevajanje skrije bazen za enim naslovom, kar odpravi težavo povratne poti in uniči identiteto posameznega odjemalca.

Izberite eno zasnovo in jo zapišite, ker obe potrebujeta različne selektorje in drugačen vrstni red požarnega zidu. Na pol uporabljen masquerade pristane med njima in ne zadovolji nobenega. Zapisana izbira je tudi tisto, kar naslednjemu inženirju omogoči, da razlikuje napako od namerne odločitve.

Zaprite zanko pri posredovanju in odgovoru

Prehod mora posredovati protokol in cilj, ki ju imate v mislih, kar pomeni vklopljeno posredovanje IP in verigo posredovanja, ki paru dovoljuje prehod. Nato mora oddaljena stran pošiljati odgovore nazaj po poti IPsec, in to je odločitev o usmerjanju na njihovem prehodu, ne na vašem. Obe polovici sta običajna konfiguracija in obe zlahka ostaneta nedokončani. Preizkusite ju ločeno, da manjkajoče pravilo posredovanja ne bo zamenjano za pokvarjen tunel.

Preverite z eno resnično zahtevo od odjemalca do aplikacije, pri tem pa opazujte, kako prečka vmesnik OpenVPN, odločitev IPsec in oddaljenega gostitelja. Odgovor pregledajte kot ločeno opazovanje, ker sta zahteva, ki prispe, in odgovor, ki se nikoli ne vrne, z mesta odjemalca videti enako. Ena sledena zahteva je vredna več kot poljubno število pingov s prehoda.

Med preizkušanjem držite dovoljenje za cilj ozko in potrdite, da odjemalec brez pravila ne more doseči storitve. Nameščena pot in vzpostavljena asociacija nista isto kot odobren dostop.