Varför en full tunneldriven väg skär av servern som bär den

Slå på en full tunnel och varje destination tillhör nu VPN-gränssnittet, inklusive maskinen som avslutar den. De yttre paketen som bär tunneln är adresserade till den maskinen, så vägen äter till slut upp den transport den är beroende av. En extra specifik väg löser det, och skälet är värt att förstå. Utan det skälet återinför nästa ombyggnad felet.

En väg som äter sin egen transport

Inkapslingen lindar varje paket i ett andra huvud. Det yttre adresseras från den lokala fysiska adressen till serverns publika adress, och det måste korsa den fysiska länken innan någon tunnel kan existera.

Låt nu uppslaget efter den publika adressen välja tunneln. För att skicka paketet måste maskinen kapsla in det, vilket kräver en väg till samma adress, och den returnerar tunneln. Klienter hanterar detta på ett av två sätt. En försiktig vägrar installera standardvägen och rapporterar ett fel, medan en mindre försiktig rapporterar framgång och flyttar sedan ingenting. Det tysta felet är det som kostar en eftermiddag.

Det längsta prefixets matchning avgör uppslaget innan någon metrik konsulteras, så en väg för en enda adress överträffar varje standardväg på maskinen. Det är hela mekanismen bakom reparationen.

Installera undantaget före standardvägen

Skapa en väg för en enda adress för servern, med den fysiska gatewayen som nästa hopp, innan standardvägen flyttas. Ordningen spelar roll: att installera den efteråt innebär att leva med en trasig tunnel medan du skriver.

De flesta klienter gör detta utan att bli ombedda. OpenVPN slår upp fjärradressen och fäster den innan standardgatewayen skrivs om, och dess route-delay-alternativ finns för plattformar där den sekvensen kappas. wg-quick tar en helt annan väg, genom att märka paket och rådfråga en policyregel i stället för att lägga till ett undantag. Olika mekanismer, samma krav: det yttre paketet måste undkomma tunneln det skapar.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Uppslagets utdata är acceptanstestet. Det måste namnge den fysiska enheten och det fysiska nästa hoppet. En tunnelenhet i det svaret betyder att undantaget saknas, eller placerades efter något som övertrumfar det.

Spegelbilden på servern

Samma fälla väntar på andra sidan, omvänt. Ge servern en standardväg genom en annan tunnel, eller skjut en väg till den som täcker klienternas publika adresser, och dess svar får en vana att gå åt fel håll.

Föreställ dig en klient som ansluter och skickar en förfrågan. Svaret adresseras till den klientens publika adress, som nu matchar en tunnelväg, så det lämnar ett annat gränssnitt med en källa som klienten aldrig slagit. Klienten kan ta emot paketet och ändå kasta det, eftersom ingenting binder det till förfrågan den skickade. Utgå från serverns routingbeslut i stället för klientens tidsgräns, eftersom bara en av dem visar det faktiska valet.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Det finns tre reparationer och de är inte likvärdiga. Att fästa tjänsten vid den fysiska adressen eller översätta källan döljer båda routingbeslutet i stället för att rätta det. Att skicka svartrafik för tunnelpoolen genom en dedikerad tabell rättar orsaken, och de andra två är bara acceptabla så länge routingdesignen är fryst.

Undantag som tunneln fortsätter att stjäla

En handfull uppgifter behöver det öppna internet även när tunneln äger standardvägen, och var och en behöver sitt eget undantag. Den dynamiska DNS-uppdateraren brukar vara den första som går sönder.

Den slår upp leverantören, öppnar en anslutning och upptäcker att dess egna paket färdas genom en tunnel vars adress ändrades för sekunder sedan, så uppdateringen misslyckas eller publicerar fel adress. Tre vägar ut: fäst leverantören med en värdväg genom den fysiska gatewayen, kör uppdateringen innan tunneln reser sig, eller ge uppdateraren en policytabell som tunneln aldrig rör. Tidssynkronisering har samma exponering på en enhet som startar utan resolver, och slutpunkter för certifikatvalidering hör hemma på listan av samma skäl.

Ett undantag som ingen skrev ned är ett undantag som nästa ombyggnad tyst tappar.

Bevisa det efter en återanslutning, inte före

Testa tre destinationer, inte en: slutpunkten, en privat adress bakom tunneln och en publik adress bortom den. Ett enda lyckat uppslag säger nästan ingenting om de andra två.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Starta sedan om anslutningen, eftersom en klient som bygger upp sin tabell på nytt vid återanslutning kastar en väg du skrev för hand. Med en kill switch i spel, kontrollera att slutpunkten är tillåten, annars kan tunneln inte komma tillbaka efter en nätverksändring och symptomet ser ut som ett avbrott. Spara undantaget i profilen eller unit-filen i stället för i en shell-historik, så att återanslutningen återskapar det i stället för att radera det.