Forsvinn Linux VPN-svara? Sjekk rp_filter og ruta

Førespurnader forlèt maskina, VPN-partnaren svarar, og svaret når aldri fram til socketen. Tunnelen er oppe, loggane til partnaren viser at pakken vert send, og ingenting i programmet forklarar stillheita. På Linux er ein av dei vanlege mistenkte omvend veg-filtrering: ein innkomande IPv4-pakke kan verte avvist når kjeldvalideringa ikkje stemmer med ruta kjernen ventar for den kjelda. Å gå gjennom det i rekkjefølgje fortel deg om det er årsaka eller eit samantreff. Det held deg òg frå å slå av ein tryggleikskontroll for å rette ei manglande rute.

Kva kjeldvalideringa avgjer

Kjernen sjekkar om kjeldadressa til ein pakke er plausibel for grensesnittet han kom inn på, ved å slå opp i rutetabellen etter ei rute tilbake til den kjelda. Viss den omvende ruta peikar ein annan stad, kan pakken verte droppa før nokon brannmurregel eller program-socket ser han. Den kontrollen finst for å gjere visse spoofingmønster vanskelegare, og det er òg derfor asymmetriske og policy-ruta design støyter på han, medan kvar vanleg klient på same nettverket fungerer fint. Vanlege klientar har symmetrisk rutering, som er nøyaktig det kontrollen føreset.

Det viktige ordet er plausibel. Pakken kan vere heilt legitim og likevel feile kontrollen, fordi det ikkje er legitimiteten som vert testa.

Les den effektive modusen, ikkje eitt felt

Det finst tre modusar: deaktivert, streng og laus. Streng pålegg ei anna ruteforventing enn laus, og den globale innstillinga samverkar med dei per grensesnitt, så å lese éi fil kan skildre feil kva som faktisk gjeld. Les båe, og les dei på grensesnittet som mottek svaret, ikkje på grensesnittet til standardruta.

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 linja er den delen folk hoppar over. Det fortel deg kva kjernen meiner om kjelda, og det er nøyaktig inndataen til kontrollen.

Finn avviket før du endrar kontrollen

Finn ut kvifor svaret kjem inn på det grensesnittet og om den omvende ruta skal vere annleis. Ein policyregel som sender førespurnader ut éin veg medan svar kjem tilbake ein annan, er eit legitimt design, og det er òg designet streng validering avviser. Merke som vert brukte i policy-rutering kan ha noko å seie her òg, sidan dei endrar kva det omvende oppslaget returnerer.

Viss den omvende ruta rett og slett manglar, rettar det å leggje ho til årsaka i staden for å slå av ein kontroll. Ei manglande rute, ein brannmur-avvising og ein feil trafikkveljar gir alle det same synlege symptomet, og berre éin av dei handlar om kjeldvalidering.

Ikkje slå av kjeldkontrollar globalt som første reaksjon. Det byter ein konkret diagnose mot ei brei åtferdsendring du må hugse seinare.

Ei selektiv justering du kan forsvare

Viss ei smal justering verkeleg er nødvendig, avgrens ho til grensesnittet som treng ho, skriv ned kvifor, og legg ho i konfigurasjonen som eig det grensesnittet, slik at ho overlever ein omstart. Test deretter på nytt nøyaktig den flyten som feila, frå same kjelda til same målet, i staden for ein ping til noko praktisk.

Ta med eit tilfelle som framleis bør avvisast. Viss det tilfellet no lukkast, svekte justeringa meir enn den eine vegen du ville reparere.

Hald IPv4 og IPv6 åtskilde

Ein kjend utsjåande sysctl er ikkje ein policy for kvar adressefamilie. IPv6 har si eiga åtferd og sine eigne innstillingar, og ei maskin kan vere streng på den eine familien og ettergjevande på den andre utan at nokon merkar det før ein bestemd destinasjon feilar. Sjekk båe viss arbeidslasta brukar båe.

Noter modusen, grensesnittet, utdataen frå ruteoppslaget og årsaka til endringa på ein stad. Den neste personen finn innstillinga og inga forklaring, og vil anten fjerne ho eller kopiere ho ein stad ho ikkje høyrer heime.