Forsvinder Linux VPN-svar? Kontroller rp_filter og ruten

Anmodninger forlader maskinen, VPN-partneren svarer, og svaret når aldrig socketen. Tunnelen er oppe, partnerens logfiler viser, at pakken sendes, og intet i programmet forklarer tavsheden. På Linux er et af de sædvanlige mistænkte reverse-path-filtrering: en indgående IPv4-pakke kan afvises, når kildevalideringen ikke stemmer overens med den rute, som kernen forventer for den kilde. At gennemgå det i rækkefølge fortæller dig, om det er årsagen eller en tilfældighed. Det holder dig også fra at slå en sikkerhedskontrol fra for at rette en manglende rute.

Hvad kildevalideringen afgør

Kernen kontrollerer, om en pakkes kildeadresse er sandsynlig for det interface, den ankom på, ved at slå op i routingtabellen efter en rute tilbage til den kilde. Hvis den omvendte rute peger et andet sted hen, kan pakken blive droppet, før nogen firewallregel eller program-socket ser den. Den kontrol findes for at gøre bestemte spoofingmønstre sværere, og det er også derfor asymmetriske og policy-routede designs støder på den, mens enhver almindelig klient på samme netværk fungerer fint. Almindelige klienter har symmetrisk routing, hvilket er præcis det, kontrollen forudsætter.

Det vigtige ord er sandsynlig. Pakken kan være helt legitim og alligevel fejle kontrollen, fordi det ikke er legitimitet, der testes.

Læs den effektive tilstand, ikke ét felt

Der findes tre tilstande: deaktiveret, streng og løs. Streng pålægger en anden ruteforventning end løs, og den globale indstilling spiller sammen med dem per interface, så en enkelt fil kan beskrive forkert, hvad der faktisk gælder. Læs begge, og læs dem på det interface, der modtager svaret, ikke på standardrutens interface.

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

Ruteopslaget i den tredje linje er den del, folk springer over. Det fortæller dig, hvad kernen mener om kilden, og det er præcis inputtet til kontrollen.

Find uoverensstemmelsen, før du ændrer kontrollen

Find ud af, hvorfor svaret ankommer på det interface, og om dets omvendte rute bør være anderledes. En politikregel, der sender anmodninger ud ad én vej, mens svar vender tilbage ad en anden, er et legitimt design, og det er også det design, som streng validering afviser. Mærker brugt i policy-routing kan også have betydning her, da de ændrer, hvad det omvendte opslag returnerer.

Hvis den omvendte rute simpelthen mangler, retter det årsagen at tilføje den i stedet for at slå en kontrol fra. En manglende rute, en firewall-afvisning og en forkert trafikvælger giver alle det samme synlige symptom, og kun én af dem handler om kildevalidering.

Slå ikke kildekontroller fra globalt som den første reaktion. Det bytter en konkret diagnose for en bred adfærdsændring, som du senere skal huske.

En selektiv justering, du kan forsvare

Hvis en snæver justering virkelig er nødvendig, begræns den til det interface, der har brug for den, skriv ned hvorfor, og læg den i den konfiguration, der ejer det interface, så den overlever en genstart. Test derefter præcis det flow, der fejlede, fra samme kilde til samme destination, i stedet for en ping til noget bekvemt.

Medtag et tilfælde, der stadig bør afvises. Hvis det tilfælde nu lykkes, svækkede justeringen mere end den ene vej, du ville reparere.

Hold IPv4 og IPv6 adskilt

En kendt udseende sysctl er ikke en politik for hver adressefamilie. IPv6 har sin egen adfærd og sine egne indstillinger, og en maskine kan være streng på den ene familie og eftergivende på den anden, uden at nogen opdager det, før en bestemt destination fejler. Kontroller begge, hvis arbejdsbelastningen bruger begge.

Notér tilstanden, interfacet, ruteopslagets output og årsagen til ændringen ét sted. Den næste person finder indstillingen og ingen forklaring og vil enten fjerne den eller kopiere den et sted, hvor den ikke hører til.