Volledige tunnel in strongSwan vereist 0.0.0.0/0 aan beide kanten

Een strongSwan-verbinding die voor één privaat subnet werkt, draagt geen internetverkeer alleen omdat iemand één regel heeft bewerkt. Een volledige tunnel is een afspraak tussen twee peers over welke adressen de child SA beschermt, en elke peer noemt de andere kant ten opzichte van zichzelf. Krijg de ene kant goed en de andere fout, en de child SA komt of niet omhoog of smaller omhoog dan bedoeld. De vijf controles hieronder volgen die afspraak van de client, via de gateway, naar het internet.

Controleer eerst de selector van de client

De client beschrijft wat hij aan de andere kant wil beschermen als remote_ts, en alles wat hij stuurt komt van zijn eigen toegewezen adres. Voor internetverkeer moet die waarde de bestemmingen dekken die de gebruiker werkelijk bereikt, wat in de praktijk de hele IPv4-ruimte betekent. Een client die nog één subnet vermeldt, vraagt om een gesplitste tunnel, hoe het profiel in de interface ook heet. De bronkant is meestal dynamic omdat het adres bij het verbinden wordt toegewezen. Een vaste bron die daar staat, breekt zodra de adrespool verandert.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Het fragment is geen volledig verbindingsbestand, en dit gaat ervan uit dat authenticatie, identiteiten en de pool met virtuele adressen al zijn geconfigureerd. De bronselector van de client en het adres dat de server toewijst moeten nog steeds overeenkomen, anders komt de child SA omhoog met een bereik dat geen van beide kanten verwachtte. Laad het met swanctl --load-all en lees de uitvoer voordat u succes aanneemt. Een bestand dat parseert, kan alsnog worden geweigerd vanwege een selector die niet overlapt met het voorstel van de andere peer.

Controleer de selector van de gateway aan zijn eigen kant

De gateway leest hetzelfde concept uit de tegenovergestelde richting. Internetbestemmingen zijn lokaal voor de gateway, dus zijn local_ts is de brede en zijn remote_ts beschrijft de clientpool. Die omkering is de meest voorkomende fout in een volledige-tunnelconfiguratie, en ze overleeft de beoordeling omdat beide regels apart plausibel lijken.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Het clientfragment naar het gatewaybestand kopiëren levert een selectorpaar op dat niets nuttigs beschrijft, omdat beide kanten dezelfde rol zouden opeisen. De strongSwan-doorstuurhandleiding documenteert de koppeling van client en gateway expliciet, en het is de moeite waard die naast het verbindingsbestand te lezen in plaats van na de fout. Het gatewaybestand heeft ook de pooldefinitie nodig waarnaar remote_ts verwijst. Een selector die een niet-bestaande pool noemt, laadt zonder klacht en faalt bij het verbinden.

De oudere ipsec.conf gebruikt linker- en rechterrollen met verschillende sleutels, en een rightsubnet-regel is geen directe vervanging voor de swanctl-waarde. Houd de twee syntaxen in aparte bestanden in plaats van de ene in de andere te plakken. Ze in één map mengen is hoe een werkende verbinding na een herstart stil terugvalt.

Controleer de onderhandelde child SA, niet het bestand

Een opgeslagen configuratie bewijst bedoeling en niets meer. De andere peer kan het gevraagde versmallen, en een bestaande child SA wordt niet vervangen alleen omdat het bestand eronder is gewijzigd. Bevestig wat werkelijk is geïnstalleerd voordat u iets anders wijzigt.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

De eerste opdracht toont wat de daemon heeft geladen, de tweede de opgezette child SA's en de derde het beleid dat de kernel toepast. Als het bestand 0.0.0.0/0 zegt en de lijst één subnet toont, heeft de onderhandeling het bereik versmald en helpt het herlezen van het bestand niet. Beëindig de child, start hem opnieuw en vergelijk alle drie de uitvoer opnieuw. Een child die met hetzelfde smalle bereik terugkomt, wordt door de andere kant versmald en niet door het lokale bestand, en dat is een gesprek met de andere beheerder in plaats van een lokale wijziging.

Lees beide richtingen in de beleidslijst, want een tunnel die de ene richting installeert en de andere niet, is een routeringsprobleem in configuratiekostuum. Het voorwaartse en terugkerende beleid moeten hetzelfde selectorpaar in spiegelbeeld noemen, en een ontbrekende spiegel is een defect in de daemon of in het voorstel, niet in de selectortekst.

Controleer doorsturen en de retourroute

Een selector laat verkeer naar de gateway toe, maar zorgt er niet voor dat de gateway dat verkeer verder routeert. Doorsturen moet zijn ingeschakeld, de firewall moet de stroom toestaan, en het antwoord moet de weg terug naar de clientpool vinden. Dat zijn drie afzonderlijke vereisten, en elk faalt met een ander symptoom. Een ontbrekende doorstuurregel gedraagt zich als een zwart gat, terwijl een ontbrekende retourroute zich als een eenrichtingstunnel gedraagt.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Private clientadressen hebben meestal bewuste brontranslatie nodig voordat ze een openbare interface kunnen verlaten, terwijl een expliciet gerouteerde toewijzing andere behandeling vereist. Als NAT in het spel is, behoud de door de implementatie ondersteunde uitzonderingen zodat verkeer dat een beveiligingsbeleid moet inspecteren er niet langs wordt vertaald. Een brede masquerade-regel gekopieerd van een andere gateway verandert veel meer stromen dan de auteur bedoelde. Schrijf de regel alleen voor de clientpool, en laat een opmerking achter waarom die bestaat.

Bevestig op de client de routes die de backend heeft geïnstalleerd in plaats van de routes die u aannam. Een beheerder met route-installatie uitgeschakeld heeft een met de hand onderhouden routeringsontwerp nodig, en dat ontwerp moet worden bijgewerkt telkens wanneer de tunnel verandert. Controleer de routeringstabel na een herverbinding, niet alleen na een verse start.

Controleer wat de tunnel nog steeds niet dekt

Het selectorpaar dekt IPv4 en niets anders. IPv6, DNS en elk beleid op applicatieniveau zijn afzonderlijke beslissingen die een brede IPv4-selector stil negeert. Een tunnel die elk IPv4-pakket draagt, kan nog steeds elke naamopzoeking laten lekken.

Benoem het bedoelde DNS-pad expliciet, want een volledige tunnel die namen nog via de lokale resolver oplost, lekt queries buiten de tunnel en breekt private namen. Als de client een IPv6-adres krijgt, heeft die adresfamilie dezelfde behandeling nodig, anders verkiest de host een pad dat de tunnel niet beschermt. Test met een naam die alleen de private kant kan beantwoorden, en behandel een openbaar antwoord als een lek.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Bevestig de keten met die twee opdrachten plus de onderhandelde selectors uit de lijst hierboven. Als de traceroute de lokale router als eerste hop toont, gebruikt het verkeer de tunnel niet, wat de selectors ook beweren. Internettoegang is pas volledig wanneer het gekozen verkeer wordt toegelaten, doorgestuurd en teruggebracht via de ontworpen gateway. 0.0.0.0/0 in een profiel vinden is het begin van die keten, niet het bewijs.