Pigilan ang mga kliyente ng VPN na maabot ang isa't isa sa tunel

Dalawang kliyente ay maaaring parehong buksan ang jump host at wala pa ring anumang gawain sa pagbubukas ng isa't isa. Ang maabot ang isang serbisyo ay desisyon sa pagpapasa, samantalang ang maabot ang isang kapwa ay desisyon sa patakaran, at iniingatan ito ng karamihan ng mga stack ng VPN sa magkahiwalay na bagay. Wala sa anumang i-configure mo para sa una ang nagpapatupad ng pangalawa. Kaya ang gawain ay hindi magdagdag ng panuntunan, kundi hanapin ang bagay na nagpapasya sa trapikong kapwa sa server na ito, isulat doon ang pagtanggi, at patunayan ito mula sa isang kliyente.

Ang ruta patungo sa pinagsasaluhang serbisyo ay hindi pahintulot sa pagitan ng mga kapwa

Ang pag-anunsyo ng subnet ng mga kliyente ay nagsasabi sa kapwa kung paano ilagay ang pakete sa kawad patungo sa address ng ibang kliyente. Kung ang paketeng iyon ay maihahatid ay pinagpapasyahan pagkatapos, ng anumang nagpapasa nito. Sa gateway na Linux iyon ang FORWARD chain; sa loob ng daemon sa user space iyon ang sariling talahanayan ng sesyon ng tunel. Ang ruta ay sumasagot sa maabot at iniiwan ang pahintulot na hindi ginalaw.

Kaya ang pagsusuring panghiwalay na nagbabasa lamang ng mga ruta ay walang pinapatunayan. Maaaring itulak ang /24 sa bawat kliyente habang ang bawat pakete sa pagitan ng mga kapwa ay itinatapon sa kawit ng pagpapasa. Ang mapanganib na kaso ay ang kabaligtaran: walang malinaw na panuntunan, isang mapagpayag na default, at paghihiwalay na umiiral lamang dahil walang sumubok nito.

Isulat ang pangangailangan sa isang linya bago magbukas ng terminal. Maabot ang bloke ng mga serbisyo at ang jump host, huwag maabot ang anumang iba sa loob ng bloke ng mga kliyente.

Alamin kung sino talaga ang nagpapasa ng pakete ng kapwa

Dalawang ugali ng server ang magkamukha mula sa panig ng kliyente at nangangailangan ng magkaibang panuntunan. Maaaring muling ipasa ng kernel ang pakete palabas ng interface ng tunel, o kinokopya ito ng daemon sa pagitan ng mga sesyon at hindi ito nakikita ng kernel.

Ang WireGuard ay kabilang sa unang grupo: wala itong switch sa pagitan ng mga kapwa, kaya ang pakete mula 10.8.0.4 patungong 10.8.0.5 ay dumarating sa wg0, tumatama sa kawit ng pagpapasa at muling iruruta palabas ng wg0 kapag sinasaklaw ng AllowedIPs ang dalawang address. Ang OpenVPN ay ang ikalawang grupo kapag nakatakda ang client-to-client sa configuration ng server, dahil ipinapasa ng direktibang iyon ang pakete sa pagitan ng mga sesyon sa user space. Suriin ang naka-load na configuration para sa direktibang iyon bago magsulat ng anuman. Ang panuntunan ng kernel na hindi kailanman nakakakita ng trapiko ay hindi makikilala sa panuntunang gumagana, at ganoon natatapos ang isang deployment na walang anumang paghihiwalay.

Basahin ang epektibong configuration at hindi ang file na inaakala mong naka-load, dahil nagdadala ang mga pakete ng distribusyon ng kanilang sariling mga pagsasama. Kung ang daemon ang nagpapasa, ang pagtanggi ay nasa sarili nitong mga kontrol kada kliyente, at ang firewall ng host ay nagsasala lamang ng trapikong patungo sa host. Kung ang kernel ang nagpapasa, ang kawit ng pagpapasa ang tanging lugar na mahalaga.

Ang mga rutadong at isinaling deployment ay nangangailangan ng isa pang pagsusuri: ang pinagmulan na nakikita ng malayong kliyente ay maaaring hindi ang inaasahan mo. Kung gayon ang panuntunang tumutugma sa subnet ng mga kliyente ay walang katugma. Itala ang address na nakakaligtas sa pagsasalin bago isulat ang tugma, at piliing itugma ang pares ng interface kaysa manghula ng mga address ng NAT.

