Kial OpenVPN-klientoj maltrafas la IPsec-selektilojn de la enirejo
Ping de la enirejo pruvas alian fluon. Spuru la klientaron tra la puŝita itinero, la IPsec-selektiloj, la plusenda ĉeno kaj la responda vojo.
Pregu gastiganton malantaŭ la fora IPsec-tunelo de la enirejo kaj ĝi respondas pure, do la tunelo ŝajnas sana kaj la bileto pluiras. Poste konektita kliento provas la saman gastiganton kaj ricevas nenion. Tiu pingo neniam estis pruvo por la fluo de la kliento, ĉar ĝi eliris kun la propra fontadreso de la enirejo kaj kongruis kun alia IPsec-selektilo. Kompreni kial la du kazoj diverĝas estas la plej granda parto de la solvo.
La pingo de la enirejo testas fluon, kiun via kliento neniam uzas
La fontadreso decidas, kiu politiko validas. Paketo kreita sur la enirejo eliras kun adreso el ĝia loka LAN aŭ el ĝia tunela finpunkto, kaj la politiko kongruanta kun ĝi estis verkita ĝuste por tiu kazo. La paketo de kliento alvenas sur la OpenVPN-interfaco kun adreso el la klientaro, kio estas tute alia selektilo.
Tial la malsukceso aspektas kiel itinera problemo, kvankam ĝi efektive estas problemo de politika amplekso. Atingebleco de la enirejo pruvas, ke la samtavolano funkcias kaj la proponoj estis intertraktitaj, kaj ĝi pruvas nenion pri tio, ĉu la klientaro estas protektita.
Puŝu la foran prefikson, kiun la aplikaĵo vere bezonas
Prenu la ilustran paron 10.8.0.0/24 por konektitaj klientoj kaj 172.30.239.0/25 por la protektita fora reto. Kion kliento bezonas estas itinero al tiu dua prefikso, ne al la LAN de la enirejo kaj ne al iu alia tunela adreso. Itinero puŝita en la klientaron estas tio, kio igas la klienton transdoni tiun trafikon al la enirejo entute. Sen ĝi la paketo neniam atingas la politikan decidon, kiun vi sencimigas.
En Community-servilo, kiu akceptas puŝitajn itinerojn, la direktivo prenas la veran maskon: push "route 172.30.239.0 255.255.255.128". Access Server agordas la saman celon per la agordoj de privata reto aŭ alirreguloj de la instalita versio, kun la itinera aŭ traduka reĝimo elektita konscie. Redakti generitajn fajroŝirmilajn ĉenojn anstataŭ la posedan agordon estas kiel funkcianta aranĝo fariĝas nereproduktebla.
Post konektiĝo legu la itinera tabelo de la kliento, ne la intencon de la servilo. Itinero, kiu kovras nur la klientaron, signifas ke la puŝo neniam alvenis, kaj defaŭlta itinero tra la tunelo estas pli larĝa ol tiu postulo kaj surprizos vin poste. Kontrolu la maskon kaj ankaŭ la prefikson, ĉar /25 puŝita kiel /24 sendas trafikon por najbaraj adresoj en vojon, kiu ne povas porti ĝin. Poste konfirmu, ke la kliento elektis la tunelan interfacon por tiu celo.
Igu la selektilojn inkluzivi la klientaron
Por itinera aliro, kiu konservas klientajn adresojn, la IPsec-politiko devas protekti trafikon inter la klientaro kaj la fora prefikso. Selektiloj verkitaj por la propra LAN de la enirejo akceptas la pingon kaj forĵetas la peton de la kliento, kaj ĝuste tio estas la nesimetrio, kiu komencis ĉi tiun enketon.
Ekzamenu la intertraktitan politikon kaj ankaŭ la agorditajn proponojn, ekzemple per ipsec statusall sur strongSwan aŭ la ekvivalenta statusa komando por via realigo. Ĉe politikbazita IPsec la ordinara itinero povas montri al fizika interfaco dum kongrua trafiko ankoraŭ estas ĉifrata, do mankanta tunela aparato pruvas nenion. Komparu la selektilajn parojn kun la klientaro kaj prefikso, kiujn vi notis.
Ĝenerala fonta NAT sur la enirejo ankaŭ povas rompi la kongruon. Se masquerade-regulo reverkas la fonton de la kliento antaŭ la politika kontrolo, la paketo ne plu aspektas kiel la selektilo, kiun vi verkis. Tio estas unu kialo, kial larĝa masquerade-regulo estas malbona solvo por dua VPN: ĝi ŝanĝas, kiu politiko validas kaj kiun adreson la fora flanko registras. Esceptu la trafikon, kiun vi intencas itinigi, aŭ traduku ĝin konscie kaj ĝisdatigu la selektilojn.
Elektu itinigon aŭ tradukon intence
Itinigo tenas la klientan adreson videbla por la fora flanko, do foraj protokoloj kaj reguloj laŭ fonto restas signifoplenaj, kaj ĝi postulas, ke la fora enirejo sciu la revenan vojon al la klientaro. Traduko kaŝas la klientaron malantaŭ unu adreso, kio forigas la revenvojan problemon kaj detruas la identecon laŭ kliento.
Elektu unu dezajnon kaj skribu ĝin, ĉar la du bezonas malsamajn selektilojn kaj malsaman fajroŝirmilan ordon. Duone aplikita masquerade falas inter ili kaj kontentigas neniun. La skribita elekto ankaŭ estas tio, kio ebligas al la sekva inĝeniero distingi cimon de intenca decido.
Fermu la cirklon pri plusendo kaj la respondo
La enirejo devas plusendi la protokolon kaj celon, kiujn vi intencas, kio signifas ŝaltitan IP-plusendon kaj plusendan ĉenon, kiu permesas la paron. Poste la fora flanko devas resendi respondojn tra la IPsec-vojo, kaj tio estas itinera decido sur ilia enirejo, ne sur via. Ambaŭ duonoj estas ordinaraj agordoj, kaj ambaŭ facile restas duonfinaj. Testu ilin aparte, por ke mankanta plusenda regulo ne estu konfuzita kun rompita tunelo.
Kontrolu per unu reala peto de kliento al aplikaĵo, rigardante ĝin trapasi la OpenVPN-interfacon, la IPsec-decidon kaj la foran gastiganton. Ekzamenu la respondon kiel apartan observon, ĉar peto, kiu alvenas, kaj respondo, kiu neniam revenas, aspektas idente de la sidloko de la kliento. Unu spurita peto valoras pli ol ajna nombro da enirejaj pingoj.
Tenu la celan rajtigon mallarĝa dum vi testas, kaj konfirmu, ke kliento sen la regulo ne povas atingi la servon. Instalita itinero plus establita asocio ne estas la sama afero kiel donita aliro.