Geteilte vs. dedizierte VPN-IP: Was sich wirklich ändert
Ein fest zugewiesener Ausgang und ein geteilter Pool durchlaufen dieselbe Umschreibung. Anders ist der Portblock, den Sie erhalten, wie lange die Bindung hält und wer ihre Historie teilt.
Ein geteilter Ausgang und ein dedizierter Ausgang durchlaufen dieselbe Umschreibung: Das Gateway ersetzt Ihre Quelladresse durch eine öffentliche Adresse aus seinem Pool und wählt einen Port. Der Unterschied liegt darin, wie dieser Pool aufgebaut ist und wie lange Ihre Bindung überlebt. Es ist eine Zuweisungsentscheidung, kein Verschlüsselungs-Upgrade.
Diese Einordnung beantwortet die meisten praktischen Fragen auf einmal. Eine Allowlist interessiert sich für die Stabilität der Bindung, die Betrugsprüfung einer Website für die Historie der Adresse, und keines von beiden kümmert sich darum, wie der Tarif heißt.
Beide Optionen sind Portzuordnungen auf einer Adresse
Wenn ein Client eine Verbindung über einen Ausgang öffnet, schreibt das Gateway die Quelladresse auf die öffentliche Adresse um, die der Pool vergibt, und wählt einen Quellport aus dem freien Bereich dieser Adresse. Zwei Teilnehmer am selben Ausgang werden zu zwei Portblöcken auf einer einzigen IPv4-Adresse. Der entfernte Server sieht einen Host mit vielen gleichzeitigen Verbindungen, und nichts in der Nutzlast verrät, welcher Block zu welchem Teilnehmer gehört. Diese Portzuordnung ist der Mechanismus, der die gemeinsame Nutzung einer Adresse überhaupt möglich macht.
Eine dedizierte Zuweisung verkürzt diese Geschichte, ohne ihre Form zu ändern: Der Pool hält ein Mitglied für Ihr Konto, und der Betreiber pinnt es fest, statt Sie durch einen Ring zu rotieren. Ports werden weiterhin über Ihre eigenen Sitzungen hinweg geteilt, und die Adresse wird weiterhin am Ausgang übersetzt statt zu Ihrem Gerät geroutet.
Das Verhalten auf der Leitung ist also identisch, nur die Buchführung unterscheidet sich.
| Property | Shared pool | Pinned assignment |
|---|---|---|
| Address selected at connect | Any free member of the pool | The one address bound to the account |
| Other subscribers on it | Present, unknown to you | Usually none, though the operator may oversubscribe |
| Stability across reconnects | Depends on pool size and rotation policy | Holds until the operator changes the assignment |
Allowlists verfolgen die Bindung, nicht das Etikett
Eine IP-basierte Zugriffsregel auf einem Business-Dienst prüft ein Feld im Paketkopf. Muss dieses Feld einem festen Wert entsprechen, ist ein rotierender Pool das falsche Werkzeug, egal wie viele Adressen er enthält. Eine feste Zuweisung erfüllt die Regel, bis die Wartung die Adresse verschiebt; deshalb gehört die Wartungsrichtlinie in dasselbe Gespräch wie die Funktionsliste.
curl -4 -s https://api.ipify.org; echo curl -6 -s https://ifconfig.co; echo
Führen Sie beide Zeilen bei aktivem Tunnel aus. Die erste bestätigt den IPv4-Ausgang, den Ihre Allowlist sehen wird; die zweite erkennt ein Dual-Stack-Leck, bei dem IPv6-Verkehr über den Anbieter das Gerät verlässt, während IPv4 durch den Tunnel geht. Ein Dienst, der beide Familien akzeptiert, kann eine Allowlist-Prüfung aus einem Grund nicht bestehen, den das IPv4-Ergebnis nie zeigt.
Bestätigen Sie dann, dass die Anwendung, die die Allowlist benötigt, auch diejenige ist, die den Tunnel nutzt: Split-Tunnelling, eine ausgenommene Route oder eine Proxy-Einstellung können diese App direkt nach außen schicken, während der Browsertest korrekt aussieht. Ein Kill-Switch, der den Verkehr blockiert, wenn der Tunnel abbricht, ist besser als ein stiller Rückfall auf Ihre Heimatadresse – genau so bricht ein allowlist-basierter Workflow in die falsche Richtung.
Reputation reist mit der Adresse
Ein geteilter Ausgang trägt das angesammelte Verhalten aller, die ihn genutzt haben, sodass Bewertung, Ratenlimits und Challenge-Seiten auf der Zielseite auf diese Historie reagieren. Normales Surfen kann dann aus Gründen, die Sie nicht sehen, auf eine zusätzliche Überprüfung stoßen. Eine feste Adresse verengt die Gruppe der Beiträger auf Ihr eigenes Konto. Sauber kommt sie trotzdem nicht an, denn feste Adressen werden recycelt, und ein Rechenzentrumsbereich kann anders behandelt werden als ein Wohnbereich, egal wer ihn jetzt hält.
Konten, Cookies und Browser-Fingerabdrücke bestimmen weiterhin die meisten dieser Entscheidungen.
Betrachten Sie Reputation als Eigenschaft des gesamten Pfads statt als eine Zahl, die an einem Tarifnamen hängt. Zwei Kunden desselben Anbieters können wegen des Subnetzes, der eigenen Richtlinie des Ziels oder des Kontos hinter der Anfrage unterschiedlich behandelt werden.
Was in beiden Fällen gleich bleibt
Der Tunnel verschlüsselt auf dieselbe Weise. WireGuard führt den Handshake weiterhin mit denselben Schlüsseln aus, OpenVPN handelt weiterhin dieselbe Cipher-Suite aus, und die Ausgangsadresse fließt nie in diese Aushandlung ein. Für eine feste Adresse zu zahlen kauft Zuweisungsverhalten, keinen stärkeren Transport.
Auch die Sichtbarkeit für den Betreiber bleibt gleich. Quellverbindungen, Zeitstempel und Kontokennungen bleiben am Ausgang in beiden Arrangements beobachtbar, und eine Adresse mit Fremden zu teilen erzeugt keine Protokollierungsrichtlinie. Eine feste Adresse kann sogar als stabilerer Identifikator über Sitzungen hinweg wirken, was der Annahme widerspricht, dediziert bedeute mehr Privatsphäre.
Wählen Sie eine feste Adresse, wenn ein Ziel eine stabile Quelle verlangt, wenn ein Workflow Rotation nicht verträgt oder wenn geteilte Historie legitimen Verkehr immer wieder unterbricht. Bleiben Sie bei einem Pool, wenn die einzige Anforderung ein anderer Ausgang ist und Rotation nichts kostet. Überprüfen Sie das Ergebnis mit den beiden obigen Befehlen, bevor Sie einer der beiden Annahmen trauen. Der Ausgang, den Sie zu haben glauben, und der, den der Server sieht, sind nur dann dasselbe Feld, wenn nichts dazwischen ihn umschreibt.