Varför en /32-värdrutt håller VPN-slutpunkten nåbar
En värdrutt väljer en adress, inte ett subnät. Den kan hålla en tunnelslutpunkt nåbar eller fästa en resurs, men blir inaktuell när adresserna ändras.
Du öppnar routingtabellen efter anslutning och hittar en enda adress som routas genom tunneln medan subnätet runt den fortfarande går till den lokala gatewayen. Den posten är en värdrutt: en adress, matchad av ett prefix med bara ettor. Det spelar roll eftersom routingbeslut använder det längsta matchande prefixet, så en /32 kan överrida en /24 eller en standardrutt utan att ändra någon av dem. Om det är ett noggrant undantag eller ett framtida avbrott beror på vilken adress den namnger och vem som underhåller den.
En adress, en post i tabellen
En IPv4-värdrutt har ett /32-prefix och en IPv6-värdrutt har /128, vilket betyder att posten kan matcha exakt en destinationsadress. Ingenting annat i tabellen flyttar sig: subnätet som täcker den och standardrutten stannar där de var. Den smala posten vinner för den adressen därför att prefixet är längre, inte därför att den lades till senare.
Den egenskapen gör en värdrutt till ett bra undantag och en dålig vana. Två /32-poster som namnger en tjänsts ytterdörr täcker inte dess andra adress, dess IPv6-adress eller adressen den flyttar till nästa månad. En tabell full av oförklarade enadressposter betyder vanligtvis att någon fortsatte att lappa runt ett subnätsbeslut i stället för att fatta det. Läs prefixlängden först och fråga sedan vad posten ska skydda.
Läs posten från klienten och utåt
Börja på maskinen med problemet, eftersom samma adress kan routas olika på en bärbar dator och på gatewayen framför den. Fråga kärnan vilken väg den skulle välja för den exakta adress som programmet använder, i stället för att läsa tabellen uppifrån. Svaret innehåller gränssnittet och nästa hopp, som tillsammans är beslutet.
ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25
Upprepa frågan för den adressfamilj som programmet faktiskt väljer, eftersom en klient kan föredra IPv6 och tyst kringgå ett IPv4-undantag. Jämför resultatet före och efter att tunneln kommer upp och spara båda utskrifterna. Den jämförelsen visar om klienten lade till posten vid anslutningen eller om den redan fanns där.
En permanent post och en runtime-post misslyckas olika. Runtime-posten försvinner med sessionen, medan den permanenta överlever en omstart och fortsätter skicka trafik till en gateway som inte längre finns.
Slutpunktsundantaget och rekursionsfällan
VPN-klienter installerar vanligtvis en värdrutt till serverns yttre adress via den ursprungliga gatewayen innan de omdirigerar standardrutten. Utan den posten skulle de krypterade paketen skickas in i tunneln de försöker bygga, och anslutningen skulle loopa tills den tog slut.
Fällan dyker upp när tunnelns accepterade subnät råkar innehålla den slutpunktsadressen, eller när en andra profil senare lägger till en bredare rutt. Då förlorar slutpunktsposten mot ett längre prefix och sessionen kollapsar så snart den börjar föra trafik. Att skriva slutpunktsadressen bredvid de accepterade subnäten är det billigaste sättet att upptäcka kollisionen före användarna. Det förklarar också varför samma profil fungerar från ett nätverk och misslyckas från ett annat.
Verifiera den väg programmet verkligen använder
En lyckad ping till värdnamnet är svagt bevis när programmet ansluter till en annan adress eller en annan familj. Verifiera den exakta kombinationen av adress, familj, port och gränssnitt, från maskinen som kör klienten.
ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net
Om vägen är fel, avgör om kravet är ett nätverk eller en adress innan du redigerar något. Ett krav på en enda adress motiverar en värdrutt med en kommentar och en ägare; en tjänst med roterande adresser behöver domänbaserad routing eller ett ärligt subnätsbeslut.
Ta bort poster som inte längre motsvarar en verklig destination och notera dem du behåller. En oförklarad /32 går tre månader senare inte att skilja från ett fel, och nästa person raderar den utan att veta vad som hängde på den.