OpenVPN iroute eller kjernerute: kva manglar?
Tenaren har ei rute, og trafikken stoppar likevel. Den eine vegvalet høyrer til kjernen, det andre til peer-en; finn ut kva som manglar, og kva du skal kontrollere.
Ein pakke til 10.77.20.0/24 tek to separate avgjerder på ein OpenVPN-tenar: operativsystemet må levere han til VPN-grensesnittet, og OpenVPN må vite kva tilkopla klient som eig det prefikset. Ei manglande kjernerute slepp han før tunnelen, ei manglande peerrute slepp han etterpå. Dei to feila ser identiske ut frå det fjerne LAN-et, og å diagnostisere kva du har krev éin kommando på kvar side.
I den klassiske datastien i brukarrommet bringar kjerneruta pakken inn i tunnelprosessen, og iroute fortel den prosessen kva peer som skal ta imot han. Ingen av dei erstattar den andre, og ein konfigurasjon med berre éin av dei vil sjå rimeleg ut heilt til den første ping-en.
To avgjerder, ikkje éi rute
Sjå føre deg ei samband mellom to stader der 10.77.20.0/24 ligg bak éin einaste klient. Kjerneruta til tenaren, til dømes ip route add 10.77.20.0/24 dev tun0, sender samsvarande pakkar til tunneleininga. Deretter slår OpenVPN opp i si eiga interne tabell, bygd av iroute-oppføringar i konfigurasjonskatalogen til klienten, for å avgjere kva peer-samband som tek imot dei. Utan kjerneruta når pakken aldri prosessen, og utan peerruta når han prosessen og kjem ingen veg.
Den todelinga er lett å gløyme, fordi éi ruttelinje i ein klientprofil kan sjå ut som ho gjer begge jobbane. Det gjer ho ikkje: å dytte ei rute fortel klientane kva dei skal sende gjennom tunnelen, medan iroute fortel tenaren kven som eig eit adresseområde bak ein klient. Dei bur i ulike filer, blir lesne av ulike sider og feilar i motsette retningar.
Kvar iroute høyrer heime, og kva ho seier
Oppføringa høyrer i ei fil per klient oppkalla etter common_name til klienten, under client-config-dir, som iroute 10.77.20.0/24. Filnamnssamsvaret er ikkje kosmetisk: OpenVPN slår opp den autentiserte identiteten og les fila med nøyaktig det namnet, så ei fil som heiter site-a verkar berre for ein klient der fellesnamnet er site-a. Legg til ccd-exclusive om klientar utan ei slik fil skal avvisast heilt, som er rett innstilling når kvar klient er ein stadsporth. Hald éi fil per porth, og namnset ho etter sertifikatsubjektet du faktisk gjev ut.
Test oppføringa frå tenaren før du klandrar det fjerne LAN-et. Statusfila listar tilkopla klientar med fellesnamna deira, og ein tenar som køyrer med --verb 4, loggar installasjonen av iroute når peer-en koplar til. Om ingenting dukkar opp ved tilkopling, ligg fila i feil katalog eller nemner feil identitet.
Fella: fila finst, identiteten er feil
Ein iroute som ser rett ut, men er knytt til feil peer, kostar meir tid enn ei manglande fil, fordi alt på disken ser rett ut. Omdøyving av sertifikat, dupliserte fellesnamn og username-as-common-name som endrar den effektive identiteten lagar det alle. Kontroller kva identitet tenaren autentiserte, i staden for kva du venta: statusutdata er autoritative, medan filnamnet berre er ein oppslagsnøkkel.
Ei rute kan òg overleve eigaren sin. Statiske ruter og iroute-oppføringar skildrar eit prefiks, ikkje ein garanti for tilgjenge, så trafikk kan halde fram med å bli ruta mot ein peer som er fråkobla akkurat no.
Fullfør stien forbi peer-en
Peer-eigarskap er midten av stien, ikkje slutten. Klienten må vidaresende pakkar frå tunnelen til sitt eige LAN, noko som tyder at IP-vidaresending er slått på på den verten og ein brannmurregel tillèt gjennomgangen. Vertar i det fjerne LAN-et treng ei returveg for tunneladressa: anten ei rute som peikar tilbake mot porten, eller eit medvite NAT-design på klientsida. Stadfest vidaresendingsinnstillinga på klienten med sysctl net.ipv4.ip_forward i staden for å gå ut frå ein distribusjonsstandard.
Om andre VPN-klientar skal nå det undernettet, veks oppsettet igjen: tenaren treng client-to-client, og dei klientane må rute prefikset gjennom tunnelen. Ingenting av det følgjer av tenaren sin eigen rutetabell.
Stadfest éin destinasjon frå ei ekte kjelde i staden for frå tenaren sjølv. Ein ping frå ein uvedkomande LAN-vert til ein vert bak klienten prøver returvegen, vidaresendingsregelen og peer-eigarskapet i éi rørsle, medan eit vellukka handtrykk berre provar identitet. Kople deretter frå den eigande peer-en og noter kva ruta gjer, fordi det svaret er feilmodusen din.