Forsvinner Linux VPN-svar? Sjekk rp_filter og ruten

Forespørsler forlater maskinen, VPN-partneren svarer, og svaret når aldri frem til socketen. Tunnelen er oppe, loggene til partneren viser at pakken sendes, og ingenting i programmet forklarer stillheten. På Linux er et av de vanlige mistenkte omvendt veifiltrering: en innkommende IPv4-pakke kan avvises når kildevalideringen ikke stemmer med ruten kjernen forventer for den kilden. Å gå gjennom det i rekkefølge forteller deg om det er årsaken eller en tilfeldighet. Det holder deg også fra å slå av en sikkerhetskontroll for å rette en manglende rute.

Hva kildevalideringen avgjør

Kjernen sjekker om kildeadressen til en pakke er plausibel for grensesnittet den kom inn på, ved å slå opp i rutetabellen etter en rute tilbake til den kilden. Hvis den omvendte ruten peker et annet sted, kan pakken bli droppet før noen brannmurregel eller program-socket ser den. Den kontrollen finnes for å gjøre bestemte spoofingmønstre vanskeligere, og det er også derfor asymmetriske og policy-rutede design støter på den, mens enhver vanlig klient på samme nettverk fungerer fint. Vanlige klienter har symmetrisk ruting, som er nøyaktig det kontrollen forutsetter.

Det viktige ordet er plausibel. Pakken kan være helt legitim og likevel feile kontrollen, fordi det ikke er legitimiteten som testes.

Les den effektive modusen, ikke ett felt

Det finnes tre moduser: deaktivert, streng og løs. Streng pålegger en annen ruteforventning enn løs, og den globale innstillingen samvirker med dem per grensesnitt, så å lese én fil kan beskrive feil hva som faktisk gjelder. Les begge, og les dem på grensesnittet som mottar svaret, ikke på standardrutens grensesnitt.

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

Ruteoppslaget i den tredje linjen er den delen folk hopper over. Det forteller deg hva kjernen mener om kilden, og det er nøyaktig inndataen til kontrollen.

Finn avviket før du endrer kontrollen

Finn ut hvorfor svaret kommer inn på det grensesnittet og om den omvendte ruten skal være annerledes. En policyregel som sender forespørsler ut én vei mens svar kommer tilbake en annen, er et legitimt design, og det er også designet streng validering avviser. Merker som brukes i policy-ruting kan ha betydning her også, siden de endrer hva det omvendte oppslaget returnerer.

Hvis den omvendte ruten rett og slett mangler, retter det å legge den til årsaken i stedet for å slå av en kontroll. En manglende rute, en brannmur-avvisning og en feil trafikkvelger gir alle det samme synlige symptomet, og bare én av dem handler om kildevalidering.

Ikke slå av kildekontroller globalt som første reaksjon. Det bytter en konkret diagnose mot en bred atferdsendring du må huske senere.

En selektiv justering du kan forsvare

Hvis en smal justering virkelig er nødvendig, begrens den til grensesnittet som trenger den, skriv ned hvorfor, og legg den i konfigurasjonen som eier det grensesnittet, slik at den overlever en omstart. Test deretter på nytt nøyaktig den flyten som feilet, fra samme kilde til samme mål, i stedet for en ping til noe praktisk.

Ta med et tilfelle som fortsatt bør avvises. Hvis det tilfellet nå lykkes, svekket justeringen mer enn den ene veien du ville reparere.

Hold IPv4 og IPv6 atskilt

En kjent utseende sysctl er ikke en policy for hver adressefamilie. IPv6 har sin egen atferd og sine egne innstillinger, og en maskin kan være streng på den ene familien og ettergivende på den andre uten at noen merker det før en bestemt destinasjon feiler. Sjekk begge hvis arbeidslasten bruker begge.

Noter modusen, grensesnittet, utdataen fra ruteoppslaget og årsaken til endringen på ett sted. Den neste personen finner innstillingen og ingen forklaring, og vil enten fjerne den eller kopiere den et sted den ikke hører hjemme.