OpenVPN iroute versus kerneli marsruut: kumb puudub?
Serveril on marsruut ja liiklus seisab ikkagi. Üks teeotsus kuulub kernelile, teine partnerile; saage teada, kumb puudub ja mida kontrollida.
Pakett sihtkohale 10.77.20.0/24 teeb OpenVPN-serveris kaks eraldi otsust: operatsioonisüsteem peab selle edastama VPN-liidesele ja OpenVPN peab teadma, milline ühendatud klient seda prefiksit omab. Puuduv kerneli marsruut viskab selle enne tunnelit välja, puuduv partneri marsruut pärast seda. Mõlemad tõrked näevad kaugest LAN-ist ühesugused välja ja diagnoosimine, kumb neist teil on, nõuab mõlemal pool üht käsku.
Klassikalises kasutajaruumi andmeteel kulgeb kerneli marsruut paketi tunneliprotsessi ja iroute ütleb sellele protsessile, milline partner peaks selle vastu võtma. Kumbki ei asenda teist ja ainult ühte neist sisaldav konfiguratsioon näeb mõistlik välja kuni esimese pingini.
Kaks otsust, mitte üks marsruut
Kujutage ette saidi-saiti ühendust, kus 10.77.20.0/24 asub ühe kliendi taga. Serveri kerneli marsruut, näiteks ip route add 10.77.20.0/24 dev tun0, saadab sobivad paketid tunneliseadmele. Seejärel vaatab OpenVPN oma sisemisse tabelisse, mis on koostatud kliendi konfiguratsioonikataloogis olevatest iroute kirjetest, et otsustada, milline partneri ühendus need vastu võtab. Ilma kerneli marsruudita ei jõua pakett kunagi protsessi ja ilma partneri marsruudita jõuab see protsessi ning ei lähe kuhugi.
Seda jaotust on lihtne unustada, sest üks marsruudirida kliendiprofiilis võib tunduda tegevat mõlemat tööd. Ei tee: marsruudi lükkamine ütleb klientidele, mida tunnelist saata, samas kui iroute ütleb serverile, kellele kuulub kliendi taga olev aadressivahemik. Need elavad eri failides, neid loevad eri pooled ja need ebaõnnestuvad vastassuundades.
Kuhu iroute kuulub ja mida see ütleb
Kirje läheb kliendi common_name järgi nimetatud üksikukliendi faili, client-config-dir all, kujul iroute 10.77.20.0/24. Failinime sobivus ei ole kosmeetiline: OpenVPN otsib autenditud identiteedi ja loeb faili täpselt selle nimega, seega fail nimega site-a mõjub ainult kliendile, mille üldnimi on site-a. Lisage ccd-exclusive, kui ilma sellise failita kliendid tuleb kohe tagasi lükata, mis on õige seade, kui iga klient on saidi värav. Hoidke üks fail värava kohta ja nimetage see sertifikaadi subjekti järgi, mille te tegelikult väljastate.
Testige kirjet serverist enne kaug-LAN-i süüdistamist. Staatusefail loetleb ühendatud kliendid nende üldnimedega ja --verb 4-ga töötav server logib iroute paigaldamise hetkel, mil partner ühendub. Kui ühendumise ajal midagi ei ilmu, on fail vales kataloogis või nimetab vale identiteedi.
Lõks: fail on olemas, identiteet vale
Õigesti näiv, kuid vale partneri külge kinnitatud iroute raiskab rohkem aega kui puuduv fail, sest kõik kettal näeb õige välja. Sertifikaatide ümbernimetamine, dubleerivad üldnimed ja efektiivset identiteeti muutev username-as-common-name tekitavad selle kõik. Kontrollige, millise identiteedi server autentis, mitte millist te ootasite: staatuse väljund on autoriteetne, failinimi on vaid otsinguvõti.
Marsruut võib oma omanikust kauem kesta. Staatilised marsruudid ja iroute kirjed kirjeldavad prefiksit, mitte kättesaadavuse garantiid, seega võib liiklus jätkata suunamist partneri poole, kes on praegu lahti ühendatud.
Lõpetage tee partnerist kaugemal
Partneri omandiõigus on tee keskpaik, mitte lõpp. Klient peab tunnelist pakette oma LAN-i edasi saatma, mis tähendab, et sellel hostil on IP-edastus lubatud ja tulemüürireegel lubab läbipääsu. Kaug-LAN-i hostid vajavad tunneli aadressi jaoks tagasiteed: kas värava poole tagasi osutavat marsruuti või kliendi poolel teadlikult kavandatud NAT-i. Kinnitage edastusseade kliendil käsuga sysctl net.ipv4.ip_forward, selle asemel et eeldada distributsiooni vaikeväärtust.
Kui teised VPN-kliendid peavad sellesse alamvõrku jõudma, kasvab lahendus taas: server vajab client-to-client seadet ja need kliendid peavad prefiksi tunnelist läbi marsruutima. Miski sellest ei tulene serveri enda marsruutimistabelist.
Kontrollige ühte sihtkohta päris allikast, mitte serverist endast. Ping kõrvaliselt LAN-hostilt kliendi taga olevale hostile harjutab tagasiteed, edastusreeglit ja partneri omandiõigust ühe liigutusega, samas kui edukas handshake tõestab ainult identiteeti. Seejärel ühendage omanikpartner lahti ja kirjutage üles, mida marsruut teeb, sest see vastus on teie tõrkerežiim.