Pravila, ki preusmerjajo vse vrata, lahko pogoltnejo vaš WireGuard poslušalec

Javni prehod že izvaja WireGuard na UDP 51820, SSH na 22 in eno aplikacijo, ki mora biti dosegljiva z interneta. Vabljivo pravilo preusmeri vsaka vrata na peera in razglasi delo za končano. Na prehodu WireGuard lahko to pravilo ujame promet samega tunela in vas zaklene iz stroja, ki ga zaključuje. Objava je odločitev o usmerjanju z izjemo za krmilno ravnino, ne ena vrstica DNAT.

Javni vhod ali vhod skozi tunel: izberite enega

Objava storitve ustvari novo vstopno točko v internetu. To ni isto kot podelitev članstva v VPN peeru, ker obiskovalec nikoli ne vstopi v tunel in prehod postane javni obraz zaledja. Ta razlika določi občinstvo pravila in njegovo potrdilo.

Upravljalni vmesniki redko spadajo na to mesto. Upravljalna stran, do katere pridejo pooblaščeni odjemalci VPN, ohranja napadalno površino znotraj tunela in se izogne izpostavitvi prijavnega obrazca poljubnemu skeniranju. Javne končne točke aplikacije še vedno potrebujejo lastno potrdilo TLS, overjanje in omejevanje hitrosti; šifrirani skok WireGuard ne ščiti odseka obiskovalca do prehoda.

Če mora biti storitev res javna, zapišite ime gostitelja, potrdilo, ki ga pokriva, in razpone obiskovalcev, ki naj bi jo dosegli. Ta tri dejstva pozneje določijo obliko pravila in politiko filtriranja. Vse zunaj njih je širjenje obsega na javnem poslušalcu.

Ena vrata noter, eno zaledje ven

Uporabite ena javna vrata in eno storitev zaledja. V tem primeru eth0 nosi javni naslov 198.51.100.20, naslov tunela prehoda je 10.200.0.1, peer pa izvaja aplikacijo na 10.200.0.7. Javni TCP 9443 se preslika v TCP 8443 peera:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

Pravilo SNAT se ujema s prevedenim zaledjem in izvirnim javnim ciljem, zato druga povezava do iste storitve zaledja ostane zunaj tega preslikavanja. Skrije tudi naslov obiskovalca pred peerom, in to je kompromis, zaradi katerega je usmerjena vrnitev z ohranitvijo vira ločena zasnova. Referenca razširitev iptables dokumentira oba cilja in njune možnosti ujemanja.

Preusmerjanje mora biti še vedno omogočeno, filtrirna veriga pa potrebuje dovoljenje za prevedeni cilj in vrata ter vzpostavljene odgovore. Veriga FORWARD vidi prevedeni cilj po DNAT, zato pravilo, napisano na javni naslov, ne ustreza preusmerjenemu paketu. Dovoljenje napišite na tuple zaledja, ne na javnega.

Peer mora sprejeti povezavo storitve z naslova tunela prehoda in poslati odgovor nazaj skozi tunel. Njegov AllowedIPs mora odobriti vir, ki ga dejansko prejme, kar je pri prevajanju vira naslov tunela prehoda, in širok vnos 0.0.0.0/0 na vsakem peeru za to zasnovo ni potreben. Povratni promet zavrže peer, katerega seznam ta naslov izpusti, ali zasnova z ohranitvijo vira, ki namesto tega preusmeri naslov samega obiskovalca, zato preverite vir, ki ga peer res vidi, ne tistega v vašem pravilu.

Držite lastne poslušalce prehoda zunaj pravila

Zamenjajte ujemanje vrat s pravilom, ki pokriva vsak cilj TCP in UDP, in lastna vtičnica WireGuard prehoda pade znotraj njega. Prevajanje cilja se zgodi, preden se stroj odloči, da je paket lokalen, zato lahko UDP 51820 konča pri peeru namesto v procesu, ki drži vsako peerjevo povezavo. Pravilo se naloži uspešno in tunel umre, kar je napaka, ki jo je s peerjeve strani težko brati.

SSH, nadzorni agenti in vsaka druga storitev, gostovana na prehodu, imajo enako izpostavljenost. Pravilo, ki preusmeri vse, ne loči krmilne ravnine od objavljene aplikacije, in prvi ponovni zagon po spremembi je trenutek, ko zaklep postane očiten. Pravilo, ki ujame vse, ne opozori na storitev, ki jo tiho prevzame. Ugotovite, ko naslednja povezava ne uspe.

Če je široko preusmerjanje res potrebno, rezervirajte krmilna vrata pred pravilom, ki ujame vse, ali uporabite ločen javni naslov za objavo. Druga možnost je čistejša, ker krmilni naslov obdrži lastno politiko, vendar mora ponudnik ta naslov zagotoviti; dodajanje zapisa DNS ga ne dodeli.

Široko preusmerjanje TCP in UDP tudi niso vsi protokoli. ICMP, IPv6, povratna informacija path-MTU in zunanji promet VPN potrebujejo lastno politiko, pravilo, ki pokriva TCP in UDP, pa te primere prepusti privzeti verigi.

Izberite model, preden napišete pravila

Štiri oblike pokrijejo večino objav s prehoda, izbira pa je odvisna od tega, koliko storitev izvajate in koliko tveganja v krmilni ravnini prenesete. Spodnja tabela jih razvrsti od najožje do najširše.

Začnite z ozkim modelom, tudi če pričakujete več storitev pozneje. Najlažje ga je pregledati, in pretvoriti niz ozkih pravil v pregledano pravilo, ki ujame vse, je preprostejše kot ugotoviti, kateri poslušalec ga je ujelo široko pravilo. Ne glede na model imejte pravila pri lastniku požarnega zidu. Uporaba vrstic iptables ob konfiguraciji UFW ali nftables, ki upravlja iste verige, ustvari politiko, ki se spreminja glede na vrstni red zagona.

Dokažite objavo in krmilno pot

Preizkusite s pooblaščenega zunanjega odjemalca z odobrenim imenom gostitelja in potrdilom, veljavnim zanj. Potrdite, katero zaledje je odgovorilo, nato preverite, da neodvisna javna vrata ostanejo zavrnjena. Onemogočeno preverjanje potrdila ni uspešen preizkus HTTPS, povezava, ki prispe do napačnega zaledja, pa je slabša od neuspele.

Nato preverite sam prehod: povežite peera WireGuard, odprite sejo SSH in potrdite, da nadzor še vedno poroča. Objavljena storitev lahko deluje, medtem ko je krmilna ravnina pokvarjena, zato obe preverjanji spadata v isto okno sprememb. Enkrat znova zaženite, da dokažete, da se pravila znova uporabijo v pričakovanem vrstnem redu, nato odstranite objavo in potrdite, da odstranitev res ustreza dodatku. Velik niz dodatkov ob zagonu z nepopolnim čiščenjem je način, kako začasen preizkus postane trajna odprtina.