Kvifor ei OpenVPN-klientblokkeringsregel aldri treffer FORWARD

To klientar på same OpenVPN-tenar kan nå kvarandre sjølv om du har lagt til ei DROP-regel for utvalet deira. Regelen sit i FORWARD-kjeda, trafikken flyt tydeleg, og teljaren for den regelen blir ståande på null. Den naturlege konklusjonen er at brannmuren er øydelagd. Oftare har pakken aldri kome inn i kjeda i det heile.

Det er to vegar ein peer-pakke kan ta gjennom ein OpenVPN-tenar, og dei blir avgjorde av konfigurasjonen, ikkje av brannmuren. Å vite kva veg som er i bruk fortel deg om ein vertsregel i det heile er på rett stad.

To vegar ein peer-pakke kan ta

Når valet for intern videresending er slått av, kjem ein pakke frå klient A inn på tunnelgrensesnittet med ein destinasjon innanfor den tildelte adressa til klient B. Rutetabellen til tenaren sender han ut att gjennom same tunnelgrensesnitt, fordi tenaren eig ruta til adressa til B. Det er ein inn-og-ut-straum gjennom verten, og IPv4-videresendingsvegen vurderer han.

Når valet for intern videresending er slått på, matchar tenarprosessen pakken mot ein tilkopla klient og skriv han tilbake til den klienten sjølv. Pakken blir handsama inne i daemonen og kjem aldri attende i tunneleininga, så videresendingsvegen til verten blir hoppa heilt over. OpenVPN 2.6-handboka skildrar dette valet som intern klient-til-klient-videresending, og det er nettopp derfor ein brannmurregel på verten ikkje kan sjå han.

Det finst ein tredje variant i installasjonar som flyttar datakanalen til ein kjernemodul. Videresendingsavgjerda og krypteringa flyttar ut av brukarrommet, og om netfilter ser straumen avheng av korleis overføringsvegen er bygd. Gå aldri ut frå at eit gamalt regelsett oppfører seg på ein overført tenar som på ein i brukarrommet. Stadfest modusen frå den køyrande konfigurasjonen, ikkje frå pakkeversjonen.

Når teljaren aldri rører seg

Ein nullteljar betyr at pakken ikkje matcha den regelen på det punktet, og det er fleire grunnar. Den første er omvegen ovanfor: trafikken nådde aldri kjeda. Den andre er ein mismatch i grensesnitt, retning, kjelde eller destinasjon, noko som er vanleg når utvalet er omnummerert og regelen framleis nemner det gamle prefikset.

Den tredje er plassering. Ein regel tidlegare i kjeda kan godta straumen før DROP-en din blir vurdert, og ein regel seinare kan vere den som faktisk avgjer resultatet. Les kjeda i rekkjefølgje med teljarane synlege, og sjekk deretter kva regel som aukar når du gjer testen om att.

Gjer éin kontrollert utveksling mellom to klientar der du har stadfesta dei verkelege adressene deira frå tilstanden til tenaren sjølv, ikkje frå ein lease du hugsar. Flyttar den aktuelle teljaren seg framleis ikkje, mistenk vegen før du skriv om matchinga. Flyttar han seg men tilkoplinga lukkast framleis, blir droppet overstyrt seinare og rekkjefølgja er problemet. Det svaret avgjer om reparasjonen er ei regelendring eller ei topologiendring, så skaff det før du redigerer noko.

Å velje ei grense som kan filtrere

Viss policyen må bu i brannmuren på verten, set trafikken der brannmuren kan sjå han. Å slå av intern videresending er den støtta måten å få peer-trafikk til å gå gjennom tunnelgrensesnittet og videresendingsvegen, mot at kvar peer-pakke går gjennom stacken til verten.

Match deretter straumen nøyaktig. Trafikk kjem inn på tunnelgrensesnittet og går ut på tunnelgrensesnittet, i begge retningar, så reglar som berre ser på det fysiske grensesnittet vil ikkje matche. Adressebaserte reglar treng det gjeldande utvalet, og dei må ta omsyn til returretninga like mykje som den fremre.

Mange installasjonar tener på filtrering på klient- eller gruppenivå, der identiteten er kjend og policyen følgjer brukaren i staden for ei adresse som endrar seg ved gjenoppkopling. Det er ein annan mekanisme enn ei vertskjede, og dei to bør ikkje blandast utan ein klar grunn.

Ikkje flytt eit regelsett frå ein gamal topologi gjennom ein migrering uendra. Adresseutval, grensesnittnamn og videresendingsmodusar påverkar alle om ein regel matchar, og ein kopiert regel som før virka er den mest villleiande typen bevis. Start med straumen du vil tillate og skriv regelen som matchar han.

Å teste isolasjon i staden for å stole på ein regel

Test det forbodne tilfellet og det tillatne tilfellet i same køyring. Start ei ny tilkopling frå den eine klienten til den andre og stadfest at ho feilar, stadfest deretter at ei tilkopling som burde vere tillaten framleis verkar. Viss berre det første blir testa, ser ein brannmur som blokkerer alt ut som ein suksess.

Gjenta etter å ha lasta tenarkonfigurasjonen på nytt og etter at ein klient koplar til att, fordi intern videresending og utvalstildelingar er køyretidstilstand. Sjekk teljarar i begge retningar, sidan ein regel som matchar éi retning og ikkje svaret gir delvis isolasjon som er vanskeleg å leggje merke til i ein rask test.

Isolasjon er det observerte resultatet ved grensa som faktisk ber straumen. Ein DROP-regel ein stad på verten er ikkje bevis; ei mislukka tilkopling pluss ein flytta teljar på regelen som førte til det er det.