Kial VPN-kliento en la oficeja loka reto perdas ĉiun respondon

Tekkomputilo sidas en la /24 de la oficejo per Ethernet kaj samtempe aliĝas al OpenVPN-servilo, kiu loĝas en la sama /24. Kolego pingas la tunelan adreson; la peto klare alvenas, kaj nenio revenas. La tunela protokolo estas pura kaj retumado ankoraŭ funkcias, do la tunelo estas la malĝusta suspektato. IPv4-fonta validigo sur la ricevanta maŝino forĵetas la paketon antaŭ ol io ajn legas ĝin.

La forĵeto okazas antaŭ ol io legas la paketon

Fonta validigo demandas unu demandon pri ĉiu envenanta paketo: se ĉi tiu gastiganto respondus al tiu fonto, ĉu la respondo elirus tra la interfaco, sur kiu la paketo ĵus alvenis? Kiam la respondo estas ne, la kerno forĵetas la paketon tuj ĉe alveno. Nek ingo nek plusenda vojo iam vidas ĝin, kaj tial kapto sur la tunelo ankoraŭ registras peton, kiun la aplikaĵo neniam ricevas.

La kliento ĉi tie tenas 10.66.0.9 sur sia tunelo, kaj la OpenVPN-servilo respondas ĉe 192.168.80.10 ene de la oficeja prefikso. Kolego ĉe 192.168.80.25 pingas la tunelan adreson, do la peto transiras la lokan reton, la servilo enkursigas ĝin en la tunelon, kaj ĝi alvenas sur la tunela interfaco de la kliento portante oficejan fontan adreson. En la enkursiga tabelo de tiu maŝino la oficeja prefikso apartenas al la Ethernet-aparato, ne al la tunelo. La validigo komparas la alvenan interfacon kun la vojo, trovas malkongruon kaj forĵetas la paketon, do la kolego vidas plenan perdon dum ambaŭ finoj raportas sanan tunelon.

La spegula direkto havas la saman formon: kiam la kliento iniciatas al la oficejo, respondoj povas esti forĵetitaj ĉe la oficeja flanko pro la sama kialo. Riparo kontrolita nur en unu direkto emas reveni kiel dua bileto.

Pruvu la validan reĝimon antaŭ ol tuŝi ajnan sysctl

Legu la efektivajn valorojn anstataŭ fidi distribuadan defaŭlton, ĉar la agordo por interfaco estas nur duono de la decido. La valida reĝimo estas la pli alta el la interfaca valoro kaj la valoro de all, do nulo sur la tunela interfaco signifas nenion dum all estas unu. La decido de la strikta reĝimo estas enkursiga decido, do rulu la serĉon, kiun rulas la kerno, kaj komparu ĝian respondon kun la interfaco, sur kiu la paketo efektive alvenis.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Poste ripetu la pingon dum vi observas la eraran nombrilon. Kreskanta nombro apud peto, kiun la kapto jam montras, estas la signo de ĉi tiu forĵeto, ne de mankanta vojo. Ŝaltu marsan protokoladon dum vi estas tie, por ke la kerno nomu la fonton kaj la interfacon, kiun ĝi rifuzis. Kune ili ekskludas la ĉifron, la fajroŝirmilon kaj mankantan iroute kiel klarigojn.

Skribu la bazlinion antaŭ ol ŝanĝi ion: ambaŭ valorojn, la aparaton, kiun elektis la serĉo, kaj la nombrilon, kiun vi observis. Ĝuste tiu registro diras al vi poste, ĉu la ŝanĝo faris tion, kion vi pensas.

Kion ĉiu rp_filter-reĝimo efektive akceptas

La kerno montras tri valorojn por interfaco, kaj ili ne estas tri nuancoj de unu regulo. Nulo malŝaltas la kontrolon. Unu estas strikta kaj postulas, ke la fonto estu enkursigita reen tra la alvena interfaco. Du estas malfiksa kaj postulas nur, ke ekzistu ia vojo al la fonto en la tabelo, kien ajn ĝi montras.

La vico, kiu gravas ĉi tie, estas la malfiksa, kaj tio, kion ĝi daŭre rifuzas. Falsa fonto, kiu estas enkursigebla ie ajn en via tabelo, pasas, dum fonto tute sen vojo ankoraŭ estas rifuzata. Sur tekkomputilo tio estas mallarĝa cedado; sur enkursigilo, kiu plusendas trafikon por aliaj homoj, ĝi estas larĝa. La reĝimo apartenas al la gastiganto, do la sama nombro portas malsaman pezon en la du lokoj.

Kiun vicon ĉi tiu topologio bezonas, sekvas el la tabelo, ne el kutimo. La paketo estas legitima kaj ĝia fonto estas enkursigebla, do la malfiksa akceptas ĝin kaj la strikta ne. Nenio en la kazo postulas nulon, kaj elekti nulon forigus kontrolon, kiu ĉi tie kostas nenion.

Elektu la plej malgrandan ŝanĝon, kiu forigas la ambaŭsecon

La malfiksa reĝimo estas la plej malgranda ŝanĝo, kiu taŭgas, kaj ĝi estas reala malstreĉiĝo de strikteco, ne sendanĝera ŝaltilo. Pli bona opcio ekzistas ĉiam, kiam la topologio permesas: forigu la interkovron, kaj la ambaŭseco malaperas.

Kie la oficeja prefikso bezonatas nur per Ethernet, forigu ĝin el la vojoj, kiujn la profilo tiras, kaj la adreso fariĝos atingebla per unu vojo. Kiam ambaŭ vojoj vere devas kunekzisti, fiksu la fonton kaj la aparaton per politika regulo anstataŭ malstreĉi la validigon sur ĉiu interfaco. Tio konservas striktan filtradon por ĉio alia sur la maŝino kaj dokumentas la escepton tie, kie la sekva inĝeniero serĉos ĝin.

Kiun ajn vojon vi elektos, registru ĝin en sysctl-drop-in anstataŭ en viva komando. Agordu la ŝlosilojn all kaj default kune, por ke rekonekto ne povu kviete restarigi la striktan reĝimon.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Kion la malfiksa reĝimo rezignas, kaj kie

La malfiksa reĝimo ankoraŭ rifuzas fonton, kiun neniu vojo povus atingi, kaj ĝi ĉesas rifuzi falsan fonton, kiu hazarde estas enkursigebla. Sur tekkomputilo tio estas mallarĝa cedado. Sur aparato, kiu plusendas trafikon, kiun ĝi ne posedas, la sama elekto estas multe pli larĝa. La sama agordo do portas du tre malsamajn signifojn depende de tio, kie ĝi funkcias.

Tute malŝalti la kontrolon sur gastiganto, kiu plusendas trafikon por aliaj homoj, estas la unu riparo, kiun oni evitu. Nulo forĵetas la validigon, kiun la malfiksa reĝimo zorgeme konservas. Se la gastiganto plusendas por aliaj, argumentu anstataŭe por la politika-regula opcio el la antaŭa sekcio.

Lasu noton nomantan la du interfacojn, la interkovrantan prefikson kaj la precizan provon, kiu nun sukcesas. Tio estas pli utila por la sekva inĝeniero ol linio diranta, ke la filtrado estis ĝustigita.