VPN-roete of vuurmuurreël: watter een laat die pakket val?

Twee onafhanklike besluite gebeur met dieselfde pakket, en enige een van hulle kan die versoek stilswyend beëindig. Die roetesoektog kies 'n koppelvlak en 'n volgende sprong, en dan besluit die pakketfilter of daardie kombinasie deurgelaat word. 'n Tydverstreke antwoord sê vir jou een van die twee het geweier, nie watter nie. Werk die fases in volgorde deur, en die herstel is gewoonlik nie meer 'n raaiskoot nie.

Twee besluite, een pakket, twee eienaars

Die roetesoektog raadpleeg eers beleidsreëls, dan die tabel waarna hulle wys, en kies die mees spesifieke voorvoegsel wat by die bestemming pas. 'n Kliënt wat 'n tonnelroete geïnstalleer het, besit daardie besluit, en niks aan 'n vuurmuurreël kan dit vervang nie. Wanneer die soektog na 'n onverwagte plek wys, werk elke latere fase op die verkeerde pakket.

Filtering is apart. Op 'n Linux-gasheer verdeel die netfilter-hake verkeer volgens vir wie die pakket is: uitset verlaat die masjien, inset eindig daarop, deurvoer gaan daardeur. 'n Hek wat VPN-kliënte aanvaar en na 'n LAN roeteer, het die deurvoerpad nodig, en dit is juis die ketting wat die meeste verstekkonfigurasies leeg laat.

Bronkeuse hoort by dieselfde besluit, en dit is waar die meeste wanpassings skuil. Die kern kies 'n bronadres uit die uitgaande koppelvlak, tensy die roete een noem, so 'n filterreël wat vir die LAN-subnet geskryf is, pas nooit by 'n pakket wat met die tonneladres vertrek nie.

Lees wat die soektog werklik gekies het

Druk die besluit uit in plaas daarvan om dit af te lei. Die opdrag hieronder los die roete op wat die kern vir daardie bestemming sou gebruik, insluitend die koppelvlak en die bron wat dit sou kies:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN-kliënte installeer dikwels beleidsreëls by prioriteite onder die hooftabel, so 'n skoon hooftabel bewys op sigself niks. Vergelyk die reëlprioriteite met die tabelle wat hulle kies, en kyk of die tonnelroete 'n herverbinding oorleef in plaas daarvan om een keer met die hand bygevoeg te word.

Beleidsgebaseerde IPsec voeg 'n derde passingfase by wat roetering nie dek nie, soos strongSwan se deurvoernotas vir tonnel- en vervoeropstellings beskryf. Die sekuriteitsbeleid kies verkeer volgens voorvoegsel en protokol, terwyl die roete net besluit waar 'n onbeskermde pakket sou gaan. 'n Subnet wat geroteer word maar geen passende keurder het nie, bly óf onbeskermd óf word laat val, afhangende van die konfigurasie, en nie een van die uitkomste lyk soos 'n vuurmuurprobleem nie. Druk die beleid en vergelyk sy keurders met die voorvoegsels wat jy verwag het die tonnel sou dra.

Filtering geld by 'n haak, nie by 'n roete nie

'n Reël wat die VPN-luisteraar toelaat, is 'n reël oor verkeer wat aan die hek self gerig is. Dit sê niks oor kliënte wat gashere agter daardie hek bereik nie, want deurgevoerde verkeer gaan deur 'n ander ketting. Om die reëlstel as een plat lys te lees, is die gewone rede waarom 'n korrek-lykende reël nooit vuur nie.

Tellers besleg die vraag vinnig. 'n Reël met 'n nul pakkettelling is nooit bereik nie, wat op die verkeerde ketting, die verkeerde koppelvlak of 'n vroeëre druppel wys. 'n Reël met 'n groeiende telling onder 'n druppelbeleid is die grens waarna jy gesoek het, en die pakket word weggegooi eerder as verkeerd geroteer.

Stuur 'n probe deur die pad wat die kliënt gebruik

Toetse wat op die hek self uitgevoer word, reis deur uitset en inset, met die hek se eie bronadres. Dit is 'n ander pad as 'n kliënt se deurgevoerde versoek, so 'n suksesvolle plaaslike curl bewys minder as wat dit lyk. Probeer vanaf die masjien wat misluk, of spyker die koppelvlak en bron eksplisiet vas.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

'n Opname aan beide kante skei die oorblywende gevalle. 'n SYN wat die kliënt verlaat en nooit aankom nie, beteken roetering, enkripsie of 'n stroomop-toegangslys. 'n SYN wat aankom en geen antwoord kry nie, beteken die diens of sy gasheerfilter, en die tonnel was nooit die probleem nie.

Terugkeerverkeer verdien sy eie kyk. Asimmetriese roetering plus terugpadfiltering laat antwoorde val wat op die verkeerde koppelvlak aankom, wat as 'n eenrigtingverbinding eerder as 'n geblokkeerde poort wys. Kyk na die sysctl-waarde voordat jy die vuurmuur blameer vir 'n simptoom wat hy nie veroorsaak het nie.

Logging werk as 'n tweede mening, nie 'n eerste stap nie. 'n Tydelike logverklaring op die deurvoerketting noem die koppelvlak en adresse wat dit tref, en dit is maklik om later te verwyder. Los dit permanent daar en jy het 'n logvolume-probleem gebou in plaas van 'n antwoord.

Plaas elke verandering waar dit 'n herverbinding oorleef

'n Roete wat met ip route add bygevoeg is, leef totdat die koppelvlak afgaan. Hou dit eerder in die verbindingsprofiel: NetworkManager aanvaar ekstra roetes op die verbinding, en netplan hou hulle oor herstarte. Dieselfde reël geld vir 'n kliëntkant-vuurmuuruitsondering, wat ná die volgende herlaai weg is.

Reëls aan die bedienerkant hoort in die konfigurasielêer wat die diens by die begin laai, nie in 'n interaktiewe sessie wat eindig wanneer jy dit sluit nie. Skryf die reël, herlaai, en bevestig dat die teller beweeg het, want 'n herlaai wat die sintaksis verwerp het, laat die ou reëlstel stilswyend in plek.

Herhaal dan die oorspronklike toepassingsversoek van begin tot einde en teken aan watter laag verander het. 'n Roeteherstel wat ook 'n filterverandering nodig gehad het, sal steeds misluk, en die tweede mislukking lees baie makliker sodra jy weet die eerste is weg. Noteer die datum en die kliëntweergawe langs die resultaat, want roetering- en filteringverstekke beweeg albei tussen weergawes. Hou daardie nota op die kaartjie sodat die volgende persoon begin waar jy opgehou het in plaas daarvan om die tweefase-wandeling te herhaal.