OpenVPN iroute kontra kernelrute: hvilken mangler?
Serveren har en rute, og trafikken stopper alligevel. Den ene beslutning om stien hører til kernen, den anden til peeren; find ud af, hvilken der mangler, og hvad du skal kontrollere.
En pakke til 10.77.20.0/24 træffer to separate beslutninger på en OpenVPN-server: styresystemet skal aflevere den til VPN-interfacet, og OpenVPN skal vide, hvilken tilsluttet klient der ejer det præfiks. En manglende kernelrute taber den før tunnelen, en manglende peerrute taber den bagefter. De to fejl ser identiske ud fra det fjerne LAN, og at diagnosticere, hvilken du har, kræver én kommando på hver side.
I den klassiske datasti i brugerrummet bringer kernelruten pakken ind i tunnelprocessen, og iroute fortæller den proces, hvilken peer der skal modtage den. Ingen af dem erstatter den anden, og en konfiguration med kun én af dem vil se rimelig ud lige indtil den første ping.
To beslutninger, ikke én rute
Forestil dig et site-til-site-link, hvor 10.77.20.0/24 ligger bag en enkelt klient. Serverens kernelrute, for eksempel ip route add 10.77.20.0/24 dev tun0, sender matchende pakker til tunnelemheden. Derefter slår OpenVPN op i sin egen interne tabel, bygget af iroute-poster i klientens konfigurationsmappe, for at afgøre, hvilken peerforbindelse der modtager dem. Uden kernelruten når pakken aldrig processen, og uden peerruten når den processen og går ingen steder.
Den opdeling er let at glemme, fordi én ruttelinje i en klientprofil kan se ud som om den klarer begge opgaver. Det gør den ikke: at skubbe en rute fortæller klienterne, hvad de skal sende gennem tunnelen, mens iroute fortæller serveren, hvem der ejer et adresseområde bag en klient. De bor i forskellige filer, læses af forskellige sider og fejler i modsatte retninger.
Hvor iroute hører til, og hvad den siger
Posten hører i en fil for hver klient opkaldt efter klientens common_name, under client-config-dir, som iroute 10.77.20.0/24. Filnavnssammenfaldet er ikke kosmetisk: OpenVPN slår den godkendte identitet op og læser filen med præcis det navn, så en fil med navnet site-a virker kun for en klient, hvis fælles navn er site-a. Tilføj ccd-exclusive, hvis klienter uden en sådan fil skal afvises helt, hvilket er den rigtige indstilling, når hver klient er en sitegateway. Hold én fil for hver gateway, og navngiv den efter det certifikatssubjekt, du faktisk udsteder.
Test posten fra serveren, før du bebrejder det fjerne LAN. Statusfilen viser tilsluttede klienter med deres fælles navne, og en server, der kører med --verb 4, logger installationen af iroute, når peeren opretter forbindelse. Hvis der ikke dukker noget op ved forbindelsen, ligger filen i den forkerte mappe eller angiver den forkerte identitet.
Fælden: filen findes, identiteten er forkert
En iroute, der ser rigtig ud, men er knyttet til den forkerte peer, spilder mere tid end en manglende fil, fordi alt på disken ser korrekt ud. Omdøbning af certifikater, dubletter af fælles navne og username-as-common-name, der ændrer den effektive identitet, frembringer det alle. Kontrollér, hvilken identitet serveren godkendte, i stedet for hvilken du forventede: statusoutputtet er autoritativt, mens filnavnet kun er en opslagsnøgle.
En rute kan også overleve sin ejer. Statiske ruter og iroute-poster beskriver et præfiks, ikke en tilgængelighedsgaranti, så trafik kan fortsat blive rutet mod en peer, der i øjeblikket er afbrudt.
Færdiggør stien ud over peeren
Peer-ejerskab er midten af stien, ikke enden. Klienten skal videresende pakker fra tunnelen til sit LAN, hvilket betyder, at IP-videresendelse er slået til på den vært, og at en firewallregel tillader gennemløbet. Værter på det fjerne LAN har brug for en retursti til tunneladressen, enten en rute, der peger tilbage mod gatewayen, eller et bevidst NAT-design på klientsiden. Bekræft videresendelsesindstillingen på klienten med sysctl net.ipv4.ip_forward i stedet for at antage en distributionsstandard.
Hvis andre VPN-klienter skal nå det undernet, vokser arrangementet igen: serveren skal bruge client-to-client, og de klienter skal rute præfikset gennem tunnelen. Intet af det følger af serverens egen rutetabel.
Bekræft én destination fra en rigtig kilde i stedet for fra serveren selv. En ping fra en uvedkommende LAN-vært til en vært bag klienten afprøver returstien, videresendelsesreglen og peer-ejerskabet i én bevægelse, hvorimod et vellykket handshake kun beviser identitet. Afbryd derefter den ejende peer, og notér, hvad ruten gør, fordi det svar er din fejltilstand.