Linux-VPN-antwoorde verdwyn? Kontroleer rp_filter en die roete

Versoeke verlaat die masjien, die VPN-eweknie antwoord, en die antwoord bereik nooit die sok nie. Die tonnel is op, die eweknie se logboeke wys dat die pakkie gestuur word, en niks in die toepassing verduidelik die stilte nie. Op Linux is een van die gewone verdagtes terugpadfiltrering: 'n inkomende IPv4-pakkie kan verwerp word wanneer bronvalidering nie ooreenstem met die roete wat die kern vir daardie bron verwag nie. Om dit in volgorde na te gaan, sê vir jou of dit die oorsaak is of 'n toevalligheid. Dit keer ook dat jy 'n sekuriteitsbeheer afskakel om 'n ontbrekende roete reg te maak.

Wat bronvalidering besluit

Die kern kyk of 'n pakkie se bronadres geloofwaardig is vir die koppelvlak waarop dit aangekom het, deur die roetertabel te raadpleeg vir 'n roete terug na daardie bron. As die terugroete elders heen wys, kan die pakkie laat val word voordat enige brandmuurreël of toepassingsok dit sien. Daardie kontrole bestaan om sekere vervalsingspatrone moeiliker te maak, en dit is ook hoekom asimmetriese en beleidsgeroeteerde ontwerpe daarop afkom terwyl elke gewone kliënt op dieselfde netwerk fyn werk. Gewone kliënte het simmetriese roetering, wat presies is wat die kontrole veronderstel.

Die belangrike woord is geloofwaardig. Die pakkie kan heeltemal wettig wees en steeds die kontrole faal, want wettigheid is nie wat getoets word nie.

Lees die effektiewe modus, nie een veld nie

Daar is drie modusse: gedeaktiveer, streng en los. Streng stel 'n ander roeteverwagting as los, en die globale instelling werk saam met die per-koppelvlak-instellings, so om 'n enkele lêer te lees kan verkeerd beskryf wat werklik geld. Lees albei, en lees hulle op die koppelvlak wat die antwoord ontvang, nie op die koppelvlak van die verstekroete nie.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Die roete-opsoek in daardie derde reël is die deel wat mense oorslaan. Dit vertel jou wat die kern oor die bron glo, wat presies die inset vir die kontrole is.

Vind die wanverhouding voordat jy die kontrole verander

Werk uit hoekom die antwoord op daardie koppelvlak aankom en of sy terugroete veronderstel is om te verskil. 'n Beleidsreël wat versoeke een pad uitstuur terwyl antwoorde op 'n ander terugkom, is 'n wettige ontwerp, en dit is ook die ontwerp wat streng validering verwerp. Merktekens wat in beleidsroetering gebruik word, kan hier ook saak maak, want hulle verander wat die terugsoek oplewer.

As die terugroete bloot ontbreek, maak die byvoeg daarvan die oorsaak reg eerder as om 'n kontrole af te skakel. 'n Ontbrekende roete, 'n brandmuurverwerping en 'n verkeerde verkeerskeurder lewer almal dieselfde sigbare simptoom, en net een van hulle gaan oor bronvalidering.

Moenie bronkontroles as eerste reaksie globaal afskakel nie. Dit ruil 'n spesifieke diagnose vir 'n breë gedragsverandering wat jy later sal moet onthou.

'n Selektiewe aanpassing wat jy kan verdedig

As 'n nou aanpassing werklik nodig is, beperk dit tot die koppelvlak wat dit nodig het, skryf neer hoekom, en sit dit in die konfigurasie wat daardie koppelvlak besit sodat dit 'n herboot oorleef. Toets dan weer die presiese vloei wat gefaal het, van dieselfde bron na dieselfde bestemming, eerder as 'n ping na iets gerieflik.

Sluit 'n geval in wat steeds geweier moet word. As daardie geval nou slaag, het die aanpassing meer verswak as die een pad wat jy wou herstel.

Hou IPv4 en IPv6 apart

'n Bekende sysctl is nie 'n beleid vir elke adresfamilie nie. IPv6 het sy eie gedrag en sy eie instellings, en 'n masjien kan streng op die een familie en toegeeflik op die ander wees sonder dat iemand dit opmerk totdat 'n spesifieke bestemming faal. Kyk na albei as die werkvraging albei gebruik.

Teken die modus, die koppelvlak, die roete-opsoek-uitset en die rede vir die verandering op een plek aan. Die volgende persoon sal die instelling vind en geen verduideliking nie, en sal dit óf verwyder óf op 'n plek kopieer waar dit nie hoort nie.