Foarôf makke tun yn OpenVPN: ferliking fan de twa eigendomsmodellen

Immen makke tun1 foarôf oan, it profyl seit dev tun1, en de ferbining kin noch hieltyd net oanheakje. It bestean fan 'e namme op 'e host seit hast neat, want oanheakjen hinget ôf fan 'e nammromte, it type apparaat, wa't de ferbining besit en wat de daemon dwaan mei. It werbrûken fan in apparaat twingt ek in beslút dat de standertkonfiguraasje ferberget: hokker komponint de adressen en rûtes skriuwt. De fioelmodi fan 'e twa opstellings ferskille folle mear as de konfiguraasjeregels, dus beslute foar't jo in profyl bewurkje.

In namme is gjin oanheaksel

dev tun1 freget OpenVPN om dy neamde ynterface, en tradisjonele brûkersromte-builds sille besykje dy te iepenjen. As de namme it gewoane tun- of tap-patroan net folget, hat it profyl ek in byhearrende dev-type nedich, want it type wurdt nea út in tekenrige ôflaat. In TAP-apparaat is gjin TUN-apparaat mei in oar label: it ferkearde oanheakje mislearret óf streekrjocht, óf makket in ferbining dy't frames draacht dy't nimmen ferwachtet. Kontrolearje it type foar al it oare, want elke lettere kontrôle giet derfan út dat beide kanten it dermei iens binne. Fan dêrút, befêstigje dat it proses it apparaat wier iepenje kin, net allinnich sjen.

dev tun1
dev-type tun

It netwurk-ynterface en /dev/net/tun binne ferskillende objekten: it iene is in keppeling binnen in nammromte, it oare is it tekentapparaat dat in brûkersromte-programma brûkt om oan te heakjen. De Linux TUN/TAP-dokumintaasje beskriuwt dat oanheakpaad en de eigendomsregels foar persistinte apparaten. In root-shell dy't ip link útfiere kin, bewiist allinnich dat de shell privileezjes hat, net dat de daemon se hat. Eigendom fan it apparaatknooppunt, de kapasiteitenset fan 'e tsjinst en de brûker dêr't it ûnder draait moatte allegear oerienkomme foar't it iepenjen slagget.

In apparaat dat bestiet en net iepene wurde kin, is in eigendomsprobleem, gjin rûteprobleem. Behannelje it as sadanich by it debuggen, oars giet de middei oan it lêzen fan rûtetabellen dy't nea it probleem wiene.

Wa't konfigurearret de keppeling: twa eigendomsmodellen

Yn it earste model konfigurearret OpenVPN adressen en rûtes as ûnderdiel fan it opheljen fan 'e ferbining. Dat is it standertgedrach en it maklikst te begripen, want ien komponint makket de steat en hellet dy wer fuort. Yn it twadde model besit in eksterne behearder de ynterface, en ifconfig-noexec stopet OpenVPN derfan syn adreskonfiguraasjekommandos út te fieren en jout de parameters oan skripts. Dan moat de behearder sels de juste lokale en peer-konfiguraasje tapasse, wat mear wurk is as de namme fan 'e opsje suggerearret. Kieze tusken de twa is de fraach wa't de keppeling feroarje mei wylst dy omheech is.

ifconfig-noexec beslacht allinnich adressen: de rûtetabel bliuwt ûnoanroerd, en rûtekonfiguraasje heart by route-noexec. Behannelje de twa rjochtlinen as aparte kontrôles mei aparte eigners, want it iene ynstelle en it oare oannimme is in algemiene boarne fan heal konfigurearre keppelings. Kies krekt ien eigner per laach, adressen op ien plak en rûtes op ien plak. In netwurkbehearder en in VPN-help dy't tegearre adressen skriuwe is hoe't in ferbrekking steat wisket dêr't de oare kant noch fan ôfhinklik is.

Besjoch it apparaat út 'e nammromte dy't der ta docht

