Hoekom 'n bediener agter 'n VPN-kliënt deur die tonnel antwoord

Inkomende verbindings na 'n gasheer wat ook 'n VPN-kliënt laat loop, misluk op 'n baie spesifieke manier: die handdruk kom aan, die daemon antwoord, en die kliënt kry niks terug nie. Niks blokkeer die poort nie. Die antwoord het deur die tonnel gegaan, want die tonnel besit die verstekroete en die kernel stuur antwoorde volgens bestemming eerder as volgens die herinnering van waar die versoek gekom het. Die daemon is reg en die poort is oop.

Die antwoord word geroteer, nie onthou nie

'n VPN-kliënt wat 'n verstekroete installeer, voeg 'n inskrywing by wat die LAN-deurlaat oortref, hetsy deur maatstaf of deur die ruimte in twee meer spesifieke helftes te verdeel. Uitgaande pakkette kies nou die tonnelkoppelvlak. Die kernel vra nooit waar die pakket wat beantwoord word oorspronklik aangekom het nie. Daardie enkele weglating verduidelik elke simptoom wat volg.

Die voorwaartse rigting word volgens bestemming geroteer, en die omgekeerde rigting ook. Die antwoord is aan 'n publieke kliënt geadresseer, wat die tonnel graag sal dra. Die verre kant ontvang 'n pakket waarvan die bron nie aan hom behoort nie, gooi dit weg, en die oorspronklike kliënt wag tot dit tyd uitloop.

Streng omgekeerde-pad-filtering kan die inkomende pakket laat val voordat die daemon dit ooit lees. Kyk eerste na daardie teller, want 'n filterval en 'n roeteringsfout lyk van buite identies.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Die eerste opdrag wys watter verstek tans wen. Die tweede rapporteer of streng filtering globaal of per koppelvlak geld, en die derde wys enige voorwaartse-kettingreël wat moontlik betrokke is.

Drie maniere om die terugroete te behou

Om die diensbestemming van die tonnel uit te sluit, is die engste opsie. 'n Gasheervoorsiening wat na die LAN-deurlaat wys, plus 'n daemon wat aan die fisiese adres gebind is in plaas van elke adres, hou daardie een stroom buite die tonnel. Die verandering is plaaslik en maklik om terug te draai.

Beleidsroetering is die algemene antwoord. 'n Reël wat op die bronadres of op 'n firewallmerk geskoei is, kies 'n tabel waarvan die verstek na die WAN-deurlaat wys, terwyl die gasheer se eie verbindings aanhou om die tonnel te gebruik. Hou die prioriteit eksplisiet sodat die reël later nie oorskadu kan word nie.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Die eerste twee opdragte bou die alternatiewe pad vir antwoorde wat van die publieke adres afkomstig is. Die derde vra die kernel watter pad daardie presiese bron en bestemming sou volg, en dit is hoe jy bevestig dat die reël enige effek het.

Bronvertaling is die derde opsie en die enigste een wat 'n router oorleef wat reeds NAT voor die diens doen. Die antwoord moet na daardie router terugkeer, en maskering na die WAN-koppelvlak bereik dit terwyl dit die kliënt van die dienslogboeke verberg. Om die verstekroete ná verbinding met die hand te vervang, is 'n diagnose, want die kliënt herskryf die tabel by die volgende herverbinding.

Wanneer die boks ook vir 'n LAN roeteer

Dieselfde fout verskyn een sprong verder uit wanneer die gasheer vir toestelle agter hom roeteer. 'n Inkomende verbinding word na 'n interne toestel deurgestuur wie se enigste terugroete die tonnel is, en die antwoord bereik die eksterne kliënt vanaf die verskaffer se adres. Die interne toestel werk die hele tyd korrek.

Verbindingsopsporing sien dan 'n antwoord vir 'n stroom wat dit nooit aangeteken het nie en laat dit val. Bestemmingsvertaling lewer die inkomende verbinding by die toestel af, en bronvertaling laat die antwoord lyk asof dit van die router self kom.

'n Beleidsroete wat die deurgestuurde poort op die WAN hou terwyl die router se eie verkeer die tonnel gebruik, is die netter ekwivalent. Sonder bronvertaling is die antwoord aan die eksterne kliënt geadresseer, en die interne toestel het glad geen roete vir daardie adres nie.

Drie ondersoeke wat die oorsake skei

Voer drie ondersoeke uit: 'n verbinding in die boks in vanaf die internet, 'n verbinding daaruit na 'n publieke gasheer, en 'n naamopsoeking. Wanneer die eerste twee verskil, is die antwoordpad skuldig. Wanneer name beide kante toe misluk, is die oplosser 'n ander fout wat bloot dieselfde tonnel deel.

Maak eers die roeteringsvraag reg, kyk dan na name. Om die twee te meng, is hoe 'n werkende bediener vir 'n stukkende oplosser geblameer word.

Teken aan watter koppelvlak die uitsondering noem en hou die konfigurasie onder weergawebestuur. 'n Reël wat teen 'n koppelvlak geskryf is wat ná 'n opgradering hernoem word, slaag vandag en faal ná die volgende herlaai.