Povežite dva OpenVPN klijenta na jednom Linux hostu s fwmark

Složiti drugi OpenVPN klijent na jednom Linux hostu pada na jednom od dva mjesta. Ili unutarnji klijent ne može doći do vlastitog poslužitelja jer je vanjski tunel zauzeo taj promet, ili drugi klijent prepisuje tablicu ruta i prvi tunel prestaje raditi. Oba problema su u usmjeravanju, ne u enkripciji, i oba se rješavaju prije nego novi tunel prenese ikakav aplikacijski promet. Adrese su ovdje ilustrativne: tun0 je vanjski tunel, 203.0.113.9 je unutarnji poslužitelj, a TCP 9999 je tok koji mora koristiti unutarnju putanju.

Dva načina kvara, jedna tablica ruta

Unutarnji klijent otvara UDP utičnicu prema svom poslužitelju, a ta utičnica slijedi trenutačnu tablicu ruta kao i svaka druga. Ako vanjski tunel već drži zadanu rutu, handshake paketi odlaze u vanjski tunel. To radi samo kad vanjski poslužitelj može doći do unutarnjeg i druga strana pristaje prenijeti tok; inače handshake stane i klijent pokušava ponovno.

Drugi kvar dolazi od push poruke poslužitelja. Uobičajeni push je redirect-gateway def1, koji postavlja 0.0.0.0/1 i 128.0.0.0/1 umjesto zamjene zadane rute. Dva klijenta koja svaki postave svoj par /1 zato se sudaraju, a najnoviji par pobjeđuje za gotovo svako odredište. Tražite ta dva prefiksa u tablici kad tunel umre nakon što se drugi spojio, jer zadana ruta sama možda nikada nije promijenjena.

Označite tok i dajte mu tablicu

Usmjerite odabrani promet označavanjem u mangle tablici i podudaranjem oznake u pravilu politike. Pravilo pokazuje na namjensku tablicu čija je zadana ruta unutarnji uređaj, pa samo označeni paketi idu unutarnjom putanjom.

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 pogreške. Vrijednost oznake koju postavlja vatrozid i vrijednost koju pravilo podudara moraju biti identične, jer nesklad ne daje ni grešku ni učinak. I PREROUTING vidi samo pakete koji dolaze izvana, pa veza pokrenuta na ovom hostu treba OUTPUT pravilo s istim podudaranjem 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 postavlja. route-noexec prihvaća gurnute opcije u okruženje klijenta, ali promjenu tablice prepušta hooku, što je ono što želite kad trebate vidjeti što je poslužitelj ponudio.

Hook se izvodi s gurnutim vrijednostima u svom okruženju i trebao bi dodati samo unose koje ste odobrili. Učinite ga idempotentnim: ispraznite tablicu koju posjeduje prije ponovne izgradnje i ne pretpostavljajte da je prethodno pokretanje ostavilo čisto stanje. Ponovno spajanje ponovno 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 nitko kasnije ne može objasniti.

Prikvačite obje adrese poslužitelja

Unutarnji poslužitelj treba host rutu kroz vanjski uređaj prije nego se unutarnji klijent spoji. Taj unos drži unutarnji promet 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 odgovarajuću host rutu i za vanjski poslužitelj u glavnu tablicu, inače ponovno spajanje može usmjeriti promet samog vanjskog klijenta u njegov vlastiti tunel. Redoslijed nije neobavezan: dodajte te unose nakon što relevantno sučelje postoji, što znači hook ili skripta koja se izvodi nakon spajanja. Ruta prema uređaju koji je isključen uklanja se ili zanemaruje, pa unos zapisan pri podizanju sustava ne preživljava slijed koji ste pretpostavili.

Provjerite pretraživanje umjesto čitanja cijele tablice. Izlaz pretraživanja rute navodi uređaj i izvornu adresu koje će kernel koristiti, a to je upravo ono što klijent dobiva kad otvori svoju utičnicu.

Testirajte lanac i učinite kvar vidljivim

Snimajte na vanjskom sučelju dok se unutarnji klijent spaja. Unutarnji handshake trebao bi 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 unutarnji promet izlazi s pogrešne izvorne adrese. Ako se drugi klijent može izravno ponovno spojiti kad vanjski tunel padne, onemogućite tu putanju ili je 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 trebale bi ići različitim putanjama, a ip rule show trebao bi navesti prioritet koji ste namjeravali. Ako oba toka idu istom putanjom, oznaka se ne primjenjuje ondje gdje mislite.