Besjoch it apparaat út 'e nammromte dêr't it VPN-proses yn draait, net út dy't jo shell tafallich yn sit. De twa kommando's hjirûnder beantwurdzje ferskillende fragen, en it ferskil docht bliken as in host in ynterface sjocht dy't in container net sjocht. Fiere se yn 'e opjûne folchoarder út, want it twadde hat allinnich sin as jo witte oft de keppeling überhaupt bestiet.

ip -details link show dev tun1
ip tuntap show

It earste kommando printsje de keppeling sa't de kernel dy sjocht, mei flaggen en ynterfacetype, en sa befêstigje jo dat dit it bedoelde apparaat is. It twadde listet persistinte tun/tap-ynfieringen op, dy't bestean sûnder dat ien proses se hâldt. In ynterface dy't op syn bedoelde eigner wachtet is in oare situaasje as in libbene tunnel oan in oare VPN, en allinnich it twadde ferklearret wêrom't jo eigen oanheaksel mislearret. Fyn it proses dat it apparaat hâldt foar't jo wat feroarje, want in persistinte ynfiering en in beset ynterface hawwe ferskillende oplossingen.

Stipe foar meardere rijen is in spesifike driveropstelling mei eigen easken, gjin tastimming foar net-relatearre prosessen om ien ynterface te dielen. In libbene sesje fan in oare eigner is in koördinaasjeprobleem, en gjin profylbewurking lost dat op.

Twa ferskillende soarten persistinsje

Kernelpersistinsje en persist-tun beskriuwe libbensdoerren dy't maklik te betiizjen binne en djoer te ferwikseljen. In persistint apparaat bestiet ûnôfhinklik fan elk proses, dus it oerlibbet in stop en kin troch de folgjende start wer brûkt wurde. persist-tun hâldt boarnen oer stipe sêfte resets binnen ien OpenVPN-proses, in folle koartere horizon. Net ien fan beiden belooft dat it stopjen fan 'e tsjinst rûtes en adressen op plak lit, en in ynterface dat sichtber bliuwt is gjin bewiis fan in wurkjende fersifere sesje.

Befêstigje ek de backend, want in foarôf makke ynterface seit neat oer hokker ymplemintaasje dy iepenje sil. Mienskipsbuilds mei it direkte gegevenspaad sille besykje it te brûken, útsein as it ûntwerp oars seit. Wêr't de ferzje de skeakel stipet, kiest disable-dco ynstee it brûkersromtepaad; âldere motoren en oare kliïnten hawwe sa'n rjochtline net, dus hâld de ferzjebetingst njonken de opsje ynstee fan oan te nimmen dat dy jildt.

Wat brekt as allinnich it opstarten test wurdt

In eigendomsoerienkomst kin de earste test helje en de lêste mislearje, wat it opstarten op himsels in minne kontrôle makket. Besjoch ynstee twa oergongen: in sêfte reset, en in folsleine stop folge troch in start.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Opstarten is it maklike gefal: de ienheid komt omheech, de keppeling ferskynt en de statusútfier neamt it profyl dat laden is. Oanheakjen is it momint dat de daemon it apparaat iepenet, dus fiere de keppelingskontrôle út neidat de ienheid aktyf meldt, net dêrfoar. As de keppeling bestiet wylst de status noch aktivearret, sjogge jo in persistint apparaat dêr't noch nimmen oan heakke is, gjin wurkjende tunnel. Stjoer echte ferkear troch de keppeling foar't jo fierder gean, want in oanheakke ynterface sûnder brûkbere rûte is noch altyd in mislearring.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

In sêfte reset heart de sesje brûkber en de boarnen yntakt te litten, en dat is it wurk dat persist-tun docht. In folsleine stop is it plak dêr't in eksterne behearder himsels ferriedt: as de keppeling of syn adressen de stop oerlibje, besit immen oars se, en dat is óf de steat dy't jo dokumintearre hawwe, óf de bug dy't jo krekt fûn hawwe. Skriuw beide waarnimmingen njonken it profyl, sadat de folgjende feroaring fan bewiis út begjint ynstee fan fan in diagram.