Behöver varje OpenVPN-peer en remote-rad? Inte riktigt

Två peer-konfigurationer jämförs sida vid sida, den ena har en remote-rad och den andra inte, och slutsatsen är att en av dem är trasig. Den slutsatsen är fel tillräckligt ofta för att vara värd att plocka isär. Direktivet beskriver vart det första paketet ska skickas. Det väljer inte om processen agerar som en initierande klient eller som en väntande gateway, och det avgör inte vilken sida som bevisar sin identitet för den andra.

Vad remote faktiskt anger

En remote-post namnger en värd, eventuellt en port och ett transportprotokoll, och eventuellt flera sådana poster som prövas i ordning.

Dess frånvaro har en definierad och inte odefinierad betydelse: processen väntar och agerar inte på paket från en adress om inte den peeren autentiserar sig. En gateway som betjänar roaming-användare har därför ingen anledning att namnge någon av dem i förväg.

Läs posten som en adressrelation. Om den andra änden är betrodd besvaras av certifikat och verifieringsalternativen, inte av att en adress skrevs ned.

Tre uppställningar avgör svaret

En roaming-klient behöver en destination, eftersom den måste initiera och inte vet var gatewayen är utan en. En gateway för många klienter behöver ingen destination per användare, eftersom klienterna anländer och autentiserar sig. En avsiktlig förbindelse mellan två peers med kända ändpunkter kan ha en destination på ena sidan, båda sidorna eller ingen, beroende på vilken sida som initierar.

Att klistra in en fast klientadress i en allmän gateway är det fel som följer av att ignorera dessa kategorier. Det fungerar för den enda peer vars adress registrerades och vilseleder alla andra.

Inget i direktivet gör en konfiguration till en server för många klienter, och inget i dess närvaro hindrar en serverroll. OpenVPN 2.6-referensen dokumenterar de valfria argumenten och beteendet utan remote var för sig, vilket är en antydan om hur oberoende de är.

Transportroller är en annan axel

Med TCP väntar den ena sidan och den andra ringer. Det är separata direktiv från destinationen, och att blanda dem ger ett par där båda väntar eller båda ringer.

Det finns också en TCP-källfilterroll, och därför är det platta påståendet att en server aldrig får innehålla remote fel.

Med UDP finns ingen förbindelse att upprätta, så båda ändarna använder motsvarande UDP-transport och direktivet säger bara vart det ska siktas. Adressändringar från en autentiserad peer hanteras av ett eget beteende i stället för att fler poster läggs till. Att ha transporten rätt är en förutsättning för att destinationen ska betyda något, och att blanda de två ger konfigurationer som ser rimliga ut och aldrig slutför ett handskak.

Varför en saknad remote inte är en öppen dörr

En process utan destination avvisar ändå trafik från peers som inte autentiserar sig, och det är den delen folk missar när de läser den saknade raden som en lyssnare som är öppen för alla.

Autentisering och destination är oberoende, och den första är den som spelar roll för förtroende.

Det omvända felet är farligare. En fast källadress kan kännas som åtkomstkontroll eftersom den är specifik och lätt att kontrollera, men den bevisar inget om vem som sitter i andra änden. Behåll certifikatverifieringen och identitetskontrollerna som binder ett certifikat till dess roll. Att ersätta dem med en adressmatchning byter en verklig kontroll mot utseendet av en.

Skriv ned vad konfigurationen förutsätter

För varje sida, notera tre saker: hur det första paketet når peeren, vilken sida som kan ta emot transporten, och vad varje sida verifierar om den andra.

De antagandena är designen. Direktiven är bara deras stavning.

Om de två filerna skiljer sig, kontrollera om de uttrycker olika antaganden i stället för att anta att en är fel. Ett symmetriskt par filer är varken nödvändigt eller tillräckligt för en fungerande tunnel, och asymmetrin är ofta den del som får en topologi att fungera.