Ien app troch WireGuard: bining is gjin rûtering

De ynstelling liket op in skeakel per applikaasje, dat minsken bine de klient oan de WireGuard-ynterface en ferwachtsje dat allinnich dy klient de tunnel brûkt. Wat de bining eins docht, is in boarneadres kieze. Dêrnei siket de kernel in rûte foar de bestimming, fynt de gewoane standertrûte en stjoert it pakket oer de fysike ferbining nei bûten mei it tunneladres deroan taheakke. Allinnich in rûte dy't foar dat boarneadres keazen is, foltôget de bedoeling.

It meganisme hat twa helten: in rûteringstabel dy't allinnich it ferkear fan de tunnel brûke moat, en in regel dy't de oerienkommende boarne dêrhinne stjoert.

Bining set in boarneadres, net mear

Linux kiest in útgongsynterface troch de bestimming yn in rûteringstabel te sykjen, nei't beliedsregels de kâns hân hawwe om dy syk opnij te rjochtsjen. Regels kinne kieze op it boarneadres, in fjoermuorremerk, de ynkommende ynterface, in UID of sels in poarte; elk is in oare manier om te sizzen dit ferkear ynstee fan alles. De konfiguraasje fan de VPN-klient kiest de tabel dy't de tunnelrûtes hâldt; de regel kiest hokker ferkear it konsultearje mei. Bining allinnich leveret gjin fan beide.

Dêrom liket de flater sa frjemd. De applikaasje brûkt grif it tunneladres, de tunnel is grif omheech, en it ferkear giet grif troch de ferkearde ynterface nei bûten. Eltse bewearing is wier, en tegearre beskriuwe se in systeem wêryn't neat it adres mei de rûte ferbûn hie.

Jou de tunnel syn eigen tabel

wg-quick ynstallearret rûtes wêr't it profyl it ek seit. Table = 40 ûnder [Interface] taheakje ferpleatst se nei tabel 40 ynstee fan de haadtabel. Bring de ynterface omheech en befêstigje dat se oankamen: ip -4 route ls table 40 heart de rûtes fan de tunnel te toanen, en ip -4 route get 10.66.127.142 lit sjen hoe't de kernel no ien fan har oplost. Mei de rûtes yn har eigen tabel bliuwt de haadtabel foar al it oare wurkjen.

Doch itselde foar IPv6 ynstee fan in breed foarheaksel te matsen. ip -6 rule add from fd00::2/128 lookup 40 set ien adres fêst; fc00::/8 kin botse mei oare ynterfaces op de host en in regel meitsje dy't mear matst as bedoeld.

Foegje de boarneregel ta en sjoch nei de tellers

Ferbynt dêrnei de helten: ip -4 rule add from 10.66.127.142/32 lookup 40, mei itselde adres oan de WireGuard-ynterface taheakke. Set beide regels yn PostUp sadat in werferbining se werstelt. Ferifiearje mei in echte oanfraach ynstee fan in ynstelling: ip route get 1.1.1.1 from 10.66.127.142 heart it tunnetapparaat te neamen, en curl --interface wg0 ifconfig.me heart it adres fan de tunnel te rapportearjen ynstee fan it thúsadres.

As it noch mislearret, lês ip -s rule. In regel dy't bestiet mar nea matst hat, toant tellers fan nul, en dat ûnderskiedt in ferkearde regel fan hielendal gjin regel. Dy iene opdracht sparret in protte rieden oer de fraach oft de applikaasje har ynterface-ynstelling negearre hat.

It omkearde gefal: hâld SSH bûten de tunnel

It tsjinoerstelde probleem is like gewoan: wg-quick besit de standertrûte en de SSH-sesje nei de tsjinner stjert midden yn de sesje. Syn regels steane op in leech prioriteitsnûmer, dat in útsûndering moat earder beoardiele wurde as sy. ip rule add dport 22 ipproto tcp table main priority 123 docht dat op in resint iproute2; wêr't de selektor net beskikber is, markearje de stream yn nftables en matsje de marke ynstee.

Kontrolearje ek it antwurdpaad. In SSH-sesje dy't ta stân komt en dan stil wurdt, hat meastentiids asymmetryske rûtering, mei ien rjochting troch de tunnel nei bûten en de oare troch de fysike ynterface. ip route get foar it tsjinneradres fertelt jo hokker kant it antwurd út gean soe.

Skriuw it tabelnûmer, de boarneregel en de útsûndering yn it profyl sels op. Alle trije hearre by ien ûntwerp en wurde tegearre bewurke.