OpenVPN-klienten stoppar når tenaren køyrer på same vert

Eg hadde ein laboratoriemaskin som tok imot ein tunnel frå ein ekstern stad og òg ringde ut til eit leverandørnettverk. Den utgåande profilen hadde fungert i veker. Etter at den inngåande tenaren vart lagd til, kopla den utgåande til og slutta deretter å senda trafikk innan få sekund, eller nekta å starta med ein feil om at adressa allereie er i bruk. Konfigurasjonsfilene var ikkje endra; verten hadde ganske enkelt fått ein ny OpenVPN-prosess med si eiga meining om portar og ruter.

Feilen er ikkje tilfeldig, og det er ikkje eit autentiseringsproblem. To daemonar på éin maskin konkurrerer om same lokale socket og same rutetabell, og den som startar eller koplar til på nytt sist, vinn vanlegvis. Å vita kva av desse to kollisjonane du har avgjer kvar du skal sjå først.

Les symptomet baklengs

Byrja med når tunnelen døyr. Ein bind-feil ved oppstart peikar mot lyttesida: noko eig allereie den porten, og OpenVPN nektar å starta i staden for å dela han. Ein tunnel som kjem opp og deretter blir stille, peikar mot ruting, fordi ei rute installert av den andre førekomsten kan trekka pakkane til den ytre sambandet bort frå vegen sin.

Begge tilfella gir same brukarklage, og difor løyser gjenforskøksløkker og watchdog-skript ingenting. Dei koplar klienten tilbake i same konflikt. Det nyttige første spørsmålet er om prosessen framleis køyrer når trafikken stoppar.

Éin socket og éi eining per førekomst

Ein lyttande tenar bind porten sin; ein utgåande klient treng òg ein lokal port for den innkapsla trafikken sin. Når begge bur på same vert, kan standardoppførselen til klienten kollidera med porten til tenaren. Den lokale porten til klienten kan festast, og binding kan hoppast over der motparten ikkje treng ein fast kjeldeport:

lport 1195
nobind
dev tun1

Desse tala er døme, ikkje eit krav. Det som tel, er at klienten sluttar å konkurrera om porten til tenaren, og at kvar førekomst får ei eiga tunneleining. To daemonar som deler tun0, overskriv kvarandre sin einingsstatus sjølv når portane deira er ulike, så éi eining per tunnel er ikkje valfri.

nobind høyrer til klientsida. Ein tenar må framleis binda og lytta, så ikkje kopier linja inn i tenarkonfigurasjonen, og ikkje deaktiver binding på ein klient der motparten filtrerer på ein fast kjeldeport.

Vel éin eigar for standardruta

Berre éin samband kan installera ei standardrute. Viss begge profilane omdirigerer all trafikk, erstattar det andre sambandet stilltiande det første, og det første ser ut til å brytast. Anten held du den utgåande tunnelen delt og dyttar berre leverandørprefiksa, eller du gir han ein eigen rutetabell.

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

Adressene og tabellnummeret ovanfor er plasshaldarar. Stadfest umiddelbart etter at regelen er lagd til at adressa til VPN-tenaren sjølv framleis blir løyst gjennom den vanlege tabellen; ein tabell som fangar den ytre transporten, øydelegg tunnelen han skulle verna, og gjenoppkoplingsløkka som følgjer, ser ut som ein upåliteleg leverandør.

For eit oppsett som må overleva gjenoppkoplingar og omstart, er eit nettverksnamnerom den meir solide grensa. Den andre klienten køyrer inne i sitt eige namnerom med eigne grensesnitt og ruter, og berre tenestene som må krysse, blir eksponerte. Verten held éi standardrute, og ei namneromsgjenoppkopling kan ikkje skriva henne om.

Verifiser med tabellen, ikkje statuslinja

Ein klient som rapporterer at han er tilkopla, beviser berre kontrollkanalen sin. Ta opp rutingtilstanden før og etter kvar tilkopling, og spør deretter kjernen kva eining ein reell destinasjon ville brukt:

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

Viss den valde eininga for leverandøradressa endrar seg når den andre tunnelen startar, har du rutekollisjonen. Viss begge prosessane dukkar opp på same lokale port, har du socketkollisjonen. Å fiksa den første utan den andre flyttar berre feilen til neste gjenoppkopling.

Skriv portane, einingane, tabellane og ruteeigaren inn i runbooken til verten. Elles vil neste person som legg til ein tredje tunnel gjenoppdaga same kollisjon, og det einaste synlege beviset vil vera ein samband som fungerer til nokon andre sin daemon startar på nytt.