Program wat aan die VPN-adres gebind is, gebruik steeds die verkeerde roete

’n Socket wat aan die VPN-adres gebind is, volg die gewone verstekroete. Kontroleer adreseienaarskap en die bronbewuste soektog voordat jy beleidsreëls byvoeg.

’n Program bind aan die VPN se adres, en die verbinding verlaat steeds die gewone verstekroete. Niks in die bind het misluk nie; dit het presies gedoen wat ’n bind doen. Om ’n socket aan ’n plaaslike adres te bind, kies die bronadres wat die kernel in die opkop sit. Dit installeer nie ’n roete nie, en dit skep nie ’n beleidsreël wat pakkette met daardie bron in ’n bepaalde tonnel stuur nie.

Die res van hierdie runbook is die kontroleorde wat ek gebruik, saam met die opdrag wat elke waarneming lewer.

Wat ’n bind werklik bepaal

’n Bind ken ’n plaaslike adres aan die socket toe. Die kernel voer dan dieselfde roetesoektog uit wat dit andersins sou gedoen het, tensy ’n beleidsreël verander watter tabel daardie soektog lees.

Daarom kan ’n pakket met ’n VPN-bronadres op ’n fisiese koppelvlak vertrek. Aan die ander kant kom dit van ’n private reeks wat die netwerk nooit op daardie pad verwag het nie, die terugverkeer het geen roete terug nie, en die verbinding hang of herstel.

Die Linux IP-socketverwysing dokumenteer die bind-semantiek. Die roeteringhelfte woon in ip-rule en ip-route, en dit is om ’n rede aparte handleidings.

Bevestig die adres hoort aan hierdie naamruimte

’n Adres waaraan jy kan bind, moet op ’n koppelvlak binne die netwerknaamruimte bestaan waarin die program loop. ’n Eweknie-adres, ’n poortadres, of ’n adres wat net in ’n ander naamruimte bestaan, is nie bindbaar nie, en die oproep misluk met EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Voer daardie drie in dieselfde konteks as die program uit: dieselfde naamruimte, en dieselfde gebruiker as jy dit kan kry. ’n Ou net30-diagram is nie bewys van watter adres jou huidige topologie aan die kliënt toegewys het nie. Lees die koppelvlak wat werklik op is.

Lees die soektog vir daardie bron en bestemming

Een opdrag beantwoord die vraag wat die bind nie beantwoord het nie:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Die eerste reël druk die roete wat ’n pakket van daardie bron na daardie bestemming sou neem, insluitend die uitgaande koppelvlak en die voorkeurbron. As dit die fisiese koppelvlak noem, stem die bind en die roete nie ooreen nie, en die pakket sal vertrek met ’n bron waarnatoe die pad nie kan terugkeer nie.

ip rule show sê dan of enige reël ’n ander tabel sou gekies het. Prioriteite maak hier saak, want die eerste ooreenstemmende reël wen en ’n allesvanger bo jou reël maak jou reël onsigbaar.

Installeer ’n beleidsreël net as dit die ontwerp is

Brongebaseerde roetering is ’n doelbewuste ontwerp, nie ’n herstelling vir een program nie. As die beleidseienaar wil hê dat verkeer van die tonnel-subnet die tonnel moet gebruik, hoort die reël in daardie eienaar se konfigurasie eerder as in ’n eenmalige opdrag op jou skootrekenaar.

’n Werkbare vorm is ’n toegewyde tabel met ’n verstekroete deur die tonnel, plus ’n reël wat die VPN-bronreeks in daardie tabel stuur. Voeg die uitsonderings by wat die ontwerp nodig het, want ’n tabel met net ’n tonnelverstek sal bestemmings vang wat bedoel is om plaaslik te bly of oor die fisiese pad bereikbaar te wees.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Draai terug met ip rule del en ip route flush table 100. Enigiets wat so bygevoeg is, verdwyn by herlaai tensy ’n bestuurder dit skryf, wat beide ’n veiligheidseienskap en ’n rede is om nie die enigste kopie in jou shell-geskiedenis te hou nie.

Verifieer met drie waarnemings

Teken die bron aan wat die program versoek het, die roete wat die soektog gekies het, en die bron wat die bediener werklik gesien het.

Daardie drie kan verskil, en elke verskil wys na ’n ander plek. ’n Opname op die tonnelkoppelvlak bewys die pakket het met die regte bron vertrek. ’n Opname op die fisiese koppelvlak bewys dit het die verkeerde pad gevat. Die bedienerkant-aansig is die enigste een wat die pad van begin tot einde bewys.

As die program ’n bind-tot-toestel-opsie of ’n roeteringsmodus per program bied, behandel dit as ’n ander meganisme met ander beperkings. Soortgelyke instellings los nie almal op dieselfde kernel-besluit uit nie.

Verwante artikels