Slik gir du eitt test-LAN sin eigen WireGuard-utgang

Tre design løyser det same laboratorieproblemet: eit lite LAN må ut gjennom ein WireGuard-peer medan gatewayen sjølv held på den vanlege oppstraumsforbindelsen. Den freistande snarvegen er å flytte standardruta til rutaren inn i tunnelen, men det bryt den eigne administrasjonsvegen til boksen og alt anna han videresender. Det interessante alternativet er policy-ruting avgrensa til eitt grensesnitt og eitt prefiks. Vel mellom dei ved å svare på tre spørsmål om maskinen du faktisk har.

Avgjer kvar utgangen bur

Første spørsmål: videresender denne verten for noko anna? Ein dedikert laboratoriegateway kan leve med ein videresendingspolicy som droppar som standard. Ein ruter med produksjonsoppgåver kan ikkje, og å leggje eit konkurrerande regelsett oppå ein administrert brannmur er nettopp måten avbrot blir planlagde på. Andre: kan du eige to policyobjekt og rekkjefølgja deira over omstartar? Tredje: autoriserer peeren du har tunnelkjeldeadressa di og tilbyr han internett-utgang? Ein peer som berre eksponerer eit privat nettverk er eit anna produkt, og inga lokal rutingsendring rettar det. Viss noko svar er nei, set utgangen i eit namnerom eller i ein eingongs virtuell maskin i staden.

Eit namnerom eller ein VM kostar minne og gjev deg ein rein eksplosjonsradius. Policy-ruting kostar to reglar og lèt deg sitje att med éin boks å feilsøkje.

Vel utgangen som autoriserer kjelda di

Dei fleste feila i dette laboratoriet skjer før ein einaste brannmurregel finst. Operatøren av utgangen må godta kjeldeadressa pakkane dine ber etter omsetjinga, og i dette designet er det tunneladressa og ikkje LAN-prefikset. Difor høyrer maskering heime i designet frå starten og ikkje som eit seint tillegg.

Stadfest tre ting med operatøren: peeren autoriserer tunneladressa di, han videresender IPv4 i staden for å terminere hos seg sjølv, og han brukar utgåande NAT. Utan det første kjem pakkane dine fram og forsvinn. Utan det tredje går dei ut med ei privat kjelde og døyr på neste hopp. Sjekk deretter at wg-quick ikkje installerar si eiga standardrute, noko Table = off hindrar; den innstillinga undertrykkjer oppretting av ruter, ikkje AllowedIPs-kontrollane til peeren eller DNS-handteringa hans.

To policyobjekt gjer styringa

Styring krev ein tabell og ein regel. Tabellen held to ruter: LAN-prefikset ut av LAN-grensesnittet og ei standardrute ut av tunnelen. Regelen sender trafikk som kjem inn på LAN-grensesnittet og ber dette prefikset, inn i tabellen. Bruk iif-veljaren saman med kjeldevektinga, fordi dei eigne WireGuard-pakkane til gatewayen oppstår lokalt og aldri matchar eit innkommande grensesnitt.

Vakta kjem før oppslaget, ikkje etter. Den rekkjefølgja er heile sikkerheitseigenskapen ved designet.

Vakta er ein andre regel på same veljar der dommen er unreachable. Gje henne høgare numerisk prioritet slik at oppslaget framleis vinn medan tunnelen er oppe. Når tunnelruta forsvinn, returnerer oppslaget ingenting, og vakta stoppar søket i staden for å la det falle gjennom til WAN-standarden i hovudtabellen.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Lukk fallgruva før du opnar henne

Installer vakta først og oppslaget etterpå. Gjer du det omvendt, blir det att eit vindauge på sekund der trafikken frå ein testklient kan nå oppstraumsforbindelsen.

Filteret fullfører biletet. I forward-kroken godtek du retninga frå LAN til tunnel for testprefikset og den etablerte returretninga, og slepp deretter alt anna; NAT for det prefikset ut på tunnelgrensesnittet høyrer i postrouting. Nettopp å la policy drop bli ståande på forward-kjeda er det som gjer ei manglande rute til stille i staden for lekkasje. Reverse-path-filtrering krev laus modus på tunnelgrensesnittet, fordi ei offentleg kjelde som kjem dekapsulert har si beste omvende rute på WAN-sida. Linux tek den høgaste av verdien all og per grensesnitt, så å setje tunnelgrensesnittet er ikkje det same som å svekkje valideringa overalt.

Prov det med feiltilfellet

Still kjernen eit presist spørsmål ved å namngje kjeldeadressa til klienten og grensesnittet han kjem inn på. Eit oppslag utan begge svarar på eit anna spørsmål og vil sjå riktig ut i begge tilfelle. Sjå deretter på brannmurteljarane, overføringsstatusen til peeren og tenesta til klienten sjølv.

Test fjerninga ordentleg. Stopp tunnelen medan regelen og filteret blir ståande: klienten bør stoppe og den eigne trafikken til gatewayen bør halde fram med å verke. Stopp deretter peeren utan å røre det lokale grensesnittet, og det er tilfellet som fangar design som berre stolar på at ruta finst. Til slutt startar du på nytt og kontrollerer reglerekkjefølgja igjen, fordi ein nedtakingskrok som fjernar vakta gjev heile designet tilbake til hovudtabellen. Noter tabellnummer, prioritetar og grensesnittnamn på endringssaka, fordi neste person som legg til ein regel er den som øydelegg dette.