Bigyan ang bawat address ng pagkakakilanlang maaaring bawiin nang mag-isa

Bumagsak ang paghihiwalay sa sandaling magbahagi ng isang kredensyal ang dalawang aparato. Ang panuntunang nakatali sa pagkakakilanlang iyon ay hindi sila maihihiwalay, at ang pagbawi ng nawawalang laptop ay nagbabawi sa buong grupo. Ang mga sertipiko kada aparato o mga susi kada kapwa ay nagpapanatili ng pagbawi sa lokal at ng patakarang nababasa, dahil ang bawat address ay tumutugma sa eksaktong isang tao o makina. Kung saan hindi ito magawa ng disenyo, sabihin ito sa runbook sa halip na ilarawan ang panuntunan bilang pinong butil.

Dapat sumang-ayon ang paglalaan ng address sa patakaran. Maglaan ng bloke para sa mga serbisyo, bloke para sa mga kliyente, at mamahagi ng address ng kliyente mula sa pool na kontrolado mo at hindi mula sa saklaw ng unang dumating. Kung nagsasalin o nagbubuklod ang server, itago ang talahanayan ng pagmamapa sa tabi ng configuration, dahil ang talahanayang iyon ang kailangan ng susunod na mambabasa upang muli ring makuha ang panuntunan.

Ilagay ang pagtanggi kung saan tumatawid ang pakete sa tunel

Sa gateway na nagpapasa ng trapikong WireGuard, dalawang panuntunan ang sumasaklaw sa kaso: payagan ang bloke ng mga serbisyo, pagkatapos itapon ang natitirang bahagi ng bloke ng mga kliyente. Ang pares ng interface ay kasinghalaga ng mga address, dahil ang pagtutugma lamang sa destinasyon ay nahuhuli rin ang trapikong nagmumula sa LAN. I-load ang mga ito sa ganoong pagkakasunod-sunod upang ang pahintulot ay unang suriin.

Sa nftables ang pares ay pumapasok sa umiiral na talahanayan ng inet filter, pahintulot muna at pagkatapos ay pagtatapon. Ang dalawang tugma ay nagtatali ng pares ng interface pati na ang mga address.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Basahin pabalik ang chain pagkatapos i-load sa halip na umasa sa exit status, at kumpirmahin na ang dalawang panuntunan ay nasa nilalayong pagkakasunod-sunod. Magdagdag ng tugmang ip6 na panuntunan para sa pool ng IPv6, kung hindi ang pares ng v4 ay palamuti lamang sa dual-stack na tunel. Kung may mapagpayag nang patakaran sa pagpapasa ang server, idagdag ang pagtatapon sa halip na palitan ang buong chain.

Kapag naka-enable ang client-to-client sa OpenVPN, hindi kailanman tumutugma ang mga panuntunan sa pagpapasang ito sa trapikong kapwa at dapat mamuhay ang pagtanggi sa sariling mga kontrol ng daemon. Panatilihin ang mga panuntunan ng kernel para sa trapikong patungo sa host, ngunit huwag bilangin ang mga ito bilang kontrol ng paghihiwalay.

Patunayan ang pagtanggi mula sa isang kliyente, hindi mula sa server

Ang pagsubok mula sa gateway ay walang pinapatunayan, dahil ang trapikong nalikha sa lokal ay dumadaan sa landas ng output at hindi kailanman tumatawid sa kawit ng pagpapasa. Gumamit ng dalawang tunay na kliyente: isa na dapat umabot sa serbisyo at isa na dapat tanggihan. Patakbuhin muna ang kaso ng pahintulot, upang ang sirang tunel ay hindi mapagkamalang gumaganang patakaran.

Mula sa pinahintulutang kliyente, kumpirmahin na sumasagot ang serbisyo sa port nito. Mula sa parehong kliyente, subukan ang address ng kapwa at asahan ang tahimik na pagtatapon sa halip na pagtanggi:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

Ang itinapong pakete at ang offline na kapwa ay parehong mukhang timeout, kaya suriin ang mga counter bago magpasyahan. Kumpirmahin na tumataas ang counter ng panuntunan sa pagtatapon habang hayagang aktibo ang kapwa. Ulitin sa IPv6, kung saan ang nawawalang panuntunang ip6 ay nagpapakita ng pagtanggi sa v4 na parang mabisa. Itala ang mga tinanggap at tinanggihang resulta sa runbook kasama ang petsa, dahil muling makukuha ng susunod na paglipat ang panuntunan.