Dalawang profile ang konektado, at ang isa sa kanila ay tahimik na nagdadala ng trapikong para sa isa pa. Maaaring patakbuhin ng isang Linux host ang dalawang OpenVPN client nang sabay nang walang kahirapan. Ang hindi nito magagawa ay magpasya para sa iyo kung aling proseso ang maaaring mag-claim ng aling prefix. Ang desisyong iyon ay dapat gawin bago umangat ang pangalawang tunnel, hindi pagkatapos tumigil sumagot ang isang resource.

Magsimula sa gawaing dapat gawin ng pangalawang link

Ang isang opisina na maaabot sa isang profile at isang lab na maaabot sa isa pa ay nangangailangan ng dalawang tunnel na nakaangat at wala sa kanila ang nag-claim ng lahat. Ang isang matigas ang ulong aplikasyon na kailangang lumabas sa pangalawang profile ay nangangailangan ng tuntunin ng patakaran, hindi ng pangalawang default na ruta. Ang standby na link ay nangangailangan lamang ng isang tunnel na tumatakbo sa isang pagkakataon, kaya hindi dapat magsimula ang reserba kasama ng makina.

Ito ay tatlong magkakaibang configuration, at nagkakalito dahil ang tatlo ay nagsisimula sa parehong paraan: pangalawang profile at matagumpay na koneksyon. Isulat muna ang nilalayong kaayusan, pagkatapos ay i-configure patungo roon. Ang isang pangungusap tungkol sa layunin ay nakakatipid ng isang oras ng pagkuha ng packet.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Ang unang utos ay naglilista ng mga tumatakbong instance, kabilang ang mga mano-manong sinimulan sa labas ng manager. Ang pangalawa ay nagpi-print ng kasalukuyang default claim, at iyon ang estado na kakailanganin mong ipaliwanag mamaya.

Ang magkakapatong na pool ay nasisira bago pa ang routing

Dalawang server ang masayang maglalaan ng mga address mula sa parehong 10.8.0.0/24. Ang client ay may dalawang interface sa loob ng isang prefix na walang nagsasabi kung aling destinasyon ang pag-aari ng alin, at ang resultang pag-uugali ay mukhang fault sa routing ngunit talagang fault sa pagnunumero. Ang muling pagbilang ng pool ay nagkakahalaga ng isang pag-edit ng configuration; bawat kasunod na routing workaround ay nagkakahalaga ng isang weekend. Suriin ang pool bago magdagdag ng ruta para dito.

Tingnan din ang lokal na LAN. Ang isang home LAN na may numerong 192.168.1.0/24 na inilalantad din ng isang tunnel ay gumagawa ng parehong kalabuan, at ang sintomas ay isang hostname na nare-resolve habang ang koneksyon ay hindi kailanman nakumpleto. Iyon ay mukhang fault sa pag-resolve ng pangalan hanggang sa i-print mo ang mga ruta.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Ihambing ang dalawang output sa dalawang server configuration bago hawakan ang client. Kung nag-o-overlap ang mga prefix, huminto at muling magbilang, dahil walang dami ng restart ang makakapaghiwalay sa kanila.

Bigyan ang bawat profile ng sariling unit at bawat prefix ng may-ari

Bawat profile ay may sariling pangalan ng instance at sariling configuration file, kaya ang instance na tinatawag na office ay naglo-load ng office.conf habang ang tinatawag na lab ay naglo-load ng lab.conf. Kumpirmahin ang mapping na iyon sa pamamagitan ng service manager sa halip na magtiwala sa listahan ng direktoryo, dahil ang isang drop-in ay maaaring magbago kung aling file ang naglo-load. Ang maling mapping ay nangangahulugan na iaayos mo ang profile na hindi tumatakbo.

Pagkatapos ay magpasya kung sino ang nag-install ng mga ruta. Kapag nagtutulak ang mga server ng hindi tugmang set, alinman sa tanggihan ang pagtulak at ilista ang mga prefix mismo, o hayaan ang isang profile na panatilihin ang default at gabayan ang isa pa gamit ang mga tuntunin ng patakaran. Dalawang proseso na parehong nag-install ng default ay nagtatapos sa isang tahimik na panalo at walang nakasulat na talaan ng desisyon.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Ang una ay nagpapakita ng unit kasama ang anumang override na nagbabago ng mga argumento nito. Ang pangalawa ay nagpapakita kung tinatanggap ng profile ang mga pushed route, at iyon ang switch na nagpapasya sa lahat ng sumusunod.

Pinapanatili ng mga marka ang mga tugon sa interface kung saan sila nanggaling

Kapag ang bawat tunnel ay nagsisilbi sa magkakaibang source, ang isang tugon ay maaaring lumabas sa maling link at ang koneksyon ay namamatay pagkatapos ng unang packet. Ang pattern na nananatili ay markahan ang mga papasok na packet ayon sa input interface, ibalik ang markang iyon sa tugon, at bigyan ang bawat marka ng table na may sariling default gateway.

Ang maluwag na reverse-path filtering ay karaniwang kailangang luwagan para sa mga apektadong interface, dahil ang isang tugon ay lehitimong dumarating sa isang link na hindi pipiliin ng pangunahing table. Panatilihing makitid ang mga marka upang hindi nila mahuli ang sariling naka-encrypt na trapiko ng mga tunnel, na magpapadala sa tunnel sa pamamagitan ng sarili nito.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Basahin ang mga umiiral na tuntunin bago magdagdag ng isa pa. Ang mga dobleng priyoridad at nakalimutang table ang karaniwang dahilan kung bakit ang patakaran sa marka ay tila walang epekto.

Patunayan ang paghihiwalay sa pamamagitan ng paghinto ng isang link

Sa dalawang tunnel na nakaangat, itala ang address ng bawat interface, ang ruta patungo sa isang host sa likod ng bawat tunnel, at ang landas na tinatahak ng isang walang kaugnayang destinasyon. Tanungin ang kernel para sa lookup sa halip na magbasa ng isang table, dahil ang isang table ay hindi kailanman nagpapakita ng huling desisyon.

Pagkatapos ay ihinto ang isang instance at panoorin ang interface at mga ruta nito na nawawala habang ang isa ay nagpapatuloy. Ang pagkasira sa nakaligtas ay nangangahulugan na ang dalawa ay nagbabahagi pa rin ng pangalan ng device, ruta o tuntunin ng firewall na walang naghiwalay.

Ibalik ang hininto na profile at ulitin ang parehong mga pagsusuri. Kapag ang isang tunnel ay nakaligtas lamang sa unang pag-start pagkatapos ng reboot, tinitingnan mo ang depekto sa lifecycle at hindi disenyo ng routing.

Kaugnay na mga artikulo