OpenVPN iroute teenoor kernroete: watter een ontbreek?
Die bediener het ’n roete en die verkeer stop steeds. Een padbesluit behoort aan die kernel, die ander aan die eweknie; leer watter een ontbreek en wat om na te gaan.
’n Pakket vir 10.77.20.0/24 neem twee afsonderlike besluite op ’n OpenVPN-bediener: die bedryfstelsel moet dit aan die VPN-koppelvlak oorhandig, en OpenVPN moet weet watter gekoppelde kliënt daardie voorvoegsel besit. ’n Ontbrekende kernroete laat dit voor die tonnel val, ’n ontbrekende eweknie-roete laat dit daarna val. Die twee foute lyk identies van die verre LAN af, en om te diagnoseer watter een jy het, neem een opdrag aan elke kant.
In die klassieke gebruikersruimte-datapad kry die kernroete die pakket in die tonnelproses, en iroute sê vir daardie proses watter eweknie dit moet ontvang. Nie een vervang die ander nie, en ’n konfigurasie met net een van hulle sal redelik lyk tot en met die eerste ping.
Twee besluite, nie een roete nie
Stel jou ’n werf-tot-werf-verbinding voor waar 10.77.20.0/24 agter ’n enkele kliënt sit. Die bediener se kernroete, byvoorbeeld ip route add 10.77.20.0/24 dev tun0, stuur ooreenstemmende pakkette na die tonneltoestel. OpenVPN raadpleeg dan sy eie interne tabel, opgebou uit iroute-inskrywings in die kliëntkonfigurasiegids, om te besluit watter eweknie-verbinding hulle ontvang. Sonder die kernroete bereik die pakket nooit die proses nie, en sonder die eweknie-roete bereik dit die proses en gaan nêrens heen nie.
Daardie verdeling is maklik om te vergeet, want ’n enkele roetelyn in ’n kliëntprofiel kan lyk of dit albei take doen. Dit doen nie: om ’n roete te stoot sê vir kliënte wat om deur die tonnel te stuur, terwyl iroute vir die bediener sê wie ’n adresreeks agter ’n kliënt besit. Hulle woon in verskillende lêers, word deur verskillende kante gelees, en faal in teenoorgestelde rigtings.
Waar iroute hoort en wat dit sê
Die inskrywing gaan in ’n per-kliënt-lêer wat na die kliënt se common_name vernoem is, onder client-config-dir, as iroute 10.77.20.0/24. Die lêernaam-ooreenkoms is nie kosmeties nie: OpenVPN soek die geauthentiseerde identiteit op en lees die lêer met presies daardie naam, dus ’n lêer genaamd site-a werk net vir ’n kliënt wie se common name site-a is. Voeg ccd-exclusive by as kliënte sonder so ’n lêer heeltemal geweier moet word, wat die regte instelling is wanneer elke kliënt ’n werfpoort is. Hou een lêer per poort en vernoem dit na die sertifikaat-subjek wat jy werklik uitgee.
Toets die inskrywing vanaf die bediener voordat jy die verre LAN blameer. Die statuslêer lys gekoppelde kliënte met hulle common names, en ’n bediener wat op --verb 4 loop, teken die iroute aan wat geïnstalleer word wanneer die eweknie koppel. As niks by verbindingstyd verskyn nie, is die lêer in die verkeerde gids of noem dit die verkeerde identiteit.
Die lokval: lêer teenwoordig, verkeerde identiteit
’n Korrek-voorkomende iroute wat aan die verkeerde eweknie gekoppel is, mors meer tyd as ’n ontbrekende lêer, want alles op skyf lyk reg. Sertifikaathernoeming, duplikaat common names en username-as-common-name wat die effektiewe identiteit verander, veroorsaak dit almal. Kontroleer watter identiteit die bediener geauthentiseer het eerder as watter een jy verwag het: die statusuittreksel is gesaghebbend, terwyl die lêernaam net ’n soeksleutel is.
’n Roete kan ook sy eienaar oorleef. Statiese roetes en iroute-inskrywings beskryf ’n voorvoegsel eerder as ’n beskikbaarheidsgarantie, so verkeer kan aanhou om na ’n eweknie gelei word wat tans ontkoppel is.
Voltooi die pad anderkant die eweknie
Eweknie-eienaarskap is die middel van die pad, nie die einde nie. Die kliënt moet pakkette van die tonnel na sy LAN aanstuur, wat beteken IP-aansturing moet op daardie gasheer geaktiveer wees en ’n firewall-reël moet die deurgang toelaat. Gashere op die verre LAN het ’n terugpad vir die tonneladres nodig, hetsy ’n roete wat terug na die poort wys of ’n doelbewuste NAT-ontwerp aan die kliëntkant. Bevestig die aanstuur-instelling op die kliënt met sysctl net.ipv4.ip_forward in plaas daarvan om ’n verspreidingsverstek te aanvaar.
As ander VPN-kliënte daardie subnet moet bereik, groei die reëling weer: die bediener het client-to-client nodig, en daardie kliënte moet die voorvoegsel deur die tonnel lei. Niks daarvan word deur die bediener se eie roetetabel geïmpliseer nie.
Verifieer een bestemming vanaf ’n werklike bron eerder as vanaf die bediener self. ’n Ping vanaf ’n onverwante LAN-gasheer na ’n gasheer agter die kliënt oefen die terugpad, die aanstuur-reël en die eweknie-eienaarskap in een beweging, terwyl ’n suksesvolle handdruk net identiteit bewys. Ontkoppel dan die eienaar-eweknie en teken op wat die roete doen, want daardie antwoord is jou foutmodus.