Verdwijnen de antwoorden van Linux VPN? Controleer rp_filter en de route
IPv4-bronvalidatie kan een pakket weigeren waarvan de terugroute niet bij de modus past. Onderzoek de routering en de effectieve instelling voordat u die uitschakelt.
Verzoeken verlaten de machine, de VPN-peer antwoordt, en het antwoord bereikt nooit de socket. De tunnel staat, de logs van de peer laten zien dat het pakket wordt verzonden, en niets in de toepassing verklaart de stilte. Op Linux is een van de gebruikelijke verdachten reverse-path-filtering: een inkomend IPv4-pakket kan worden geweigerd wanneer de bronvalidatie niet overeenkomt met de route die de kernel voor die bron verwacht. Het in volgorde doorlopen vertelt u of dat de oorzaak is of toeval. Het weerhoudt u er ook van een beveiligingsmaatregel uit te schakelen om een ontbrekende route te repareren.
Wat de bronvalidatie beslist
De kernel controleert of het bronadres van een pakket aannemelijk is voor de interface waarop het aankwam, door de routingtabel te raadplegen voor een route terug naar die bron. Wijst de terugroute ergens anders heen, dan kan het pakket worden weggegooid voordat een firewallregel of applicatiesocket het ziet. Die controle bestaat om bepaalde spoofingpatronen moeilijker te maken, en daarom lopen asymmetrische en policy-routed ontwerpen er tegenaan terwijl elke gewone client op hetzelfde netwerk prima werkt. Gewone clients hebben symmetrische routering, en dat is precies wat de controle veronderstelt.
Het belangrijke woord is aannemelijk. Het pakket kan volkomen legitiem zijn en toch de controle niet halen, omdat niet de legitimiteit wordt getest.
Lees de effectieve modus, niet één veld
Er bestaan drie modi: uitgeschakeld, strikt en los. Strikt legt een andere routeverwachting op dan los, en de globale instelling werkt samen met die per interface, dus het lezen van één bestand kan verkeerd beschrijven wat feitelijk geldt. Lees beide, en lees ze op de interface die het antwoord ontvangt, niet op die van de standaardroute.
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>De routeopzoeking in die derde regel is het deel dat mensen overslaan. Die vertelt u wat de kernel over de bron denkt, en dat is precies de invoer van de controle.
Vind de afwijking voordat u de controle wijzigt
Zoek uit waarom het antwoord op die interface aankomt en of de terugroute ervan anders hoort te zijn. Een policyregel die verzoeken via het ene pad verstuurt terwijl antwoorden via een ander terugkomen, is een legitiem ontwerp, en dat is ook het ontwerp dat strikte validatie weigert. Markeringen die in policy-routing worden gebruikt, kunnen hier ook van belang zijn, omdat ze veranderen wat de terugopzoeking oplevert.
Ontbreekt de terugroute simpelweg, dan lost het toevoegen ervan de oorzaak op in plaats van een controle uit te schakelen. Een ontbrekende route, een weigering door de firewall en een verkeerde verkeersselector geven alle hetzelfde zichtbare symptoom, en slechts één ervan gaat over bronvalidatie.
Schakel broncontroles niet als eerste reactie globaal uit. Dat ruilt een concrete diagnose in voor een brede gedragswijziging die u later moet onthouden.
Een selectieve aanpassing die u kunt verdedigen
Als een smalle aanpassing echt nodig is, beperk die dan tot de interface die hem nodig heeft, noteer waarom, en zet hem in de configuratie die die interface bezit, zodat hij een herstart overleeft. Test daarna precies de stroom die faalde opnieuw, van dezelfde bron naar dezelfde bestemming, in plaats van een ping naar iets handigs.
Neem een geval op dat nog steeds geweigerd zou moeten worden. Lukt dat geval nu, dan heeft de aanpassing meer verzwakt dan het ene pad dat u wilde repareren.
Houd IPv4 en IPv6 gescheiden
Een vertrouwd uitziende sysctl is geen beleid voor elke adresfamilie. IPv6 heeft zijn eigen gedrag en zijn eigen instellingen, en een machine kan streng zijn op de ene familie en toegeeflijk op de andere zonder dat iemand het merkt tot een specifieke bestemming faalt. Controleer beide als de werkbelasting beide gebruikt.
Leg de modus, de interface, de uitvoer van de routeopzoeking en de reden van de wijziging op één plek vast. De volgende persoon vindt de instelling en geen uitleg, en zal die verwijderen of kopiëren naar een plek waar hij niet hoort.