Kial regulo blokanta OpenVPN-klienton neniam trafas FORWARD

Du klientoj sur la sama OpenVPN-servilo povas atingi unu la alian eĉ post kiam vi aldonis DROP-regulon por ilia aro. La regulo sidas en la FORWARD-ĉeno, la trafiko videble fluas, kaj la nombrilo de tiu regulo restas je nulo. La natura konkludo estas, ke la fajroŝirmilo estas difektita. Pli ofte la paketo tute ne eniris la ĉenon.

Ekzistas du vojhoj, kiujn paketo de samtavolano povas trairi OpenVPN-servilon, kaj ilin decidas la agordo, ne la fajroŝirmilo. Scii, kiu vojo estas uzata, diras al vi, ĉu regulo de la gastiganto entute staras en la ĝusta loko.

Du vojhoj, kiujn paketo de samtavolano povas trairi

Kiam la opcio pri interna plusendado estas malŝaltita, paketo de kliento A alvenas sur la tunelan interfacon kun celo ene de la atribuita adreso de kliento B. La enkursiga tabelo de la servilo resendas ĝin tra la sama tunela interfaco, ĉar la servilo posedas la vojhon al la adreso de B. Tio estas enira kaj elira fluo tra la gastiganto, kaj la IPv4-plusenda vojo ĝin taksas.

Kiam la opcio pri interna plusendado estas ŝaltita, la servila procezo kunordigas la paketon al konektita kliento kaj skribas ĝin reen al tiu kliento mem. La paketo estas traktata ene de la demono kaj neniam reeniras la tunelan aparaton, do la plusenda vojo de la gastiganto estas tute preterlasata. La manlibro de OpenVPN 2.6 priskribas tiun opcion kiel internan plusendadon de kliento al kliento, kaj ĝuste tial regulo de la gastiganta fajroŝirmilo ne povas ĝin vidi.

Tria variaĵo ekzistas en enkondukoj, kiuj transigas la datuman kanalon al kernmodulo. La plusenda decido kaj la ĉifrado eliras el la uzula spaco, kaj ĉu netfilter vidas la fluon dependas de tio, kiel estas konstruita la transiga vojo. Neniam supozu, ke malnova regulkompleto kondutas sur transiga servilo same kiel sur unu en la uzula spaco. Konfirmu la reĝimon el la kuranta agordo, ne el la paka versio.

Kiam la nombrilo neniam moviĝas

Nula nombrilo signifas, ke la paketo ne kongruis kun tiu regulo en tiu punkto, kaj la kialoj estas pluraj. La unua estas la ĉirkaŭvojo supre: la trafiko neniam atingis la ĉenon. La dua estas malkongruo en interfaco, direkto, fonto aŭ celo, kio oftas kiam la aro estis renumerita kaj la regulo ankoraŭ nomas la malnovan prefikson.

La tria estas pozicio. Regulo pli frue en la ĉeno povas akcepti la fluon antaŭ ol via DROP estas taksata, kaj regulo pli poste povas esti tiu, kiu fakte decidas la rezulton. Legu la ĉenon laŭorde kun videblaj nombriloj, poste kontrolu, kies nombrilo kreskas kiam vi ripetas la teston.

Plenumu unu kontrolitan interŝanĝon inter du klientoj, kies verajn adresojn vi konfirmis el la propra stato de la servilo, ne el luo, kiun vi memoras. Se la koncerna nombrilo ankoraŭ ne moviĝas, suspektu la vojon antaŭ ol reverki la kongruon. Se ĝi moviĝas sed la konekto ankoraŭ sukcesas, la forĵeto estas superata pli poste kaj la ordo estas la problemo. Tiu respondo decidas, ĉu la riparo estas ŝanĝo de regulo aŭ ŝanĝo de topologio, do akiru ĝin antaŭ ol redakti ion ajn.

Elekti limon, kiu povas filtri

Se la politiko devas loĝi en la fajroŝirmilo de la gastiganto, metu la trafikon tie, kie la fajroŝirmilo povas ĝin vidi. Malŝalti internan plusendadon estas la subtenata maniero igi trafikon de samtavolanoj trapasi la tunelan interfacon kaj la plusendan vojon, je la kosto de sendado de ĉiu paketo de samtavolano tra la stako de la gastiganto.

Poste kongruigu la fluon precize. Trafiko alvenas sur la tunelan interfacon kaj forlasas la tunelan interfacon, en ambaŭ direktoj, do reguloj, kiuj konsideras nur la fizikan interfacon, ne kongruos. Reguloj bazitaj sur adresoj bezonas la nunan aron, kaj ili devas konsideri la revenan direkton same kiel la antaŭan.

Multaj enkondukoj pli bone servatas per filtrado je klienta aŭ grupa nivelo, kie la identeco estas konata kaj la politiko sekvas la uzanton anstataŭ adreson, kiu ŝanĝiĝas ĉe rekonekto. Tio estas alia mekanismo ol ĉeno de la gastiganto, kaj la du ne miksiĝu sen klara kialo.

Ne transigu la regulkompleton de malnova topologio senŝanĝe tra migrado. Adresaroj, interfacaj nomoj kaj plusendaj reĝimoj ĉiuj influas, ĉu regulo kongruas, kaj kopiita regulo, kiu antaŭe funkciis, estas la plej misgvida speco de pruvo. Komencu de la fluo, kiun vi volas permesi, kaj skribu la regulon, kiu al ĝi kongruas.

Testi izolecon anstataŭ fidi regulon

Testu la malpermesitan kazon kaj la permesitan kazon en la sama rulado. Komencu novan konekton de unu kliento al la alia kaj konfirmu, ke ĝi malsukcesas, poste konfirmu, ke konekto, kiu devus esti permesita, ankoraŭ funkcias. Se nur la unua estas testata, fajroŝirmilo, kiu blokas ĉion, aspektas kiel sukceso.

Ripetu post reŝarĝo de la servila agordo kaj post kiam kliento rekonektiĝas, ĉar interna plusendado kaj araj atribuoj estas stata informo de plenumtempo. Kontrolu nombrilojn en ambaŭ direktoj, ĉar regulo, kiu kongruas kun unu direkto kaj ne kun la respondo, kreas partan izolecon, kiun estas malfacile rimarki en rapida testo.

Izoleco estas la observata rezulto ĉe la limo, kiu fakte portas la fluon. DROP-regulo ie en la gastiganto ne estas pruvo; malsukcesa konekto plus moviĝinta nombrilo ĉe la regulo, kiu kaŭzis ĝin, estas pruvo.