Krossar en VPN-klient på din webbserver dess svar?

Webbplatsen laddas från en bärbar dator i samma nätverk och får tidsgräns från alla andra ställen, och värden kör också en VPN-klient för sin egen utgående trafik. Den kombinationen ger ett specifikt fel: den inkommande anslutningen kommer in, svaret lämnar via fel väg och klienten utanför ser aldrig något svar. Båda halvorna syns i samma paketfångst, så händelseordningen är den del som är värd att läsa.

En källbaserad routningsregel åtgärdar ofta symptomet. Den undantar också vanligtvis mer trafik än webbplatsen som motiverade den, och det är den delen som är värd att förstå innan du sparar regeln.

Symptomet: den svarar lokalt och inte utifrån

Inuti nätverket behöver svaret inte passera tunneln, så sidan laddas och tjänsten ser frisk ut. Utifrån når begäran värden och svaret routas in i VPN:en, där den bortre änden inte har någon anledning att acceptera det. Webbläsaren ser en tidsgräns i stället för en avvisning, vilket är kännetecknet för en enkelriktad väg och inte för en stängd port.

Bekräfta formen innan du ändrar routningen: lyssnaren är uppe, den lokala begäran lyckas och den externa begäran ger inget svar alls. De tre observationerna pekar tillsammans mot returvägen och inte mot webbserverns konfiguration. En så ren asymmetri är mer användbar än någon loggrada, eftersom den utesluter lyssnaren innan du läser ett enda felmeddelande.

Håll en oberoende administrationsväg öppen medan du arbetar. En regel som krossar din egen SSH-session förvandlar en tio minuters rättelse till ett fysiskt besök.

Vad en källväljare faktiskt matchar

I Linux-policyroutning matchar en regel som from 192.168.50.2 paket vars källa är den adressen. Den kodar inte att paketet fortsätter ett samtal som kom in via hemroutern, och den vet inte vilken process som skapade det. Adressen i det exemplet är illustrativ; byt ut den mot adressen som din värd faktiskt använder. Behandla raden som ett påstående om adresser och inget mer.

Om den valda tabellen levererar en vanlig standardväg kan varje paket med den källan ta samma undantag. En annan tjänst bunden till samma adress ärver det, och ett program som medvetet binder sig till den adressen ärver det också. Referensen för policyregler listar källa, destination, protokoll, port, märke och prioritet som separata väljare, vilket påminner om att källan ensam är den grövsta som finns.

Prioriteten avgör resultatet. Uppslagningar körs i ordning och den första tabellen som ger ett resultat kan avsluta sökningen, så en regel som placeras för tidigt kan dölja en mer specifik väg som en senare tabell skulle ha levererat. Läs hela den ordnade listan i stället för den enda rad du lade till. En regel som aldrig matchar kostar ingenting, medan en som matchar för tidigt tyst ändrar allt bakom sig.

Kontrollera returvägen och trafiken du inte avsåg

Läs reglerna och tabellerna och fråga sedan kärnan vilken väg ett visst par av källa och destination skulle ta. Att testa från värden själv är inte samma sak som att testa utifrån, så gör båda.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Acceptera sedan en ny extern anslutning och, separat, en begäran som fortfarande måste gå ut genom VPN:en. Om den andra nu går direkt ut är undantaget bredare än problemet du löste, och testet som betyder något är det du inte avsåg att ändra.

En kontroll av offentlig adress i en webbläsare rapporterar bara de begäranden som den webbläsaren gjorde. Den säger ingenting om webbserverns svar, om en annan lokal applikations källval eller om vad som händer med administrationstrafik efter nästa VPN-återanslutning.

Bestäm hur snävt undantaget kan vara

Två utformningar är försvarbara och de bör väljas medvetet. Om värden finns för att publicera denna tjänst och dess utgående trafik är oviktig, är en dedikerad lokal adress med en policy bara för WAN ett rimligt arrangemang förutsatt att du accepterar hela omfånget. Om bara vissa inkommande anslutningar ska kvalificera är adressvalet för grovt, och en anslutningsmedveten utformning hör hemma framför det.

Anteckna kontraktet du förlitar dig på: den offentliga mappningen, värdadressen som begäran levereras till och vägen svaret förväntas ta. En inkommande tjänst som publiceras via en VPN-leverantör är ett annat kontrakt än en som publiceras via en hemrouter, och ett undantag kopierat från ett exempel är ofta fel för det andra.

Behåll policyn i komponenten som äger routningen i stället för att klistra in ett kommando i en startfil. Regelordning, städning efter en nätverksändring och uppspelning efter en omstart måste alla överleva, och en otestad startfil misslyckas vanligtvis i det ögonblick du inte tittar. Avsluta med acceptansresultatet du kan försvara: en publicerad webbplats återställd och ett orelaterat flöde oförändrat.