Eitt forrit í gegnum WireGuard: binding er ekki leiðsögn

Stillingin lítur út eins og rofi fyrir hvert forrit, svo fólk bindur biðlarann við WireGuard-viðmótið og býst við að aðeins sá biðlari noti gönguna. Það sem bindingin gerir í raun er að velja upprunafang. Kjarninn leitar þá að leið að áfangastaðnum, finnur venjulegu sjálfgefnu leiðina og sendir pakkann út um eðlisfræðilega tenginguna með fangi göngunnar festu við. Aðeins leið sem valin er fyrir það upprunafang uppfyllir áformið.

Aðferðin hefur tvo helminga: leiðsögutöflu sem aðeins umferð göngunnar ætti að nota, og reglu sem sendir samsvarandi uppruna þangað.

Binding setur upprunafang og ekkert meira

Linux velur útgangsviðmót með því að fletta upp áfangastaðnum í leiðsögutöflu, eftir að stefnureglur hafa fengið tækifæri til að beina þeirri flettingu annað. Reglur geta valið eftir upprunafangi, eldveggsmerki, inngangsviðmóti, UID eða jafnvel porti; hver þeirra er önnur leið til að segja þessa umferð í stað allrar. Stilling VPN-biðlarans velur töfluna sem geymir leiðir göngunnar; reglan velur hvaða umferð má ráðfæra sig við hana. Bindingin ein og sér veitir hvorki heldur.

Þess vegna lítur bilunin svo undarlega út. Forritið notar örugglega fangið á göngunni, gangan er örugglega uppi, og umferðin fer örugglega út um rangt viðmót. Hver fullyrðing er sönn, og saman lýsa þær kerfi þar sem ekkert tengdi fangið við leiðina.

Gefðu göngunni eigin töflu

wg-quick setur leiðir þar sem sniðið segir til. Að bæta Table = 40 undir [Interface] færir þær í töflu 40 í stað aðaltöflunnar. Ræstu viðmótið og staðfestu að þær hafi komið: ip -4 route ls table 40 ætti að sýna leiðir göngunnar, og ip -4 route get 10.66.127.142 sýnir hvernig kjarninn leysir eina þeirra núna. Með leiðirnar í eigin töflu heldur aðaltaflan áfram að virka fyrir allt annað.

Gerðu það sama fyrir IPv6 í stað þess að passa breitt forskeyti. ip -6 rule add from fd00::2/128 lookup 40 festir eitt fang; fc00::/8 getur rekist á önnur viðmót á hýsilnum og búið til reglu sem passar við meira en ætlað var.

Bættu upprunareglunni við og fylgdu teljunum

Tengdu svo helmingana: ip -4 rule add from 10.66.127.142/32 lookup 40, með sama fangi festu við WireGuard-viðmótið. Settu báðar reglurnar í PostUp svo endurtenging endurheimti þær. Staðfestu með raunverulegri beiðni í stað stillingar: ip route get 1.1.1.1 from 10.66.127.142 ætti að nefna tæki göngunnar, og curl --interface wg0 ifconfig.me ætti að tilkynna fang göngunnar í stað heimilisfangsins.

Þegar það mistekst enn, lestu ip -s rule. Regla sem er til en hefur aldrei passað sýnir núllteljara, og það greinir ranga reglu frá því að engin regla sé til. Sú eina skipun sparar mikið af ágiskunum um hvort forritið hunsaði viðmótsstillinguna sína.

Hið gagnstæða tilfelli: haltu SSH utan göngunnar

Gagnstæða vandamálið er jafn algengt: wg-quick á sjálfgefnu leiðina og SSH-lotan til netþjónsins deyr mitt í lotunni. Reglur þess sitja á lágri forgangsröðunartölu, svo undantekning verður að vera metin á undan þeim. ip rule add dport 22 ipproto tcp table main priority 123 gerir það á nýrri iproute2; þar sem valið er ekki tiltækt skaltu merkja flæðið í nftables og passa merkina í staðinn.

Athugaðu líka svarleiðina. SSH-lota sem kemst á og þagnar svo hefur venjulega ósamhverfa leiðsögn, þar sem önnur áttin fer út um gönguna og hin um eðlisfræðilega viðmótið. ip route get fyrir fang netþjónsins segir þér hvaða leið svarið færi.

Skráðu töflunúmerið, upprunaregluna og undantekninguna í sniðið sjálft. Öll þrjú tilheyra einni hönnun og verða breytt saman.