Routerreko kill switch-a FORWARD, OUTPUT eta IPv6 estaltzen dituena

Routerrean saioa hasten duzu, foro-mezu batetik hartutako kill switch arau-multzo bat itsasten duzu, eta LANak nabigatzeari uzten dio tunela erortzen den unean. Bi egun geroago routerrak oraindik bere DNS erregistro dinamikoa WAN arruntaren bidez eguneratzen du, eta gonbidatuen eramangarriak oraindik IPv6 guneetara iristen da. Bi jokabideak normalak dira, itsatsitako arauek kate bat eta helbide-familia bat estaltzen zituelako, eta horietako bat ere ez delako router osoa. Paketeen bideak ordenan zeharkatzeak zehazki erakusten du zer geratu zen kanpo.

Hasi routerrean, ez eramangarrian

Router mailako politika erakargarria da bulego txiki batentzat, atzean dagoen gailu bakoitzak jokabide bera heredatzen duelako eta inork ezin duelako bezeroaren etengailua piztea ahaztu. Proba egiteko leku bakarra ere ematen dizu firmware eguneraketa bakoitzaren ondoren. Ematen ez duena routerraren beraren trafikoaren edo bigarren helbide-familia baten estaldura automatikoa da, eta horiek dira porrot egin duten ezarpen gehienen atzeko bi hutsuneak.

Ezer aldatu aurretik, idatzi hiru datu paperean: WAN interfazearen izena, LAN zubiaren izena eta VPNren amaierako puntuaren helbidea eta ataka. Hirurak beharko dituzu arauetan, eta interfaze-izenak asmatzea da itxuraz zuzena den arau-multzo batek ezer egiten ez duelako arrazoi ohikoena.

Egin pakete batek har ditzakeen hiru bideak

Eramangarritik internetera doan trafikoa birbidaltzen da, beraz FORWARD katea zeharkatzen du. Routerrak berak sortzen duen trafikoa, hala nola DNS birbidalketa, NTP kontsultak, DDNS eguneraketak eta VPN kontrol-kanala, OUTPUT-etik igarotzen da. Routerrari zuzendutako kudeaketa-trafikoa INPUT-etik iristen da.

Beraz, FORWARD-en soilik eraikitako kill switch batek bezeroak babesten ditu eta ez beste ezer. Taulak erakusten du hasierako eszenako ihesa aurreikusgarria dela, ez misteriotsua.

Diseinu gehienetan ez duzu kill switch-ik behar INPUT-en, baina kudeaketa-sarrera funtzionatzen mantendu behar duzu tunela jaitsita dagoen bitartean. Bestela, VPNak huts egiten duen lehen aldian kontsola-kable batekin joango zara bulegora.

Ordenatu arauak tunela oraindik altxatu ahal izateko

Funtzionatzen duen kill switch bat ukatze batean amaitzen den baimen-zerrenda bat da, eta ordenak egiten du kill switch hareharri izan beharrean. Baimendu lehenik loopback, VPN amaierako puntua, ezarritako fluxuen erantzunak eta tunelaren interfazea; ukatu gainerakoa azkenik.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

Amaierako puntuak helbide bat izan behar du puntu honetan, ez ostalari-izen bat. Behin azken ukatzeak DNS blokeatzen duenean, hornitzailearen ostalari-izena aipatzen duen araua ezin da gehiago ebatzi, eta tunela ez da berriro abiarazten berrabiarazte baten ondoren. Hornitzaileak amaierako puntuak txandakatzen baditu, ebatzi izena politika aplikatu aurretik eta freskatu arau hori script beretik.

Izan ezazu forma bera FORWARD-en bezeroen trafikorako, eta jarri kudeaketa-arau esplizitu bat ukatzearen gainean. Eduki ezazu kudeaketa-arau hori estu baina irisgarri, eta berretsi lehen SSH saioa itxi aurretik bigarren bat irekiz. Kill switch bat aldatzean zeure burua kanpoan ixtea nahikoa ohikoa da horretarako plangintza egiteko. WireGuard daraman router batean, parearen allowed-ips balioek erabakitzen dute zer sartzen den tunelera, eta arau hauek erabakitzen dute zer irten daitekeen hura gabe.

IPv6-k bere ate propioa behar du

Goiko guztia IPv4 da. Zure LANak IPv6 funtzionala badu eta tunelak IPv4 soilik garraiatzen badu, estalitako gailu bakoitzak zuzenean internetera doan bide bat du oraindik, zure arau berriek inoiz ikusten ez dutena. Pila biko eramangarri batek gogoz nahiago izango du, eta kill switch-a hautsita egongo da IPv4-rekin probatzen duenarentzat bakarrik.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Hemen ere ordenak garrantzia du: loopback-en onarpenak WANen ukapenaren aurretik joan behar du, bestela routerreko zerbitzu lokalak modu bitxietan huts egiten hasiko dira. Sareak IPv6 batere erabiltzen ez badu, sinpleagoa da WANen eta LANen desgaitzea, eta ez da ahazteko ezer geratzen.

VPN bezero batzuek IPv4 rako bakarrik instalatzen dute bide lehenetsia eta lehendik dagoen IPv6 bide lehenetsia ukituta uzten dute. Egiaztatu bideratze-taula tunela konektatu ondoren, bezeroak konpondu duela suposatu beharrean.

Frogatu tunela jaitsita

Gelditu tunela routerretik eta probatu hiru lekutatik ordena honetan:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

Bide-kontsultak pakete bat nora joango litzatekeen esaten dizu, eta kontagailuek zure arauak inoiz bat etorri diren esaten dizute. Porrot egin duen proba baten ondoren pakete zero dituen arau batek ez du ezer babesten, eta ohiko arrazoia idatzi duzunaren ezberdina den interfaze-izen bat da. Probatu esplizituki routerrak sortutako trafikoa, LAN aldeko proba batek ezin duelako OUTPUT erabili.

Erabaki hutsegite-modua behar duzun aurretik. Fail-closed-ek bezeroak lineaz kanpo mantentzen ditu tunela itzultzen den arte; fail-open-ek WAN sarbide arrunta leheneratzen du eta zuretzat garrantzitsua zen trafikoaren helburua hondatzen du. Metrika altuko blackhole bide bat VPN pool-era bigarren geruza erabilgarria da fail-closed diseinuetarako, tunelaren bidea desagertzen denean bizirik irauten duelako, bide lehenetsira itzuli beharrean.

Onartu konfigurazioa LAN bezero batek, routerrak sortutako eskaera batek eta IPv6 eskaera batek tunela jaitsita huts egiten dutenean, eta hirurak berriro funtzionatzen dutenean tunela altxatutakoan.