Waarom een volledige tunnelroute de server afsnijdt die hem draagt

Schakel een volledige tunnel in en elke bestemming hoort nu bij de VPN-interface, inclusief de machine die hem beëindigt. De buitenste pakketten die de tunnel dragen, zijn aan die machine geadresseerd, dus de route verbruikt uiteindelijk het transport waarvan hij afhankelijk is. Eén extra specifieke route lost het op, en de reden is het waard om te begrijpen. Zonder die reden herintroduceert de volgende herbouw de fout.

Een route die zijn eigen transport opeet

Encapsulatie wikkelt elk pakket in een tweede header. De buitenste is geadresseerd van het lokale fysieke adres naar het openbare adres van de server, en hij moet de fysieke verbinding oversteken voordat er ooit een tunnel kan bestaan.

Laat nu de opzoeking voor dat openbare adres de tunnel kiezen. Om het pakket te versturen moet de machine het inkapselen, wat een route naar hetzelfde adres vereist, en die geeft de tunnel terug. Clients gaan hier op een van twee manieren mee om. Een voorzichtige weigert de standaardroute te installeren en meldt een fout, terwijl een minder voorzichtige succes meldt en vervolgens niets verplaatst. De stille fout is degene die een middag kost.

De langste-prefixovereenkomst beslist de opzoeking voordat er enige metriek wordt geraadpleegd, dus een route voor één adres overtreft elke standaardroute op de machine. Dat is het hele mechanisme achter de reparatie.

Installeer de uitzondering vóór de standaardroute

Maak een route voor één adres voor de server, met de fysieke gateway als volgende hop, voordat de standaardroute beweegt. Volgorde is belangrijk: hem achteraf installeren betekent leven met een kapotte tunnel terwijl je typt.

De meeste clients doen dit ongevraagd. OpenVPN zoekt het externe adres op en pint het vast voordat de standaardgateway wordt herschreven, en de optie route-delay bestaat voor platforms waar die volgorde racet. wg-quick neemt een heel andere weg, door pakketten te markeren en een beleidsregel te raadplegen in plaats van een uitzondering toe te voegen. Verschillende mechanismen, dezelfde eis: het buitenste pakket moet ontsnappen aan de tunnel die het maakt.

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

De uitvoer van de opzoeking is de acceptatietest. Hij moet het fysieke apparaat en de fysieke volgende hop noemen. Een tunnelapparaat in dat antwoord betekent dat de uitzondering ontbreekt, of is geplaatst na iets dat hem overstemt.

Het spiegelbeeld op de server

Dezelfde val wacht aan de andere kant, omgekeerd. Geef de server een standaardroute via een andere tunnel, of duw hem een route toe die de openbare adressen van de clients dekt, en zijn antwoorden krijgen een gewoonte in de verkeerde richting.

Stel je een client voor die verbindt en een verzoek stuurt. Het antwoord is geadresseerd aan het openbare adres van die client, dat nu bij een tunnelroute past, dus het vertrekt vanaf een andere interface met een bron die de client nooit heeft gekozen. De client kan dat pakket ontvangen en het alsnog weggooien, omdat niets het verbindt met het verzoek dat hij stuurde. Werk vanuit de routingbeslissing van de server in plaats van vanuit de time-out van de client, want slechts één van beide toont de werkelijke keuze.

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

Er bestaan drie reparaties en ze zijn niet gelijk. De dienst aan het fysieke adres vastpinnen, of de bron vertalen, beide verbergen de routingbeslissing in plaats van hem te corrigeren. Antwoordverkeer voor de tunnelpool via een speciale tabel sturen corrigeert de oorzaak, en de andere twee zijn alleen aanvaardbaar zolang het routingontwerp bevroren is.

Uitzonderingen die de tunnel blijft stelen

Een handvol taken heeft het open internet nodig, zelfs terwijl de tunnel de standaardroute bezit, en elk heeft zijn eigen uitzondering nodig. De dynamische DNS-updater is meestal de eerste die breekt.

Hij lost de provider op, opent een verbinding en ontdekt dat zijn eigen pakketten door een tunnel reizen waarvan het adres seconden geleden is veranderd, dus de update mislukt of publiceert het verkeerde adres. Drie uitwegen: pin de provider vast met een hostroute via de fysieke gateway, voer de update uit voordat de tunnel omhoog gaat, of geef de updater een beleidstabel die de tunnel nooit aanraakt. Tijdsynchronisatie heeft dezelfde blootstelling op een apparaat dat opstart zonder resolver, en eindpunten voor certificaatvalidatie horen om dezelfde reden op de lijst.

Een uitzondering die niemand opschreef, is een uitzondering die de volgende herbouw stil laat vallen.

Bewijs het na een herverbinding, niet ervoor

Test drie bestemmingen, niet één: het eindpunt, een privéadres achter de tunnel en een openbaar adres erbuiten. Eén geslaagde opzoeking zegt bijna niets over de andere twee.

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

Herstart dan de verbinding, want een client die zijn tabel bij het herverbinden opnieuw opbouwt, gooit een route weg die je met de hand hebt getypt. Met een kill switch in werking, controleer of het eindpunt is toegestaan, anders kan de tunnel na een netwerkwijziging niet terugkeren en ziet het symptoom eruit als een storing. Bewaar de uitzondering in het profiel of het unit-bestand in plaats van in een shell-geschiedenis, zodat de herverbinding hem opnieuw aanmaakt in plaats van hem te wissen.