OpenVPN server ja klient ühel hostil: miks kliendid välja kukuvad
Host, mis pakub OpenVPN-i ja kasutab seda ise, võib hoida tunnelit püsti, samal ajal kui kohalikud kliendid kaotavad vastused. Seda seletavad kaks asja: jagatud aadressibassein ja uus vaikimisi marsruut.
Lisage kliendiprofiil masinale, kus VPN-server juba töötab, ja esimene ohver on senine teenus. Uus tunnel ei pruugi kunagi tekkida või tõuseb see üles, samal ajal kui serveri olemasolevad kliendid lakkavad vaikselt vastuseid saamast. Kaks kokkupõrget annavad mõlemad tulemused: tunnelibassein, mis on juba kasutusel, ja uue kliendipoole paigaldatud vaikimisi marsruut, mis katab kogu tabeli. Kumbki ei tekita OpenVPN-i veateadet, ja seetõttu loetakse riket serveri probleemiks.
Üks masin, kaks rolli ja kaks ühildamatut vastust selle kohta, kuhu vastused peaksid minema.
Sama bassein, kaks serverit: kes võidab
Iga serveri eksemplar vajab oma tunnelialavõrku. Rea nagu server 10.8.0.0 255.255.255.0 kopeerimine teise konfiguratsiooni annab kahele eksemplarile sama prefiksi ja tulemuseks on kas keeldumine käivituda või vaikne võistlus, kus ühe serveri kliendid saavad aadresse, mida teine peab samuti omaks. Erinevad UDP-pordid ja erinevad seadmenimed ei aita, sest kumbki ei puuduta aadressiruumi. Muutke teist basseini ja muutke seda kõikjal, kus marsruudid seda mainivad.
Loetlege enne muutmist, mis on aktiivne: ip -4 addr show loetleb tunneliseadmed, ss -lunp loetleb kuulajad ja systemctl list-units nimetab üksused. Üks pilk tunneliaadressidele otsustab, kas basseinid põrkuvad.
Mida kliendiprofiil tabelisse lisab
Kliendipool kirjutab marsruudid kohe, kui see ühendub. redirect-gateway def1 jagab vaikimisi marsruudi 0.0.0.0/1 pluss 128.0.0.0/1-ks, mõlemad suunatakse läbi uue seadme, koos hostimarsruudiga kaugserverini, mis on meelega kinnitatud füüsilise liidese külge. See kinnitus on selleks, et tunnel hoiaks omaenda transpordi jaoks tee. Kõik muu, sealhulgas vastused, mille kohalik server oma klientidele võlgneb, järgib nüüd uut vaikimisi marsruuti ja väljub kauglingi kaudu.
Seega teine kokkupõrge ei ole katkine tunnel. See on töötav tunnel tabelis vales kohas.
Kolm viisi rollide lahus hoidmiseks
Kõige vähem sekkuv parandus hoiab vaikimisi marsruudi kliendiprofiilist väljas: route-nopull pluss selgesõnalised route read kaugprefiksite jaoks, nii et kohalik tabel muutub ainult seal, kus te seda palusite. Järgmine samm on poliitikareegel, mis vabastab kohaliku tunnelialavõrgu, lastes kohalikele klientidele mõeldud vastustel väljuda liideselt, kuhu need saabusid, ka siis, kui vaikimisi marsruut on olemas. Kõige põhjalikum on kliendirooli jaoks eraldi võrgu nimeruum, mis eemaldab jagatud tabeli täielikult ja nõuab teist marsruutimiskonteksti, mida hooldada.
Ükskõik millise tee valite, erand peab nimetama kohalikku tunnelialavõrku, mitte LAN-i. Vastusel, mille kohalik server saadab, on sihtkohaks tunneliaadress, seega LAN-kujuline erand ei sobi sellega kunagi.
Kumb kahest eksemplarist on süüdi
Peatage kliendieksemplar ja testige uuesti algseid kliente. Kohene taastumine tähendab marsruutimist, mitte serverit. Tooge klient tagasi ja jälgige üht vastust ip route get abil, millele on antud nii lähte- kui sihtaadress, mis näitab teed, mille kernel valiks, seejärel vaadake liidest, mida paketid tegelikult kasutavad, tcpdump -ni any port 1194 abil. Serveri olekufail, mida kirjutatakse iga paari sekundi järel direktiivi status kaudu, sisaldab ühendatud klientide loendit ja baidiloendureid mõlemas suunas.
Lugege neid loendureid üksteise vastu. Liiklus, mis väljub ega tule kunagi tagasi, on marsruutimise vastus, mitte käepigistuse probleem.