Ikaugnay ang dalawang OpenVPN client sa isang Linux host gamit ang fwmark

Ang paglalagay ng pangalawang OpenVPN client sa isang Linux host ay nabibigo sa isa sa dalawang lugar. Maaring hindi maabot ng panloob na client ang sarili nitong server dahil nakuha na ng panlabas na tunnel ang transportasyong iyon, o muling isinusulat ng pangalawang client ang talahanayan ng ruta at tumitigil sa paggana ang unang tunnel. Ang dalawang problema ay nasa routing, hindi sa encryption, at parehong nalulutas bago magdala ang bagong tunnel ng anumang trapikong aplikasyon. Ang mga address dito ay halimbawa lamang: tun0 ang panlabas na tunnel, 203.0.113.9 ang panloob na server, at TCP 9999 ang daloy na dapat gumamit ng panloob na landas.

Dalawang paraan ng pagpalya, isang talahanayan ng ruta

Ang panloob na client ay nagbubukas ng UDP socket patungo sa server nito, at sinusundan ng socket na iyon ang kasalukuyang talahanayan ng ruta tulad ng iba. Kung ang panlabas na tunnel ay may default na, pumapasok ang mga handshake packet sa panlabas na tunnel. Gumagana lamang ito kapag naabot ng panlabas na server ang panloob na server at pumapayag ang kabilang panig na dalhin ang daloy; kung hindi, natitigil ang handshake at muling sumusubok ang client.

Ang pangalawang pagpalya ay nagmumula sa push ng server. Ang karaniwang push ay redirect-gateway def1, na naglalagay ng 0.0.0.0/1 at 128.0.0.0/1 sa halip na palitan ang default na ruta. Kaya nagbabanggaan ang dalawang client na bawat isa ay naglalagay ng sariling pares na /1, at ang pinakabagong pares ang nananalo para sa halos lahat ng destinasyon. Hanapin ang dalawang prefix na iyon sa talahanayan kapag namatay ang tunnel pagkatapos kumonekta ang pangalawa, dahil maaaring hindi kailanman nagbago ang default na ruta mismo.

Markahan ang daloy at bigyan ito ng talahanayan

Ihanda ang napiling trapiko sa pamamagitan ng pagmamarka nito sa talahanayang mangle at pagtutugma ng marka sa isang patakaran ng polisiya. Itinuturo ng patakaran ang isang nakalaang talahanayan na ang default na ruta ay ang panloob na aparato, kaya ang mga markadong packet lamang ang dumadaan sa panloob na landas.

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

Karamihan ng pagpalya sa hanay ng patakarang ito ay nagmumula sa dalawang pagkakamali. Ang halaga ng marka na itinatakda ng firewall at ang halagang itinutugma ng patakaran ay dapat magkapareho, dahil ang pagkakaiba ay walang dulot na error o epekto. At ang PREROUTING ay nakakakita lamang ng mga packet na dumarating mula sa labas, kaya ang koneksiyong sinimulan sa host na ito ay nangangailangan ng patakarang OUTPUT na may parehong pagtutugma bago pa man ito markahan.

Bawiin ang pagmamay-ari ng ruta mula sa pangalawang client

Dalawang opsiyon ang pumipigil sa pangalawang client na i-edit ang talahanayan, at gumagana sila sa magkaibang punto. Binabalewala ng route-nopull ang mga opsiyon ng rutang ipinadala ng push, kaya walang nailalagay. Tinatanggap ng route-noexec ang mga opsiyon sa kapaligiran ng client ngunit iniiwan sa hook ang pagbabago ng talahanayan, at iyon ang kailangan mo kapag kailangan mong makita ang inialok ng server.

Tumatakbo ang hook gamit ang mga halagang ipinadala sa kapaligiran nito, at dapat nitong idagdag lamang ang mga entry na inaprubahan mo. Gawin itong idempotent: linisin ang talahanayang pag-aari nito bago muling buuin, at huwag ipagpalagay na nag-iwan ng malinis na kalagayan ang naunang pagtakbo. Tumatawag muli ang hook sa muling pagkonekta, at ang hook na nagdadagdag nang walang paglilinis ay nag-iipon ng doble-dobleng ruta.

Pumili ng isang may-ari at isulat ito. Ang profile na nagtatakda ng dalawang opsiyon, o hook na nakikipagpaligsahan sa manu-manong script, ay gumagawa ng talahanayang walang makakapaliwanag mamaya.

Ipin ang dalawang address ng server

Kailangan ng panloob na server ang host route sa pamamagitan ng panlabas na aparato bago kumonekta ang panloob na client. Ang entry na iyon ang nag-iingat sa panloob na transportasyon sa loob ng panlabas na tunnel sa halip na hayaang sundan nito ang default.

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

Magdagdag din ng tugmang host route para sa panlabas na server sa pangunahing talahanayan, kung hindi ay maaaring ihanay ng muling pagkonekta ang transportasyon mismo ng panlabas na client papasok sa sariling tunnel nito. Hindi opsyonal ang pagkakasunod-sunod: idagdag ang mga entry na ito pagkatapos umiral ang kaugnay na interface, ibig sabihin ay hook o script na tumatakbo pagkatapos ng koneksiyon. Ang rutang tumuturo sa patay na aparato ay tinatanggal o binabalewala, kaya ang entry na isinulat sa boot ay hindi nakakalampas sa pagkakasunod-sunod na inakala mo.

Suriin ang paghahanap sa halip na basahin ang buong talahanayan. Binabanggit ng output ng paghahanap ng ruta ang aparato at source address na gagamitin ng kernel, at iyon mismo ang natatanggap ng client kapag binuksan nito ang socket.

Subukan ang kadena at gawing nakikita ang pagpalya

Kumuha ng capture sa panlabas na interface habang kumokonekta ang panloob na client. Dapat lumitaw ang panloob na handshake bilang naka-encrypt na payload sa loob ng panlabas na tunnel; kung lumitaw ito bilang ordinaryong UDP patungo sa 203.0.113.9, kulang ang host route at hindi kailanman nabuo ang kadena.

Ang kadenang tahimik na bumabalik sa pisikal na uplink ang pinakamasamang resulta, dahil walang ipinapahayag ang kalagayan ng interface at lumalabas ang panloob na trapiko mula sa maling source address. Kung ang pangalawang client ay makakapagkonekta nang direkta kapag bumagsak ang panlabas na tunnel, patayin ang landas na iyon o itali ito sa panlabas na interface upang makita ang pagpalya.

Tapusin gamit ang dalawang daloy at isang dump ng patakaran: ang markado at hindi markadong koneksiyon ay dapat dumaan sa magkaibang landas, at dapat ilista ng ip rule show ang priyoridad na nilayon mo. Kung parehong landas ang tinatahak ng dalawang daloy, hindi ginagamit ang marka sa lugar na iniisip mo.