OpenVPN-klient jää seisma, kui selle server töötab samas hostis

Mul oli laborimasin, mis võttis vastu tunnelit kaugemast saidilt ja helistas välja ka tarnija võrku. Väljuv profiil oli töötanud nädalaid. Pärast sissetuleva serveri lisamist ühendus väljuv ja lakkas siis mõne sekundi jooksul liiklust edastamast või keeldus käivitumast veaga, et aadress on juba kasutusel. Konfiguratsioonifailid ei olnud muutunud; host oli lihtsalt saanud teise OpenVPN-i protsessi, millel oli oma arvamus portide ja marsruutide kohta.

Tõrge ei ole juhuslik ja see ei ole autentimisprobleem. Kaks deemonit ühes masinas võistlevad sama kohaliku sokli ja sama marsruutimistabeli pärast ning see, kes käivitub või ühendub uuesti viimasena, tavaliselt võidab. Teadmine, kumb neist kahest kokkupõrkest teil on, otsustab, kuhu kõigepealt vaadata.

Lugege sümptomit tagurpidi

Alustage sellest, millal tunnel sureb. Sidumisviga käivitamisel osutab kuulamispoolsele: miski juba omab seda porti ja OpenVPN keeldub käivitumast, selle asemel et seda jagada. Tunnel, mis tõuseb ja siis vaikib, osutab marsruutimisele, sest teise eksemplari paigaldatud marsruut võib välisühenduse paketid nende teelt välja tõmmata.

Mõlemad juhtumid tekitavad sama kasutajakaebuse, mistõttu korduskatse tsüklid ja valve-skriptid ei paranda midagi. Need ühendavad kliendi uuesti samasse konflikti. Kasulik esimene küsimus on, kas protsess töötab veel siis, kui liiklus peatub.

Üks sokk ja üks seade eksemplari kohta

Kuulav server seob oma pordi; väljuval kliendil on samuti vaja kohalikku porti oma kapseldatud liikluse jaoks. Kui mõlemad elavad samas hostis, võib kliendi vaikekäitumine põrkuda serveri porti. Kliendi kohaliku pordi saab kinnitada ja sidumise võib vahele jätta seal, kus vastaspool ei vaja fikseeritud lähteporti:

lport 1195
nobind
dev tun1

Need numbrid on näited, mitte nõue. Tähtis on, et klient lakkab serveri pordi pärast võistlema ja iga eksemplar saab eraldi tunneliseadme. Kaks deemonit, mis jagavad tun0, kirjutavad üksteise seadmeoleku üle ka siis, kui nende pordid erinevad, seega üks seade tunneli kohta ei ole valikuline.

nobind kuulub kliendipoolele. Server peab endiselt siduma ja kuulama, seega ärge kopeerige rida serveri konfiguratsiooni ega lülitage sidumist välja kliendil, mille vastaspool filtreerib fikseeritud lähteporti.

Valige vaikimisi marsruudile üks omanik

Vaikimisi marsruuti saab paigaldada ainult üks ühendus. Kui mõlemad profiilid suunavad ümber kogu liikluse, asendab teine ühendus vaikselt esimese ja esimene näib katkivat. Kas hoidke väljuv tunnel jaotatuna ja lükake ainult tarnija prefiksid, või andke sellele eraldi marsruutimistabel.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Ülaltoodud aadressid ja tabelinumber on kohatäited. Vahetult pärast reegli lisamist kinnitage, et VPN-serveri enda aadress laheneb endiselt tavalise tabeli kaudu; tabel, mis püüab kinni välise transpordi, rikub tunneli, mida see pidi kaitsma, ja järgnev taasühendamise tsükkel näeb välja nagu ebausaldusväärne teenusepakkuja.

Seadistuse jaoks, mis peab üle elama taasühendused ja taaskäivitused, on võrgu nimeruum tugevam piir. Teine klient töötab oma nimeruumis oma liideste ja marsruutidega ning paljastatakse ainult teenused, mis peavad piiri ületama. Host hoiab ühte vaikimisi marsruuti ja nimeruumi taasühendamine ei saa seda ümber kirjutada.

Kontrollige tabeliga, mitte olekuriga

Klient, kes teatab, et on ühendatud, tõestab ainult oma juhtkanalit. Salvestage marsruutimise olek enne ja pärast iga ühendust, seejärel küsige tuumalt, millist seadet kasutaks tegelik sihtkoht:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Kui tarnija aadressi jaoks valitud seade muutub teise tunneli käivitumisel, on teil marsruudikokkupõrge. Kui mõlemad protsessid ilmuvad samale kohalikule pordile, on teil soklikokkupõrge. Esimese parandamine ilma teiseta liigutab tõrke lihtsalt järgmisele taasühendamisele.

Kirjutage pordid, seadmed, tabelid ja marsruudi omanik hosti runbooki. Vastasel juhul avastab järgmine inimene, kes lisab kolmanda tunneli, sama kokkupõrke uuesti, ja ainus nähtav tõend on ühendus, mis töötab seni, kuni kellegi teise deemon taaskäivitub.