Nær WireGuard-biðlari ekki OpenVPN-biðlara?

Báðir göngin tengjast, hver biðlari nær í gáttina, og á þeirri stundu sem annar prófar vistfang hins hverfa pakkarnir. Ekkert er rangt við aðra hvora handtökuna, og engin endurútgáfa lykla breytir því. Gáttin ber venjulega ódulkóðaða IP-pakka milli tveggja eigin tengi sinna, svo samskiptareglurnar þurfa aldrei að skilja hvora aðra; það sem þær þurfa eru þrír hlutir sem engin handtaka veitir. Þekja áfangastaðar á upprunabiðlaranum, eignarhald uppruna í gáttinni og afturleið hinum megin. Einkennin eru þau sömu fyrir alla þrjá, þess vegna eru þeir greindir saman.

Einkennin vantar einn hluta í einu

Þessi hönnun notar WireGuard-safn 10.71.0.0/24 á wg1 og OpenVPN-safn 10.72.0.0/24 á tun1, og enda bæði á einni gátt. Beiðnin sem er prófuð fer frá 10.71.0.5 í HTTPS á 10.72.0.30. Hvert skref hér fyrir neðan snýst um þetta eina flæði. Hver prófun hefur aðra bilunarsignatúru þótt notandinn upplifi þær eins, og venjulega vantar aðeins einn af þremur í einu.

Byrjaðu á að staðfesta að bæði söfnin séu raunverulega á þessari gátt og að framsending sé virk í nafnrýminu þar sem göngin lifa. Gátt sem endar báðar samskiptareglurnar í ólíkum nafnrýmum sendir ekkert á milli þeirra, og það er þess virði að útiloka það áður en nokkur jafningjastilling er lesin.

Lengdu þekju áfangastaðar á arminum

Á WireGuard-biðlaranum verður fyrirliggjandi jafningjafærsla að velja gáttina fyrir OpenVPN-áfangastaðinn, sem þýðir að forskeyti áfangastaðarins verður að koma fram í leyfðum lista þess jafningja. Að bæta því við býr ekki til annað göng; það breytir því hvaða jafningja biðlarinn velur þegar hann flettir því vistfangi, og með wg-quick fylgir leiðin listanum venjulega sjálfkrafa.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Leyfðu raunverulegu lykla- og endapunktalínunum ósnortnum og mundu að stjórnandi sem notar Table = off tekur enga leið af þessum lista yfirleitt. Í því tilviki verður sama forskeyti að vera sett í leiðatöflu kerfisins af þeim sem á það, og leið sem vantar þar lítur nákvæmlega út eins og leyft forskeyti sem vantar.

Haltu eignarhaldi uppruna í gáttinni

Jafningjafærsla þessa biðlara í gáttinni ætti áfram að eiga nákvæmlega upprunavistfang þess biðlara. Leyfð vistföng eru athuguð í báðar áttir: þau velja jafningja fyrir útleið og staðfesta að uppruni innkomins pakka tilheyri þeim jafningja sem sendi hann. Að setja OpenVPN-safnið í færslu armsins af því arminn vill ná í það er mistökin sem beina umferð til rangs þátttakanda.

AllowedIPs = 10.71.0.5/32

Lestu þá færslu sem yfirlýsingu um eignarhald en ekki sem leiðarhagræði. Allt annað sem biðlarinn þarf að ná í tilheyrir áfangastabalistanum hans, ekki hugmynd gáttarinnar um hvað þessum jafningja er leyft að senda.

Gefðu OpenVPN-hliðinni afturleið

Áfangastaðurinn þarf nú leið til baka að WireGuard-upprunanum, og fyrir biðlara úr safni kemur hún venjulega sem ýtt leið frá OpenVPN-þjóninum. Ýttu henni aðeins til biðlara sem eiga að hafa hana, og staðfestu á biðlaranum að hún hafi verið samþykkt í stað þess að gera ráð fyrir að fyrirmælin hafi verið beitt.

push "route 10.71.0.0 255.255.255.0"

Dreifing leiða er ekki heimild. Þegar áfangastaðurinn stendur bak við annan OpenVPN-biðlara í stað þess að vera í safninu, bætast eignarhald þess biðlara á eigin LAN og framsendingarkröfur hans við hönnunina, og ýtta leiðin er aðeins fyrri helmingurinn. Endurorðaðu kröfuna sem línurit áður en fyrirmælum er bætt við: hvaða hnútur á hvaða forskeyti og hvaða hnútur sendir fram á við til þess.

Leyfðu aðeins þá einu þjónustu sem þú ætlaðir að leyfa

Með framsendingu virka og bæði söfnin leiðanleg er spurningin sem eftir er stefna. Skrifaðu regluna fyrir tiltekið flæði en ekki fyrir tengiparið almennt, forskoðaðu hana áður en henni er beitt og haltu stöðufestu afturleiðinni svo svörum sé ekki lokað sem nýjum tengingum. Þurrkeyrsla kostar ekkert og sýnir nákvæmlega hvað yrði bætt við.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Þetta eru reglur um framsenda umferð, aðskildar frá hlustunarreglum gáttarinnar fyrir þjónusturnar tvær. Að opna ytri UDP-gáttir heimilar ekki innri beiðnina, og að heimila innri beiðnina krefst hvorki ótakmarkaðs SSH að gáttinni né sjálfgefins leyfis á framsendingu. Eldveggur áfangastaðarins og hlustunarvistfang verða líka að stemma, því þjónusta sem er bundin við loopback hafnar jafnvel best leiðbeindu pakkanum. Stefna sem nær aðeins yfir aðra átt samræðnanna bregst venjulega með farsælli beiðni og hljóðu svari, sem er ruglingslegasta niðurstaðan af þremur.

Gagnkvæmar leiðir þýða venjulega að engrar upprunapýðingar sé þörf, sem varðveitir WireGuard-vistfangið á áfangastaðnum og gerir annála læsilega. Bættu ekki við alhliða masquerading af því tveimur samskiptareglum er blandað saman, og fjarlægðu ekki fyrirliggjandi pýðingarreglu án þess að vita hvað veltur á henni. Staðfestu síðan eina flæðið enda til enda og prófaðu líka eitt bannað upprunavistfang eða gátt: handtaka sem virkar hvorum megin sannar hvorki krossleiðina né einangrunina.