Ét NIC eller to? Sådan vælger du et VPN-servers interfacelayout

Én fysisk adapter er nok til mange VPN-servere, og det er heller ikke et universelt design. Den krypterede forbindelse ankommer på den adapter, VPN-processen dekrypterer den, og den indre trafik forlader gennem et virtuelt interface, før den når en lokal tjeneste eller et routet LAN. Om det virker afhænger af tre betingelser: hvor destinationen ligger, om LAN'et har en returvej til klientpuljen, og om ét delt fysisk link giver dig den isolation, du påstår. Svar på de tre, og antallet af adaptere følger.

De tre betingelser, der afgør det

Den første betingelse er destinationen. En tjeneste på selve VPN-værten nås kun gennem tunnel-interfacet, mens en vært på LAN'et kræver videresendelse og en returvej. Den anden betingelse er den returvej, fordi LAN-enheden skal vide, hvordan den når klientpuljen, enten via en rute eller via oversættelse på serveren.

Den tredje betingelse er adskillelse. Én adapter betyder, at hver pakke, krypteret eller ej, deler et link og normalt en politikskæde, så et isolationskrav, der afhænger af separat hardware, opfyldes ikke af ét interface. Det er et faktum om vejen, ikke om hvordan styresystemet er konfigureret. Du kan stadig filtrere tunneltrafikken, men du kan ikke påstå en grænse, du ikke har.

Ingen af de tre handler om antallet af porte på kabinettet. De handler om routing, adresseejerskab og hvor meget designet afhænger af fysisk adskillelse.

To adaptere er fortsat et legitimt valg, når fysiske zoner, separate uplinks, gennemstrømning eller en out-of-band-genopretningsvej berettiger det. Det er konkrete krav, og de er værd at nævne, før nogen bestiller hardware.

Når tjenesten kører på VPN-værten

Det enkleste tilfælde kræver slet ingen videresendelse. Dæmonen modtager klientens pakker på tunnel-interfacet og giver dem videre til en lokal socket, og svaret følger samme interface tilbage. Klientpuljens adresse er en rigtig lokal adresse set fra værten.

To ting skal stadig være rigtige: tjenesten skal lytte på en adresse, som tunnelen kan nå, og værtens firewall skal acceptere trafik, der ankommer på tunnel-interfacet. Begge er synlige i kommandoerne nedenfor.

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

At binde en tjeneste kun til den offentlige adresse, eller ved en fejl at filtrere tunnel-interfacet, giver en forbindelse, der når værten og derefter dør. Det ligner en VPN-fejl og er normalt en socket- eller firewallbeslutning.

Når destinationen ligger på LAN'et

Det er her, et enkeltadapterdesign får sit ry for at være bøvlet. Serveren skal videresende klientens pakker mod LAN'et, og LAN-enheden skal sende svar tilbage til klientpuljen. Enten bærer du puljen som en rute på LAN'et, eller du oversætter kildeadressen på serveren, så svarene kommer tilbage til serveren selv.

Begge svar er legitime, og de fejler forskelligt. En returrute holder den oprindelige klientadresse synlig for destinationen, hvilket er godt for logfiler og dårligt for firewallregler, der antager LAN-adresser. Oversættelse holder LAN'et enkelt og skjuler klientens identitet for destinationen.

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

En asymmetrisk vej er det klassiske symptom: klientens anmodning ankommer, svaret forlader via en anden router, og forbindelsen udløber uden fejl i nogen ende. Fang på begge sider, før du konkluderer noget om tunnelen.

Hvorfor et alias ikke skaber en anden zone

At tilføje en anden adresse til den samme adapter eller oprette et dummy-interface for at efterligne en anden port ændrer meget lidt. Pakkerne forlader stadig det samme fysiske link, den samme switchport og normalt den samme firewallskæde, så der findes ingen ny grænse mellem dem. Det er konfigurationsbekvemmelighed, ikke segmentering. At behandle det som en zonegrænse er, hvordan et isolationskrav kun overlever på papiret.

En separat zone kræver en rigtig adskillelse i vejen, og det er det krav, en anden adapter opfylder. Hvis en regel afhænger af, at VPN-vendt trafik aldrig deler broadcastdomæne med LAN-vendt trafik, kan ét kabel ikke levere den egenskab, uanset hvordan værten adresseres.

Hvor et produkt dokumenterer en multi-interface-topologi til en bestemt tilstand, følg det produkts dokumentation i stedet for at opfinde en omvej. Leverandører ændrer også deres understøttede topologier mellem udgivelser, hvilket er en anden grund til at læse den aktuelle guide frem for et gammelt guide-skærmbillede.

Kontrollér layoutet mod den trafik, du tillader

List de trafikklasser, serveren forventes at bære: klient til vært, klient til LAN, vært til LAN og den krypterede ydre forbindelse. Hver klasse har en kilde, en destination og et interface, og layoutet skal opfylde alle fire på én gang. Et design, der klarer tre af dem, er normalt det, der skaber tickets.

Bekræft derefter de faktiske interfaces og den faktiske optagelse, ikke diagrammet i designdokumentet. Kommandoerne nedenfor udskriver begge visninger.

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

Hvis den ydre optagelse viser den krypterede trafik, og den indre optagelse viser den dekrypterede trafik på tunnel-interfacet, mens den fysiske adapter bærer begge, gør ét NIC arbejdet. Hvis den indre optagelse er tom, ligger problemet i tunnelen eller videresendelsesreglerne, ikke i antallet af adaptere. Beslut topologien ud fra de to optagelser og routingtabellen, så har den næste ændring noget at måle sig op imod.