Hvorfor er undernettet bag en OpenVPN-klient utilgængeligt?

Pings til serverens tunneladresse lykkes, klientens egen rutetabel ser rigtig ud, og LAN'et bag den klient er stadig utilgængeligt. Klientens egen rutetabel ser korrekt ud, serveren har en rute, der peger mod tunnelen, og pakkerne forsvinder stadig. Det er det klassiske symptom på en layer-3-tunnel, der ikke aner, at en af dens klienter også er en gateway.

Et tun-interface har intet næste hop per klient. Kernen ser ét interface med mange peers, så beslutningen om, hvilken klient der skal modtage en pakke til et fjernnetværk, skal træffes inde i OpenVPN-processen. Den beslutning konfigureres med iroute, og uden den har pakken ingen steder at gå hen.

Serveren router efter klient, ikke efter interface

Når serveren skal sende en pakke til en klients tunneladresse, er svaret entydigt: adressen tilhører den klients session. Når destinationen er et helt undernet bag den klient, tilhører adressen ingen, serveren kender, og kernens rute til tunnelen siger kun "ud ad dette interface" uden at sige hvilken peer.

OpenVPN løser det med en intern rutetabel, der knytter et destinationspræfiks til en bestemt klient. Den tabel bygges af iroute-poster, og derfor er en almindelig rute på serverværten ikke nok. Kernens rute bringer pakken til tunnelet; den interne mapping afgør, hvilken session der modtager den. Det er også derfor reparationen aldrig dukker op i kernens ruteoutput.

Mangler mappingen, ankommer pakken til serveren, matcher tunnelruten og droppes, fordi ingen klient gør krav på destinationen. Intet logger en ren fejl, og derfor ser fejlen ud som et tavst sort hul snarere end en routingløkke.

Skriv iroute-posten, der navngiver klienten

iroute bor i en klientspecifik konfigurationsfil, ikke i serverens hovedkonfiguration. Peg serveren på en mappe med indstillingen client-config-dir, og opret derefter en fil, hvis navn er klientens certifikat-common name, og læg præfikset ind i den.

For en filial, hvis LAN er 10.20.0.0/24, og hvis certifikat-common name er branch-router, indeholder filen på den sti en linje som iroute 10.20.0.0 255.255.255.0. Hovedkonfigurationen behøver kun mappeindstillingen; præfikset bor hos klienten.

Common name er den skrøbelige del. Et certifikat udstedt med et andet subject, eller en udrulning, der autentificerer brugere på brugernavn, mens filen er navngivet efter certifikatet, giver en fil, der aldrig læses. Tjek det navn, serveren faktisk rapporterer for sessionen, og overvej indstillingen, der får en ikke-matchende klient til at fejle i stedet for lydløst at forbinde uden sine ruter. At omdøbe filen, så den matcher certifikatet, er en femminutters rettelse, der forhindrer en meget lang aften.

Én klient kan eje flere præfikser. Tilføj én iroute-linje per netværk, og hold listen ved siden af resten af den klients indstillinger, så mappingen forbliver reviderbar.

Byg returvejen i begge retninger

At få pakker til fjernnetværket er halvdelen af arbejdet. Klienten skal også sende det netværks trafik ind i tunnelen, hvilket normalt gøres ved at pushe en rute til klienten: en linje som push "route 10.8.0.0 255.255.255.0" fortæller hver klient, hvordan den når netværket på serversiden. For filialen peger den tilsvarende rute mod tunnelen for alt, hvad den skal nå på serversiden.

Returretningen kræver en ejer på den fjerne side. Der skal nogen kende vejen tilbage: en statisk rute på LAN-routeren, der peger VPN-puljen mod serveren, eller adresseoversættelse på serveren, før trafikken kommer ind i LAN'et. Den statiske rute holder de oprindelige adresser synlige i logfiler og adgangsregler, men kræver LAN-ejerens samarbejde; oversættelse er selvstændig, men skjuler, hvem der faktisk oprettede forbindelsen.

Videresendelse skal være aktiveret på serverværten. Uden det accepterer kernen pakken fra tunnelen og afviser at sende den videre til LAN-interfacet, hvilket fra klientens synspunkt ser identisk ud med en manglende iroute.

Tjek tilgængelighed med de rigtige prober

Test i lag i stedet for at pinge den fjerne ende og gætte. Fra serveren, tjek at den interne mapping for præfikset findes, og at kernens rute peger mod tunnelen. Fra klienten, bekræft at den push'ede rute er installeret, og at dens standardvej til LAN-adressen er tunnelen.

Se så på pakkerne. En optagelse på tunnelet viser, om serveren transmitterer mod klienten, og en optagelse på LAN-interfacet viser, om den videresender. Hvis den første viser pakker og den anden intet, er problemet videresendelse eller et filter; hvis ingen af dem viser noget, fejlede opslaget tidligere.

To servere forbundet med en tunnel gentager den samme regel på begge sider: hver især har brug for en iroute til den andens pool, og hver især har brug for den rute og videresendelse, der gør vejen symmetrisk. Routing og politik er adskilte emner her. Routing afgør, hvor en pakke kan gå hen, mens en FORWARD-regel afgør, om den må, så en klient med to iroute-linjer kan nå begge præfikser, medmindre et filter siger andet.