As jy IPv6 blokkeer om WireGuard toe te sluit, breek die gasheer

Die doel is redelik: net tonnelgebruikers moet die dienste op hierdie masjien bereik. Die implementering waarna mense gryp, is ’n IPv6-invoerketting wat alles behalwe WireGuard verwerp, en dit verwerp ook die verkeer wat die gasheer aan sy eie skakel gekoppel hou. Buurontdekking en padonderhoudsboodskappe is nie diens toegang nie, en om hulle te verwyder lewer ’n masjien wat onbereikbaar is om redes wat niks met jou beleid te doen het nie. Die tonnel kom op, die dienste is korrek beperk, en niks anders op die skakel werk nie.

Drie verantwoordelikhede, een reëlstel

Die eerste verantwoordelikheid is buitenste netwerkwerking: die gasheer moet aan sy skakel gekoppel bly, bure oplos en die padgrense van daardie skakel leer ken. Die tweede is die geënkripteerde luisteraar, wat UDP op die adres en poort wat jy gekies het, aanvaar. Die derde is die stel ontsleutelde dienste wat jy wil hê tonnelgebruikers moet bereik.

Dit is drie verskillende beleide, en net die tweede en derde gaan oor die VPN. ’n Reëlstel wat hulle as een behandel, erf ’n foutmodus waarin die verskerping van die toepassinggrens die gasheeraanhegting stilweg breek.

Hou hulle in aparte kettings of ten minste aparte kommentaar, sodat die volgende persoon kan sien watter reël om watter rede bestaan.

Wat ICMPv6 vir die gasheer doen

IPv6 maak vir baie meer as eggo op ICMPv6 staat. Buurversoek en -advertensie vervang ARP en is nodig vir plaaslike aflewering. Packet Too Big dra pad-MTU-inligting, en om dit te ignoreer lewer oordragte wat by groot pakkette vasval. Routeradvertensies dra die verstekroete en voorvoegselinligting wanneer die skakel outomatiese konfigurasie gebruik.

RFC 4890 skei die boodskappe wat ’n gasheerfilter moet toelaat van dié wat ’n administratiewe keuse is, en dit doen so in ’n gasheerafdeling wat verskil van die reëls vir ’n router wat tussen netwerke aanstuur. As jy net die aanstuur-afdeling lees, kry jy ’n invoerbeleid wat te streng is vir die gasheer wat dit beskerm.

Die praktiese reël is om die noodsaaklike fout- en konfigurasieboodskappe toe te laat op die koppelvlak wat hulle nodig het, beperk volgens tipe en bron waar die platform dit toelaat, en om ’n uitdruklike besluit oor die res te neem.

Om al dit met ’n allesomvattende ICMPv6-toelating te vervang, los die beskikbaarheidsprobleem op en gee die filtering prys. Om dit met ’n allesomvattende verwerping te vervang, los die filterprobleem op en gee die gasheer prys.

Laat die tonnel toe, dan die diens

Aanvaar die WireGuard-vervoer op die bedoelde buitenste adres en UDP-poort, en aanvaar die terugkeerverkeer deur verbindingnasporing. Laat dan die toepassingdienste deur die tonnelkoppelvlak toe, van die bronne wat jy werklik magtig.

’n Toelating vir die buitenste UDP-poort magtig nie die ontsleutelde versoeke daarbinne nie. Daardie onderskeid is die hele rede waarom die tonnelkoppelvlak in die diensreëls voorkom.

Lees die reëlstel soos dit bestaan, nie soos die lêer dit beskryf nie:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

’n Luisteraar op ’n fisieke adres is ’n aparte blootstelling van dieselfde diens op die tonneladres. As die masjien ook verkeer na ’n ander masjien aanstuur, is dit ’n aanstuurkettingbesluit eerder as hierdie invoerbeleid, en dit vereis sy eie redenasie.

Toets die skakel, nie net die tonnel nie

’n Werkende tonnel ná die verandering bewys minder as wat dit lyk, want ’n bestaande buurinskrywing en ’n gevestigde verbinding kan ’n beheerboodskap verberg wat die beleid nou verwerp.

Kontroleer die aanhegting direk en kontroleer dan dat die uitgeslote pad steeds misluk:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

’n Buurtabel wat ná ’n herbegin volledig bly, is die teken dat ontdekking steeds werk. ’n Tabel wat leegloop en nooit weer vol word nie, is die teken dat jy dit uitgefilter het. Die derde opdrag valideer die reëlstel se sintaks sonder om dit toe te pas, wat die moeite werd is terwyl jy nog ’n sessie het.

Herstel ’n gasheer waaruit jy jouself gesluit het

Voordat jy firewallreëls verander wat jou eie administrasiesessie dra, hou ’n tweede kanaal: ’n konsole, ’n seriële verbinding, of ’n geskeduleerde terugrol wat die nuwe reëls verwyder as jy dit nie kanselleer nie.

As ’n verandering jou wel uitsluit, is die herstel deur daardie kanaal en nie deur die netwerk wat jy pas verwyder het nie. Herstel die vorige reëlstel uit ’n gestoorde kopie, bevestig dat die gasheer weer bereikbaar is, en pas eers dan die beoogde beleid in kleiner stukke toe.

Die finale beleid is nie universeel nie. Adressering, roetering en die firewallimplementering is ontplooiingsinsette, maar die grens is oral dieselfde: weier onbedoelde toepassingtoegang terwyl die beheerverkeer wat die gemagtigde tonnel dra, behoue bly.