Én NIC eller to? Å avgjøre grensesnittoppsettet til en VPN-server

Én fysisk adapter er nok for mange VPN-servere, og det er heller ikke en universell løsning. Den krypterte forbindelsen kommer inn på den adapteren, VPN-prosessen dekrypterer den, og deretter går den indre trafikken ut gjennom et virtuelt grensesnitt før den når en lokal tjeneste eller et rutet LAN. Om det virker avhenger av tre forhold: hvor målet ligger, om LAN-et har en returvei til klientpoolen, og om én delt fysisk lenke gir deg isolasjonen du påstår. Svar på de tre, og antallet adaptere følger.

De tre forholdene som avgjør det

Det første forholdet er målet. En tjeneste på selve VPN-verten nås bare gjennom tunellgrensesnittet, mens en vert på LAN-et krever videresending og en returvei. Det andre forholdet er den returveien, fordi LAN-enheten må vite hvordan den når klientpoolen, enten via en rute eller via oversetting på serveren.

Det tredje forholdet er separasjon. Én adapter betyr at hver pakke, kryptert eller ikke, deler en lenke og vanligvis en policykjede, så en isolasjonspåstand som avhenger av separat maskinvare oppfylles ikke av ett grensesnitt. Det er et faktum om veien, ikke om hvordan operativsystemet er konfigurert. Du kan fortsatt filtrere tunneltrafikken, men du kan ikke påstå en grense du ikke har.

Ingen av de tre handler om antall porter på kabinettet. De handler om ruting, eierskap til adresser og hvor mye designet avhenger av fysisk separasjon.

To adaptere er fortsatt et legitimt valg når fysiske soner, separate uplenk er, gjennomstrømning eller en gjenopprettingsvei utenfor båndet rettferdiggjør det. Det er konkrete krav, og de er verdt å skrive ned før noen bestiller maskinvare.

Når tjenesten kjører på VPN-verten

Det enkleste tilfellet trenger ingen videresending i det hele tatt. Daemonen mottar klientens pakker på tunellgrensesnittet og gir dem til en lokal socket, og svaret kommer tilbake samme vei. For verten er klientpooladressen en ekte lokal adresse.

To ting må likevel stemme: tjenesten må lytte på en adresse tunnelen kan nå, og vertens brannmur må godta trafikk som kommer inn på tunellgrensesnittet. Begge vises i kommandoene nedenfor.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Å binde en tjeneste bare til den offentlige adressen, eller å filtrere tunellgrensesnittet ved en feil, gir en forbindelse som når verten og deretter dør. Det ser ut som en VPN-feil og er vanligvis et socket- eller brannmurvalg.

Når målet ligger på LAN-et

Det er her et design med én adapter får rykte for å være kinkig. Serveren må videresende klientens pakker mot LAN-et, og LAN-enheten må sende svar tilbake til klientpoolen. Enten bærer du poolen som en rute på LAN-et, eller du oversetter kildeadressen på serveren slik at svar kommer tilbake til serveren selv.

Begge svarene er legitime og de feiler på ulike måter. En returrute holder den opprinnelige klientadressen synlig for målet, noe som er bra for logger og dårlig for brannmurregler som forutsetter LAN-adresser. Oversetting holder LAN-et enkelt og skjuler klientens identitet for målet.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

En asymmetrisk vei er det klassiske symptomet: klientens forespørsel kommer inn, svaret går ut via en annen ruter, og forbindelsen timer ut uten feil i noen av endene. Ta opp trafikk på begge sider før du konkluderer noe om tunnelen.

Hvorfor et alias ikke lager en ny sone

Å legge en ny adresse på samme adapter, eller å lage et dummy-grensesnitt for å etterligne en ekstra port, endrer svært lite. Pakkene går fortsatt ut gjennom samme fysiske lenke, samme svitsjport og vanligvis samme brannmurkjede, så det oppstår ingen ny grense mellom dem. Det er konfigurasjonskomfort, ikke segmentering. Å behandle det som en sonegrense er måten en isolasjonspåstand bare overlever på papiret.

En separat sone krever en reell separasjon i veien, og det er kravet en ny adapter oppfyller. Hvis en regel avhenger av at trafikk mot VPN aldri deler kringkastingsdomene med trafikk mot LAN, kan én kabel ikke gi den egenskapen, uansett hvordan verten er adressert.

Der et produkt dokumenterer en topologi med flere grensesnitt for en bestemt modus, følg produktets dokumentasjon i stedet for å finne på en omvei. Leverandører endrer også støttede topologier mellom utgivelser, som er en annen grunn til å lese gjeldende veiledning og ikke et gammelt veiviserskjermbilde.

Sjekk oppsettet mot trafikken du tillater

List opp trafikkklassene serveren skal bære: klient til vert, klient til LAN, vert til LAN og den krypterte ytre forbindelsen. Hver klasse har en kilde, et mål og et grensesnitt, og oppsettet må oppfylle alle fire samtidig. Et design som håndterer tre av dem, er vanligvis det som genererer billetter.

Bekreft deretter de faktiske grensesnittene og den faktiske opptaket, ikke diagrammet i designdokumentet. Kommandoene nedenfor skriver ut begge visningene.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Hvis opptaket utenfra viser den krypterte trafikken og opptaket innenfra viser den dekrypterte trafikken på tunellgrensesnittet mens den fysiske adapteren bærer begge, gjør én NIC jobben. Hvis opptaket innenfra er tomt, ligger problemet i tunnelen eller i videresendingsreglene, ikke i antallet adaptere. Avgjør topologien ut fra de to opptakene og rutetabellen, så har neste endring noe å måles mot.