OpenVPN-klienten stopper når tjeneren kjører på samme vert

Jeg hadde en laboratoriemaskin som tok imot en tunnel fra et eksternt sted og også ringte ut til et leverandørnettverk. Den utgående profilen hadde fungert i ukevis. Etter at den innkommende tjeneren ble lagt til, koblet den utgående til og sluttet deretter å sende trafikk innen få sekunder, eller nektet å starte med en feil om at adressen allerede er i bruk. Konfigurasjonsfilene var ikke endret; verten hadde ganske enkelt fått en ny OpenVPN-prosess med sin egen mening om porter og ruter.

Feilen er ikke tilfeldig, og det er ikke et autentiseringsproblem. To daemoner på én maskin konkurrerer om samme lokale socket og samme rutetabell, og den som starter eller kobler til på nytt sist, vinner vanligvis. Å vite hvilken av disse to kollisjonene du har avgjør hvor du skal se først.

Les symptomet baklengs

Begynn med når tunnelen dør. En bind-feil ved oppstart peker mot lyttesiden: noe eier allerede den porten, og OpenVPN nekter å starte i stedet for å dele den. En tunnel som kommer opp og deretter blir stille, peker mot ruting, fordi en rute installert av den andre forekomsten kan trekke pakkene til den ytre forbindelsen bort fra veien sin.

Begge tilfellene gir samme brukerklage, og derfor løser gjenforsøksløkker og watchdog-skript ingenting. De kobler klienten tilbake i samme konflikt. Det nyttige første spørsmålet er om prosessen fortsatt kjører når trafikken stopper.

Én socket og én enhet per forekomst

En lyttende tjener binder porten sin; en utgående klient trenger også en lokal port for sin innkapslede trafikk. Når begge bor på samme vert, kan klientens standardoppførsel kollidere med tjenerens port. Klientens lokale port kan festes, og binding kan hoppes over der motparten ikke trenger en fast kildeport:

lport 1195
nobind
dev tun1

Disse tallene er eksempler, ikke et krav. Det som betyr noe, er at klienten slutter å konkurrere om tjenerens port, og at hver forekomst får en egen tunnelenhet. To daemoner som deler tun0, overskriver hverandres enhetstilstand selv når portene deres er forskjellige, så én enhet per tunnel er ikke valgfritt.

nobind hører til klientsiden. En tjener må fortsatt binde og lytte, så ikke kopier linjen inn i tjenerkonfigurasjonen, og ikke deaktiver binding på en klient der motparten filtrerer på en fast kildeport.

Velg én eier for standardruten

Bare én forbindelse kan installere en standardrute. Hvis begge profilene omdirigerer all trafikk, erstatter den andre forbindelsen stilltiende den første, og den første ser ut til å brytes. Enten holder du den utgående tunnelen delt og dytter bare leverandørprefiksene, eller du gir den en egen 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 ovenfor er plassholdere. Bekreft umiddelbart etter at regelen er lagt til at VPN-tjenerens egen adresse fortsatt løses gjennom den vanlige tabellen; en tabell som fanger den ytre transporten, ødelegger tunnelen den skulle beskytte, og gjenoppkoblingsløkken som følger, ser ut som en upålitelig leverandør.

For et oppsett som må overleve gjenoppkoblinger og omstarter, er et nettverksnavnerom den mer solide grensen. Den andre klienten kjører inne i sitt eget navnerom med egne grensesnitt og ruter, og bare tjenestene som må krysse, eksponeres. Verten beholder én standardrute, og en navneromsgjenoppkobling kan ikke skrive den om.

Verifiser med tabellen, ikke statuslinjen

En klient som rapporterer at den er tilkoblet, beviser bare kontrollkanalen sin. Ta opp rutingtilstanden før og etter hver tilkobling, og spør deretter kjernen hvilken enhet en reell destinasjon ville brukt:

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

Hvis den valgte enheten for leverandøradressen endres når den andre tunnelen starter, har du rutekollisjonen. Hvis begge prosessene dukker opp på samme lokale port, har du socketkollisjonen. Å fikse den første uten den andre flytter bare feilen til neste gjenoppkobling.

Skriv portene, enhetene, tabellene og ruteeieren inn i vertens runbook. Ellers vil neste person som legger til en tredje tunnel gjenoppdage samme kollisjon, og det eneste synlige beviset vil være en forbindelse som fungerer til noen andres daemon starter på nytt.