Lančano povezivanje dva OpenVPN klijenta na jednom Linux hostu s fwmark

Slaganje drugog OpenVPN klijenta na jedan Linux host pada na jednom od dva mjesta. Ili unutrašnji klijent ne može doći do svog servera jer je vanjski tunel preuzeo taj transport, ili drugi klijent prepiše tablicu ruta i prvi tunel prestane raditi. Oba problema su u rutiranju, ne u enkripciji, i oba se rješavaju prije nego novi tunel ponese bilo kakav aplikacijski promet. Adrese su ovdje ilustrativne: tun0 je vanjski tunel, 203.0.113.9 je unutrašnji server, a TCP 9999 je tok koji mora ići unutrašnjim putem.

Dva načina kvara, jedna tablica ruta

Unutrašnji klijent otvara UDP utičnicu prema svom serveru, a ta utičnica slijedi trenutnu tablicu ruta kao i svaka druga. Ako vanjski tunel već posjeduje zadanu rutu, paketi rukovanja odlaze u vanjski tunel. To radi samo kad vanjski server može doći do unutrašnjeg servera i druga strana pristane nositi tok; inače rukovanje stane i klijent ponovo pokušava.

Drugi kvar dolazi od serverovog pusha. Uobičajeni push je redirect-gateway def1, koji instalira 0.0.0.0/1 i 128.0.0.0/1 umjesto da zamijeni zadanu rutu. Zato se dva klijenta koja svaki instalira svoj /1 par sudaraju, a najnoviji par pobjeđuje za gotovo svako odredište. Tražite ta dva prefiksa u tablici kad tunel umre nakon spajanja drugog, jer se sama zadana ruta možda nikad nije promijenila.

Označite tok i dajte mu tablicu

Usmjerite odabrani promet tako što ćete ga označiti u tablici mangle i upariti oznaku u pravilu politike. Pravilo pokazuje na posvećenu tablicu čija je zadana ruta unutrašnji uređaj, pa samo označeni paketi idu unutrašnjim putem.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Većina kvarova u ovom skupu pravila dolazi od dvije greške. Vrijednost oznake koju postavlja firewall i vrijednost koju pravilo uparuje moraju biti identične, jer nesklad ne daje ni grešku ni učinak. A PREROUTING vidi samo pakete koji dolaze izvana, pa veza pokrenuta na ovom hostu treba OUTPUT pravilo s istim uparivanjem prije nego što uopće bude označena.

Oduzmite vlasništvo nad rutama drugom klijentu

Dvije opcije sprječavaju drugi klijent da uređuje tablicu i djeluju na različitim mjestima. route-nopull ignorira gurnute opcije ruta, pa se ništa ne instalira. route-noexec prihvaća gurnute opcije u okruženje klijenta, ali promjenu tablice prepušta hooku, što je upravo ono što želite kad trebate vidjeti šta je server ponudio.

Hook radi s gurnutim vrijednostima u svom okruženju i treba dodati samo unose koje ste odobrili. Učinite ga idempotentnim: ispraznite tablicu kojom upravlja prije ponovne izgradnje i ne pretpostavljajte da je prethodno pokretanje ostavilo čisto stanje. Ponovno spajanje ponovo poziva hook, a hook koji dodaje bez čišćenja nakuplja duplikate ruta.

Odaberite jednog vlasnika i zapišite ga. Profil koji postavlja obje opcije, ili hook koji se natječe s ručnom skriptom, stvara tablicu koju kasnije nitko ne može objasniti.

Prikvačite obje adrese servera

Unutrašnji server treba host rutu kroz vanjski uređaj prije nego se unutrašnji klijent spoji. Taj unos drži unutrašnji transport unutar vanjskog tunela umjesto da mu dopusti da slijedi zadanu rutu.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Dodajte i odgovarajuću host rutu za vanjski server u glavnu tablicu, inače ponovno spajanje može usmjeriti vlastiti transport vanjskog klijenta u njegov vlastiti tunel. Redoslijed nije izbor: dodajte te unose nakon što dotično sučelje postoji, što znači hook ili skripta koja se izvršava nakon spajanja. Ruta koja pokazuje na isključen uređaj uklanja se ili ignorira, pa unos napisan pri podizanju ne preživljava slijed koji ste pretpostavili.

Provjerite pretragu umjesto čitanja cijele tablice. Izlaz pretrage rute navodi uređaj i izvornu adresu koje će jezgro koristiti, a to je točno ono što klijent dobije kad otvori svoju utičnicu.

Testirajte lanac i učinite kvar vidljivim

Snimajte na vanjskom sučelju dok se unutrašnji klijent spaja. Unutrašnje rukovanje treba se pojaviti kao šifrirani teret unutar vanjskog tunela; ako se pojavi kao obični UDP prema 203.0.113.9, host ruta nedostaje i lanac nikad nije izgrađen.

Lanac koji tiho padne natrag na fizički uplink najgori je ishod, jer stanje sučelja ništa ne najavljuje i unutrašnji promet izlazi s pogrešne izvorne adrese. Ako se drugi klijent može izravno ponovo spojiti kad vanjski tunel padne, onemogućite taj put ili ga vežite na vanjsko sučelje da kvar bude vidljiv.

Završite s dva toka i jednim ispisom pravila: označena i neoznačena veza trebaju ići različitim putovima, a ip rule show treba navesti prioritet koji ste namjeravali. Ako oba toka idu istim putem, oznaka se ne primjenjuje tamo gdje mislite.